Questions on thread safety about the end port objects

["Gattu, Praveen" <pr...@amazon.com>]

Hi - I was trying to get more information about this from CXF
documentation, but couldn't find much. 
We are using cxf to generate stubs for an internally published wsdl,
when the stubs are generated this is the pattern we use to call the
service

SomeService someService = new SomeService(wsdlURL, SERVICE); //wsdlURL
is localtion of the wsdl file and SERVICE is the Qname
SomeServicePort port = someService.getSomeServicePort();

port.someOperation(someRequest1);

port.someOperation(someRequest2);
.....

1)First time I make this call, it takes a long time ~6sec(I am guessing
its due to loading of jar's etc, the subsequent calls takes ~200msec).
How do I speed it up, should these kind of things happen when the app
starts up? Is there a pattern to solve these kind of issues?
2)Can the port object be shared by multiple threads without any external
synchronization.
3)Is the calls to the actual service sequential and does threads get
blocked on one another? If so is there a way I could configure CXF to
create a pool of connection objects for each port, is so how would I do
that. If not should I(a client) manage these external connection pools?

Thanks in advance,
Praveen

Re: Questions on thread safety about the end port objects

[Jaroslav Libak <ja...@seznam.cz>]

Hello

Daniel Kulp schrieb:
> On Thursday 15 January 2009 4:02:46 pm Jaroslav Libak wrote:
>> Another setting that I think is not thread safe, is configuring http
>> conduit, to use/not use TLS on the fly for every call. This is a serious
>> limitation of Apache CXF, as one cannot use the same client for http and
>> https, with some addresses using http, others https. I already had to write
>> a patch for HTTPConduit, to allow it work with both http and https once
>> https conduit is configured (but not vice versa), simply because its needed
>> and configuration options in CXF are insufficient.
> 
> Submit the patch back?
> 

My patch is only temporary until this situation is solved in CXF in some
acceptable way. The patch used 2 connection factories in HTTPConduit if https
was configured, so that we also have http connection factory for getting http
connections if supplied address is http.

I think first it should be defined how this should work, and then we may have
patches. From mailinglist I read that the fact you cannot use http for https
conduit and vice versa was intentional. The argument was, that if you configure
https, you should not use unsecured connections. But there are scenarios where
this is needed, when a list of addresses (both https & http) are discovered in
some way, and multiple web services need to be invoked with different security
parameters in paralel. Some web services support https, and others don't. Some
may use authentication, others maybe don't. All this is discovered on the fly.

I think we could have some option to use the current behaviour (so that once
endpoint is secured, http calls cannot be made), and to allow http calls once
https is configured. For using https, https would need to be configured just
like now (unless a static address is configured in xml, when this seems to be
automatic).

Jaro

Re: Questions on thread safety about the end port objects

[Daniel Kulp <dk...@apache.org>]

On Thursday 15 January 2009 4:02:46 pm Jaroslav Libak wrote:
> Doug Daniels schrieb:
> >> 2)  Certain settings on the http conduit.   The conduit is per port, so
> >> anything that the conduit manipulates would not be safe.   The main one
> >> is sessions.   The session cookie is handled in the conduit.    Thus,
> >> the port is associated with a single session (if session is turned on). 
> >>   Similarly, if you change the TLS settings, those would reflect across
> >> all the threads.
> >>
> >> Basically, for the most part, you can create a single port and use it
> >> for MOST use cases.
>
> This should be clearly documented. There should be an option in XML to
> configure "thread.local.request.context" to true. Are you sure that JAX-WS
> mandates that changes to getRequestContext() also affect other future
> invocations? If it is really true, I would even say this is a bug in JAX-WS
> standard. The function is named getRequestContext(), leading you to think
> you get something per request, but its not true!

Yea.  I'm sure.  We originally made the CXF RequestContexts a thread local and 
there was no way to get the TCK's passing.   Upon talking to Sun, it's 
definitely NOT a thread local.    Basically, its designed so that in an J2EE 
container, a Proxy can be configured (deployment descriptor stuff injected 
into context) and injected into a bean (@WebServiceRef) and then usable on 
any thread that calls that bean.   That requires the request context to not 
be thread local.   

Anyway, for JAX-WS 2.2, there has been a request to "clarify" the situation 
and the current "clarification" is that not only are the proxies non-thread 
safe, but the Service objects aren't required to be either. 


> Another setting that I think is not thread safe, is configuring http
> conduit, to use/not use TLS on the fly for every call. This is a serious
> limitation of Apache CXF, as one cannot use the same client for http and
> https, with some addresses using http, others https. I already had to write
> a patch for HTTPConduit, to allow it work with both http and https once
> https conduit is configured (but not vice versa), simply because its needed
> and configuration options in CXF are insufficient.

Submit the patch back?



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Questions on thread safety about the end port objects

[Jaroslav Libak <ja...@seznam.cz>]

Hello

Doug Daniels schrieb:
> Thanks Daniel,
>>
>> CXF proxies ARE thread safe except for a couple of scenarios:
>>
>> 1) Use of the port.getRequestContext().   By default per JAX-WS spec, the
>> request context is per port.   Thus, any settings set on that will affect
>> other threads using the proxy.    You CAN do:
>> port.getRequestContext().put("thread.local.request.context", "true");
>> and future calls to getRequestContext() will use a thread local context.    In
>> CXF, the response context is always thread local.
>>
>> 2)  Certain settings on the http conduit.   The conduit is per port, so
>> anything that the conduit manipulates would not be safe.   The main one is
>> sessions.   The session cookie is handled in the conduit.    Thus, the port
>> is associated with a single session (if session is turned on).    Similarly,
>> if you change the TLS settings, those would reflect across all the threads.
>>
>> Basically, for the most part, you can create a single port and use it for MOST
>> use cases.

