You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jeff Thorn <je...@thorntechnologies.com> on 2010/09/23 21:04:06 UTC
Automatically Add Session ID
Hello,
I have a stateless webservice that I am running with Tomcat 6.0. The
product owners want to start tracking user sessions to the webservice
(how many request per session, etc.). Since its been stateless up to
this point, I am not using the HttpSession object at all. Is there any
way I can add a session id automatically just by changing the Tomcat
configuration?
If I can't do it via config, I assume I can do if via code simply by calling:
httpRequest.getSession(true);
with each request. All I really care about is the session ID so we can
log and group requests. I am not going to store any objects in the
session. What kind of overhead is there to doing this? I know it
defeats the purpose of being stateless. But if I don't put anything in
the session will it have a relatively low impact?
Thanks!
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Automatically Add Session ID
Posted by Wesley Acheson <we...@gmail.com>.
On Thu, Sep 23, 2010 at 10:13 PM, Jeff Thorn <je...@thorntechnologies.com> wrote:
> Hi Max. Thanks for your response.
>
> I am sure there are no sessions now. Its a REST based XML API.
What type of client is going to use the REST API? If its not browser
based it may well not accept sessions. Thus you would have several
session id's for the same client.
Also the overhead is low.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Automatically Add Session ID
Posted by Jeff Thorn <je...@thorntechnologies.com>.
Thanks Chis. I'll make sure the AccessLogValve is configured
correctly. Currently the app is not clustered. It it ever becomes
clustered, I will make sure we keep this in mind.
On Thu, Sep 23, 2010 at 4:47 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeff,
>
> I've re-arranged some of your comments so that my questions make a bit
> more sense.
>
> On 9/23/2010 4:13 PM, Jeff Thorn wrote:
>> I am sure there are no sessions now. Its a REST based XML API.
>>
>> So my question is what kind of overhead does getSession() have? If its
>> anything more than just generating an uid and settings a response
>> header, I will just do that myself. But I would rather not reinvent
>> the wheel since the session api does exactly what I want.
>
> Is this clustered at all? If you are using a cluster and want your
> session ids to be consistent, then there can be some overhead in
> notifying the other servers that a new session has been created, etc.
> Other than that, creating empty sessions and referencing them with every
> request is going to have a pretty minimal impact unless your webapp does
> very little with each request (like a web service that adds to numbers
> provided by the client). Things like file and database access
> overwhelmingly dominate the equation.
>
>> The session id will simply end
>> up in the access log files so we can group by and count unique
>> sessions.
>
> Session ids don't typically show up in access log files: you'll have to
> configure your logging to do this. The AccessLogValve can certainly do
> this for you.
>
>> The clients of the API do support cookies and will return
>> the session id in subsequent requests.
>
> Perfect: that will pretty much be a requirement, unless the clients are
> willing to accept a session id some other way and then add
> ";jsessionid=[the session id]" to the end of every request URL they use.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkybvN0ACgkQ9CaO5/Lv0PBlJACgoBwpy4KeIop2VI7i+KinvnG9
> DBQAoIG8hy9F/1AlQd2z+SVZ6jA3e+XM
> =1tse
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jeff Thorn
Thorn Technologies, LLC
(443) 255-2803
jeff@thorntechnologies.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Automatically Add Session ID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff,
I've re-arranged some of your comments so that my questions make a bit
more sense.
On 9/23/2010 4:13 PM, Jeff Thorn wrote:
> I am sure there are no sessions now. Its a REST based XML API.
>
> So my question is what kind of overhead does getSession() have? If its
> anything more than just generating an uid and settings a response
> header, I will just do that myself. But I would rather not reinvent
> the wheel since the session api does exactly what I want.
Is this clustered at all? If you are using a cluster and want your
session ids to be consistent, then there can be some overhead in
notifying the other servers that a new session has been created, etc.
Other than that, creating empty sessions and referencing them with every
request is going to have a pretty minimal impact unless your webapp does
very little with each request (like a web service that adds to numbers
provided by the client). Things like file and database access
overwhelmingly dominate the equation.
> The session id will simply end
> up in the access log files so we can group by and count unique
> sessions.
Session ids don't typically show up in access log files: you'll have to
configure your logging to do this. The AccessLogValve can certainly do
this for you.
> The clients of the API do support cookies and will return
> the session id in subsequent requests.
Perfect: that will pretty much be a requirement, unless the clients are
willing to accept a session id some other way and then add
";jsessionid=[the session id]" to the end of every request URL they use.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkybvN0ACgkQ9CaO5/Lv0PBlJACgoBwpy4KeIop2VI7i+KinvnG9
DBQAoIG8hy9F/1AlQd2z+SVZ6jA3e+XM
=1tse
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Automatically Add Session ID
Posted by Maximilian Stocker <ma...@talentoyster.com>.
Don't reinvent the wheel use sessions. Whatever miniscule overhead there might be is worth it. There is the whole timeout aspect and you can add listeners (for session events) down the road if you desired all of which you would additionally have to recreate.
Plus you can be sure that by now sessions have been pretty thoroughly tested... :)
As an aside I am not sure why stateless translated into no views during your development process. The XML you are sending is a view. Anyway. Just a comment and feel free to ignore.
-----Original Message-----
From: Jeff Thorn [mailto:jeff@thorntechnologies.com]
Sent: Thursday, September 23, 2010 4:13 PM
To: Tomcat Users List
Subject: Re: Automatically Add Session ID
Hi Max. Thanks for your response.
I am sure there are no sessions now. Its a REST based XML API. There
are no views or jsp pages at all. It was designed from scratch to be
stateless. I truly don't even like the idea of adding a session id
either. But that is out of my control. The session id will simply end
up in the access log files so we can group by and count unique
sessions. The clients of the API do support cookies and will return
the session id in subsequent requests.
So my question is what kind of overhead does getSession() have? If its
anything more than just generating an uid and settings a response
header, I will just do that myself. But I would rather not reinvent
the wheel since the session api does exactly what I want.
On Thu, Sep 23, 2010 at 3:59 PM, Maximilian Stocker
<ma...@talentoyster.com> wrote:
> How are you planning on logging/tracking this information anyway?
>
> My thinking would be to use a filter for all requests. And then you can do what you want with the information in the filter. And getSession() is to me clearer.
>
> A couple of other things though.
>
> 1) Are you sure you don't have sessions now? I am not asking if you are using them but are you sure they don't exist? By default when you have JSPs involved at any point you'll have sessions.
>
> 2) I'd be mildly concerned with a "stateless" webservice trying to track usage via sessions because one way or another (cookies or URL) sessions *require* client co-operation to work and it's possible that you don't have that. I would check that assumption before continuing.
>
> -----Original Message-----
> From: Jeff Thorn [mailto:jeff@thorntechnologies.com]
> Sent: Thursday, September 23, 2010 3:04 PM
> To: users@tomcat.apache.org
> Subject: Automatically Add Session ID
>
> Hello,
> I have a stateless webservice that I am running with Tomcat 6.0. The
> product owners want to start tracking user sessions to the webservice
> (how many request per session, etc.). Since its been stateless up to
> this point, I am not using the HttpSession object at all. Is there any
> way I can add a session id automatically just by changing the Tomcat
> configuration?
>
> If I can't do it via config, I assume I can do if via code simply by calling:
>
> httpRequest.getSession(true);
>
> with each request. All I really care about is the session ID so we can
> log and group requests. I am not going to store any objects in the
> session. What kind of overhead is there to doing this? I know it
> defeats the purpose of being stateless. But if I don't put anything in
> the session will it have a relatively low impact?
>
> Thanks!
> Jeff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jeff Thorn
Thorn Technologies, LLC
(443) 255-2803
jeff@thorntechnologies.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Automatically Add Session ID
Posted by Jeff Thorn <je...@thorntechnologies.com>.
Hi Max. Thanks for your response.
I am sure there are no sessions now. Its a REST based XML API. There
are no views or jsp pages at all. It was designed from scratch to be
stateless. I truly don't even like the idea of adding a session id
either. But that is out of my control. The session id will simply end
up in the access log files so we can group by and count unique
sessions. The clients of the API do support cookies and will return
the session id in subsequent requests.
So my question is what kind of overhead does getSession() have? If its
anything more than just generating an uid and settings a response
header, I will just do that myself. But I would rather not reinvent
the wheel since the session api does exactly what I want.
On Thu, Sep 23, 2010 at 3:59 PM, Maximilian Stocker
<ma...@talentoyster.com> wrote:
> How are you planning on logging/tracking this information anyway?
>
> My thinking would be to use a filter for all requests. And then you can do what you want with the information in the filter. And getSession() is to me clearer.
>
> A couple of other things though.
>
> 1) Are you sure you don't have sessions now? I am not asking if you are using them but are you sure they don't exist? By default when you have JSPs involved at any point you'll have sessions.
>
> 2) I'd be mildly concerned with a "stateless" webservice trying to track usage via sessions because one way or another (cookies or URL) sessions *require* client co-operation to work and it's possible that you don't have that. I would check that assumption before continuing.
>
> -----Original Message-----
> From: Jeff Thorn [mailto:jeff@thorntechnologies.com]
> Sent: Thursday, September 23, 2010 3:04 PM
> To: users@tomcat.apache.org
> Subject: Automatically Add Session ID
>
> Hello,
> I have a stateless webservice that I am running with Tomcat 6.0. The
> product owners want to start tracking user sessions to the webservice
> (how many request per session, etc.). Since its been stateless up to
> this point, I am not using the HttpSession object at all. Is there any
> way I can add a session id automatically just by changing the Tomcat
> configuration?
>
> If I can't do it via config, I assume I can do if via code simply by calling:
>
> httpRequest.getSession(true);
>
> with each request. All I really care about is the session ID so we can
> log and group requests. I am not going to store any objects in the
> session. What kind of overhead is there to doing this? I know it
> defeats the purpose of being stateless. But if I don't put anything in
> the session will it have a relatively low impact?
>
> Thanks!
> Jeff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jeff Thorn
Thorn Technologies, LLC
(443) 255-2803
jeff@thorntechnologies.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Automatically Add Session ID
Posted by Maximilian Stocker <ma...@talentoyster.com>.
How are you planning on logging/tracking this information anyway?
My thinking would be to use a filter for all requests. And then you can do what you want with the information in the filter. And getSession() is to me clearer.
A couple of other things though.
1) Are you sure you don't have sessions now? I am not asking if you are using them but are you sure they don't exist? By default when you have JSPs involved at any point you'll have sessions.
2) I'd be mildly concerned with a "stateless" webservice trying to track usage via sessions because one way or another (cookies or URL) sessions *require* client co-operation to work and it's possible that you don't have that. I would check that assumption before continuing.
-----Original Message-----
From: Jeff Thorn [mailto:jeff@thorntechnologies.com]
Sent: Thursday, September 23, 2010 3:04 PM
To: users@tomcat.apache.org
Subject: Automatically Add Session ID
Hello,
I have a stateless webservice that I am running with Tomcat 6.0. The
product owners want to start tracking user sessions to the webservice
(how many request per session, etc.). Since its been stateless up to
this point, I am not using the HttpSession object at all. Is there any
way I can add a session id automatically just by changing the Tomcat
configuration?
If I can't do it via config, I assume I can do if via code simply by calling:
httpRequest.getSession(true);
with each request. All I really care about is the session ID so we can
log and group requests. I am not going to store any objects in the
session. What kind of overhead is there to doing this? I know it
defeats the purpose of being stateless. But if I don't put anything in
the session will it have a relatively low impact?
Thanks!
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org