It is not easy to share the http conduit between the different proxy,
since you need to hack the HttpTransportFactory and handle
theconfiguration of the http conduit.
I don't think using the interceptor could resolve the problem that you
met. Because when you using the
interceptor to hold the first session cookie, you will make the
interceptor stateful. We do not want the interceptor
be stateful to avoid lock the multi thread calling.
My suggestion is
We could put the cookie into the message context for application code to
access and reset.
Then you can get the cookie from the first proxy in your application
code and then set cookie to the
second proxy to get around it.
Thoughts?
Willem.
Chris Campbell wrote:
That would have to be on the client side, correct? I think I would
need to have a client side inInterceptor to do that.
I tend to load the proxies as needed, is there a way to probe the
bus to get any other loaded proxies so that a lazily instantiated
proxy can get a previously acquired session cookie from another?
Maybe the inInterceptor can just stash away the first session cookie
acquired, and an outInterceptor can apply it to any request. Any
thoughts as to what the best practice would be?
I guess a feature request would be to be able to share an
http-conduit between proxies. I kind of think of the http-conduit as
an http client, is that bad analogy?
Thanks for the insight, definitely narrowing in on a solution.
Daniel Kulp wrote:
Oh. Yea. That would definitely do it. Good catch. Each client proxy
holds it's own conduit and thus the cookie for the session is stored
there is unique for each proxy.
Most likely, you will need to do some cookie management your self. Grab
the protocol headers from the response headers and set them in the
request headers for all the proxies. You can use the
org.apache.cxf.transport.http.Cookie class to help with the
parsing/setting.
Dan
On Friday 01 February 2008, Chris Campbell wrote:
The problem is that I get a different session for different
endpoints, maybe its how I set the client up? I do set the client up
in java code rather than with xml config, so maybe I am doing
something wrong there. Is it possible that each service interface is
getting a different http-conduit?
Daniel Kulp wrote:
On Friday 01 February 2008, Chris Campbell wrote:
I am using CXFServlet in tomcat, and intend to load balance
instances of them with apache mod_jk, and want to use sticky
sessions.
I figure I have to create a session somewhere, as I do not see a
session created (JSESSIONID ?) automatically. For reasons not worth
going into, I do not need the session for state, beyond making sure
that the sticky-ness works on the load-balancer.
I have tried getting the HttpServletRequest in an interceptor
(USER_LOGICAL phase) and creating an HttpSession if there is none,
and it seems to work.
The problem is that I have a few soap endpoints at different URLs,
and the session seems to be created for each endpoint, so calls to
Service /Foo gets on session and /Bar another. This causes my
sticky session load balancer to send /Foo to one of the load
balanced CXFServlet and /Bar to another .
Is there some way to create the Session so that it is valid for all
the service endpoints? Is setting the Session in an interceptor a
bad idea?
That should be completely fine assuming that works with tomcat.
This really is a tomcat question which I don't really know much
about. I would assume if all the endpoints are on the CXFServlet
instance they would have properly shared the session. If they are
in separate wars, maybe not. I don't know know enough about the
servlet spec to know what the rules are around that.