This should be clearly documented. There should be an option in XML to configure
"thread.local.request.context" to true. Are you sure that JAX-WS mandates that
changes to getRequestContext() also affect other future invocations? If it is
really true, I would even say this is a bug in JAX-WS standard. The function is
 named getRequestContext(), leading you to think you get something per request,
but its not true!

Another setting that I think is not thread safe, is configuring http conduit, to
use/not use TLS on the fly for every call. This is a serious limitation of
Apache CXF, as one cannot use the same client for http and https, with some
addresses using http, others https. I already had to write a patch for
HTTPConduit, to allow it work with both http and https once https conduit is
configured (but not vice versa), simply because its needed and configuration
options in CXF are insufficient.

Jaro

Re: Questions on thread safety about the end port objects

[Doug Daniels <da...@gmail.com>]

Thanks Daniel,

Just to make sure I understand it, you're saying for most cases it
will be thread safe, and for some cases I can specify it to use
ThreadLocal state for RequestContext's.

My use case is basically every user of my web application will make a
request to this external web service through the web application
something kinda like this (in the real system we're using JAAS and
using the SOAP web service as our remote Credential checking system):


private static Services ss = new Services(wsdlURL);
private static Services port = ss.getServicesSoap12();

public void handleLogin(Request req) {
            ss = new Services(wsdlURL);
            port = ss.getServicesSoap12();
            port.onLogin(req.getParameter("name"));
}


On Thu, Jan 15, 2009 at 2:02 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>
> CXF proxies ARE thread safe except for a couple of scenarios:
>
> 1) Use of the port.getRequestContext().   By default per JAX-WS spec, the
> request context is per port.   Thus, any settings set on that will affect
> other threads using the proxy.    You CAN do:
> port.getRequestContext().put("thread.local.request.context", "true");
> and future calls to getRequestContext() will use a thread local context.    In
> CXF, the response context is always thread local.
>
> 2)  Certain settings on the http conduit.   The conduit is per port, so
> anything that the conduit manipulates would not be safe.   The main one is
> sessions.   The session cookie is handled in the conduit.    Thus, the port
> is associated with a single session (if session is turned on).    Similarly,
> if you change the TLS settings, those would reflect across all the threads.
>
> Basically, for the most part, you can create a single port and use it for MOST
> use cases.
>
> Does that help at all?
>
> Dan
>
>
> On Thursday 15 January 2009 1:11:59 pm dougnukem wrote:
> > Gattu, Praveen wrote:
> > > 3)Is the calls to the actual service sequential and does threads get
> > > blocked on one another? If so is there a way I could configure CXF to
> > > create a pool of connection objects for each port, is so how would I do
> > > that. If not should I(a client) manage these external connection pools?
> >
> > Has there been any future response to this question?
> >
> > I'm interfacing with a SOAP web service from a JETTY servlet, and when
> > handling mutliple requests we create a new Services and port for each
> > request.
> >
> > Would I be able to reuse a single Service and port and have multiple
> > requests (threads) calling methods on it? Or would the suggested solution
> > be to create a limited pool of these ports and block requests until one of
> > those pooled objects is available?
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog

Re: Questions on thread safety about the end port objects

[Daniel Kulp <dk...@apache.org>]

CXF proxies ARE thread safe except for a couple of scenarios:

1) Use of the port.getRequestContext().   By default per JAX-WS spec, the 
request context is per port.   Thus, any settings set on that will affect 
other threads using the proxy.    You CAN do:
port.getRequestContext().put("thread.local.request.context", "true");
and future calls to getRequestContext() will use a thread local context.    In 
CXF, the response context is always thread local.

2)  Certain settings on the http conduit.   The conduit is per port, so 
anything that the conduit manipulates would not be safe.   The main one is 
sessions.   The session cookie is handled in the conduit.    Thus, the port 
is associated with a single session (if session is turned on).    Similarly, 
if you change the TLS settings, those would reflect across all the threads.

Basically, for the most part, you can create a single port and use it for MOST 
use cases.   

Does that help at all?

Dan


On Thursday 15 January 2009 1:11:59 pm dougnukem wrote:
> Gattu, Praveen wrote:
> > 3)Is the calls to the actual service sequential and does threads get
> > blocked on one another? If so is there a way I could configure CXF to
> > create a pool of connection objects for each port, is so how would I do
> > that. If not should I(a client) manage these external connection pools?
>
> Has there been any future response to this question?
>
> I'm interfacing with a SOAP web service from a JETTY servlet, and when
> handling mutliple requests we create a new Services and port for each
> request.
>
> Would I be able to reuse a single Service and port and have multiple
> requests (threads) calling methods on it? Or would the suggested solution
> be to create a limited pool of these ports and block requests until one of
> those pooled objects is available?



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Questions on thread safety about the end port objects

[dougnukem <da...@gmail.com>]

Gattu, Praveen wrote:
> 
> 3)Is the calls to the actual service sequential and does threads get
> blocked on one another? If so is there a way I could configure CXF to
> create a pool of connection objects for each port, is so how would I do
> that. If not should I(a client) manage these external connection pools?
> 

Has there been any future response to this question?

I'm interfacing with a SOAP web service from a JETTY servlet, and when
handling mutliple requests we create a new Services and port for each
request. 

Would I be able to reuse a single Service and port and have multiple
requests (threads) calling methods on it? Or would the suggested solution be
to create a limited pool of these ports and block requests until one of
those pooled objects is available?
-- 
View this message in context: http://www.nabble.com/Questions-on-thread-safety-about-the-end-port-objects-tp12785807p21483574.html
Sent from the cxf-user mailing list archive at Nabble.com.