开发者

Javax.xml.ws.Endpoint how does it deal with multiple connections?

开发者 https://www.devze.com 2023-01-04 13:05 出处:网络
When you use javax.xml.ws.Endpoint.publish t开发者_JS百科o handle incoming restful/soap requests, will it generate a thread for each request? or will I have handle threads myself?

When you use javax.xml.ws.Endpoint.publish t开发者_JS百科o handle incoming restful/soap requests, will it generate a thread for each request? or will I have handle threads myself?

I've been trying to work this out for a couple of days now. The documentation hints on threads, but there is nothing specific about this.

Doc says:

An Executor may be set on the endpoint in order to gain better control over the threads used to dispatch incoming requests. For instance, thread pooling with certain parameters can be enabled by creating a ThreadPoolExecutor and registering it with the endpoint.

For me that looks like it handles threads, but you will have no control over them, so adding a ThreadPoolExecutor to execute the threads, you will have a pool of threads you can work with. Is this right?


Examining section 5.2.7 of the JavaTM API for XML-Based Web Services specification (JAX-WS) seems to indicate so, although it looks like there is some room for implementation specific behavior. To really know what is going on you'd have to investigate the JAX-WS implementation you are using and the particular deployment environment. I'd imagine the behavior might be different depending upon whether the service is deployed within a Servlet container or in a standalone process. The control that you do have over the threads is limited to providing a specific ThreadPoolExecutor implementation. Section 5.2.7 states:

5.2.7 Executor

Endpoint instances can be configured with a java.util.concurrent.Executor. The executor will then be used to dispatch any incoming requests to the application. The setExecutor and getExecutor methods of Endpoint can be used to modify and retrieve the executor configured for a service.

<> Conformance (Use of Executor): If an executor object is successfully set on an Endpoint via the setExecutor method, then an implementation MUST use it to dispatch incoming requests upon publication of the Endpoint by means of the publish(String address) method. If publishing is carried out using the publish(Object serverContext)) method, an implementation MAY use the specified executor or another one specific to the server context being used.

<> Conformance (Default Executor): If an executor has not been set on an Endpoint, an implementation MUST use its own executor, a java.util.concurrent.ThreadPoolExecutor or analogous mechanism, to dispatch incoming requests.

Also, section 5.2.2 references 5.2.7 near the end of the section:

5.2.2 Publishing

...

An Endpoint will be typically invoked to serve concurrent requests, so its implementor should be written so as to support multiple threads. The synchronized keyword may be used as usual to control access to critical sections of code. For finer control over the threads used to dispatch incoming requests, an application can directly set the executor to be used, as described in section 5.2.7.

I realize this probably doesn't answer your question exactly, but hopefully it points you in a direction that you can get the answer you are looking for.


An Executor needs to be set in order to make an Endpoint multi-threaded. A simple multi-threaded Executor would be the fixed thread pool Executor.

endpoint.setExecutor(Executors.newFixedThreadPool(4));

This will allow your WebService to accept 4 connections simultaneously. But make sure your Service is thread safe.


I could not find and answer to this in the official doco, but after playing around with it and reading 'Java Web Services: Up and Running', it seems like it does not generate threads for each connections. So the service is blocked until it's done with one request, then a new request is handled.


Endpoint.publish(Url, ServiceImplObj) publishes a webservice at a given url. The no. of threads assigned for request handling truly is under control of the jvm because this is a light weight deployment which is handled by jvm itself.

For better clarification you can print the current thread name at service side and you can see that the service threads are being assigned from a thread pool which is managed by jvm.

[pool-1-thread-1]: Response[57]:
[pool-1-thread-5]: Response[58]:
[pool-1-thread-4]: Response[59]:
[pool-1-thread-3]: Response[60]:
[pool-1-thread-6]: Response[61]:
[pool-1-thread-6]: Response[62]:

I have used jdk1.6.0_35

xjc -version xjc version "JAXB 2.1.10 in JDK 6" JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build JAXB 2.1.10 in JDK 6)

0

精彩评论

暂无评论...
验证码 换一张
取 消