You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Chris Campbell <cc...@quaris.com> on 2008/02/02 01:23:27 UTC
HttpSession and Endpoints
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?
Re: HttpSession and Endpoints
Posted by Daniel Kulp <dk...@apache.org>.
Chris,
That should be fine as long as your SessionManager is properly
re-entrant/thread safe.
Dan
On Sunday 03 February 2008, Chris Campbell wrote:
> If I understand the code correctly, the HttpConduit holds the
> session in a private field with no accessor method, and manages the
> session itself. So I think I have to use an interceptor to set the
> cookie on the other proxies.
>
> My current work around (I think similar to what you suggested) is to
> turn off the maintainSession on the conduit and have my own
> SessionManager that an inbound interceptor can access and set when
> the Set-Cookie comes back from the first request, and an outbound
> interceptor can access and set the cookie header for any other
> request, whichever proxy is making the request.
>
> So the SessionManager is stateful, but not the interceptors. But the
> interceptors do call into my application code, is that a bad practice?
>
> Willem Jiang wrote:
> > 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.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: HttpSession and Endpoints
Posted by Willem Jiang <wi...@gmail.com>.
Basically we store the stateful information into the message context,
and the interceptor get the stateful information from the message context.
Maybe you can put your own SessionManager into the message context and
pass it to the interceptor that you use.
Willem.
Chris Campbell wrote:
> If I understand the code correctly, the HttpConduit holds the
> session in a private field with no accessor method, and manages the
> session itself. So I think I have to use an interceptor to set the
> cookie on the other proxies.
>
> My current work around (I think similar to what you suggested) is to
> turn off the maintainSession on the conduit and have my own
> SessionManager that an inbound interceptor can access and set when
> the Set-Cookie comes back from the first request, and an outbound
> interceptor can access and set the cookie header for any other
> request, whichever proxy is making the request.
>
> So the SessionManager is stateful, but not the interceptors. But the
> interceptors do call into my application code, is that a bad practice?
>
> Willem Jiang wrote:
>
>> 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.
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: HttpSession and Endpoints
Posted by Chris Campbell <cc...@quaris.com>.
If I understand the code correctly, the HttpConduit holds the
session in a private field with no accessor method, and manages the
session itself. So I think I have to use an interceptor to set the
cookie on the other proxies.
My current work around (I think similar to what you suggested) is to
turn off the maintainSession on the conduit and have my own
SessionManager that an inbound interceptor can access and set when
the Set-Cookie comes back from the first request, and an outbound
interceptor can access and set the cookie header for any other
request, whichever proxy is making the request.
So the SessionManager is stateful, but not the interceptors. But the
interceptors do call into my application code, is that a bad practice?
Willem Jiang wrote:
> 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.
>>>>>
>>>
>>
>>
>
>
Re: HttpSession and Endpoints
Posted by Willem Jiang <wi...@gmail.com>.
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.
>>>>
>>
>
>
Re: HttpSession and Endpoints
Posted by Chris Campbell <cc...@quaris.com>.
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.
>
>
>
Re: HttpSession and Endpoints
Posted by Daniel Kulp <dk...@apache.org>.
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.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: HttpSession and Endpoints
Posted by Willem Jiang <wi...@gmail.com>.
Yes , CXF do not share the http conduit between the different client proxy.
If you want to share the session between the client proxy, I am afraid
you need to hack the CXF http conduit code to handle the cookie in you
application code.
Willem.
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.
>>
>>
>>
>>
>
>
Re: HttpSession and Endpoints
Posted by Chris Campbell <cc...@quaris.com>.
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.
>
>
>
Re: HttpSession and Endpoints
Posted by Daniel Kulp <dk...@apache.org>.
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.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog