You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2010/09/24 15:44:13 UTC
Re: [OT] In org.apache.catalina.connector.Request.doGetSession, java.lang.IllegalStateException:
Cannot create a session after the response has been committed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 9/24/2010 2:22 AM, Brian wrote:
> Well, IT WORKED!
Excellent.
> Now the previous thing that went wrong is able to show its details in the
> log. What is that? A Struts tag that tries to output the content of a bean
> that is not present even though it should (this is the Struts tag:
> <bean:write name="TEXT-NoteNoShippingFees"/>).
How is the bean declared in the page? Or, is it declared in one page and
used in another?
> That bean should always be present, because it is created in the previous
> Struts action.
Where is it stored? Remember that there are 4 scopes (in increasing
order of specificity): application, session, request, and page. If your
page is looking in request scope, but the bean is in the session, it
won't be found. Or, alternatively, if you store a bean in the request
and issue a redirect, then the bean has likely been discarded.
> How can it be missing SOMETIMES, if it is not the only bean
> that is being created in the previous action, and others of these beans that
> are created in the action are present in the page? I guess it has something
> to do with the buffer that gets full sometimes, or am I wrong? What do you
> think?
You'll have to give us more details. Note that this is not a Struts
forum, though many of us (including myself) have Struts experience and
would be glad to help. Technically, you ought to start a new thread
since you're asking about a new subject (this helps people find answers
to their questions when searching the archives).
> In fact, I have had LOTs of problems with beans that "dissappear" even
> though they should be present because they were created in the previous
> actions. I have been dealing with these "randomic" problem for YEARS, and I
> applied just a patch for that ("If the bean is not present, redirect to the
> home page instead of showing an error message and dumping a trace in the
> log"). That was just a workaround, and not a clean solution. I will try now
> to use a buffer with 16K, to see if that will solve this.
Could you also be experiencing session timeouts that aren't properly
handled? Does your application use any kind of authentication and
authorization? If not, you could easily be seeing visitors with expired
sessions accessing actions that expect the session to be in a certain state.
There are lots of ways to fix this kind of thing, but the remedies all
depend upon your requirements and application architecture.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkycqy0ACgkQ9CaO5/Lv0PDGMgCgktZRGzJLSmg6KLu1fMhu0G+J
66oAniuA/KNxzzRpYyJEqOgadZZ79tF2
=EjKC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] In org.apache.catalina.connector.Request.doGetSession, java.lang.IllegalStateException: Cannot create a session after the response has been committed
Posted by Brian <bb...@yahoo.com>.
Hi Wesley,
> -----Original Message-----
> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
> Sent: Friday, September 24, 2010 10:44 AM
> To: Tomcat Users List
> Subject: Re: [OT] In org.apache.catalina.connector.Request.doGetSession,
> java.lang.IllegalStateException: Cannot create a session after the
response
> has been committed
>
> On Fri, Sep 24, 2010 at 5:29 PM, Brian <bb...@yahoo.com> wrote:
> > Hi Christoper,
> >
>
> > The sessions expire if 2 hours have passed, and if that happens, the
system
> forwards them to another page.
> > I mean, in my programming I already considered what should happen if the
> session suddenly expired, and it should not arrive to this point.
> >
> > Thanks!
> >
>
> You can't be sure that's whats happening though. The browser can make its
> own rules with session cookies. Unlikely but possible for the cookies to
be
> deleted sometimes. Some people may not accept session cookies in the first
> place.
That is interesting. I think I need to study that subject...
Oh, regarding people not accepting cookies: Struts then mantains a
jsessionid in the URL.
> Are you encoding the urls for sessions too? Where's the bean being set in
an
> Interceptor, in a filter, on an earlier page in the session? Is it
possible that
> you've missed a route to the pages which should always have this bean?
I use Struts. All my URLs are actions (.do). So for all of them, a java code
is executed, whish creates the bean and stores it in the session.
> Is it possible that people are directly navigating to the page that throws
the
> error (say via a bookmark, or got a cached search engine result)?
I already considered that in my programming, years ago. If they do, it doesn
matter. The actions still execute given that they access a ".do" and not a
".jsp", and the bean gets created immediately before, before the JSP is sent
to the response. And if other beans that should be present (because they
should have been created, if they followed a regular path of actions in my
site) are not present, the client is redirected to the home page.
That certainly happens a lot, given that my site gets thousands of request
from the crawlers such as GoogleBot! And they do whatever they want,
certainly.
> My advise would be (assuming you have an access log enabled that contains
> the session id). Look at the access log. Try to figure out the route the
person
> took through your site. How long between page views? Was there some
> detail that they entered in the bean which was unserialiasble etc.
GOOD IDEA! I will do it!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] In org.apache.catalina.connector.Request.doGetSession,
java.lang.IllegalStateException: Cannot create a session after the response
has been committed
Posted by Wesley Acheson <we...@gmail.com>.
On Fri, Sep 24, 2010 at 5:29 PM, Brian <bb...@yahoo.com> wrote:
> Hi Christoper,
>
> The sessions expire if 2 hours have passed, and if that happens, the system forwards them to another page.
> I mean, in my programming I already considered what should happen if the session suddenly expired, and it should not arrive to this point.
>
> Thanks!
>
You can't be sure that's whats happening though. The browser can make
its own rules with session cookies. Unlikely but possible for the
cookies to be deleted sometimes. Some people may not accept session
cookies in the first place.
Are you encoding the urls for sessions too? Where's the bean being set
in an Interceptor, in a filter, on an earlier page in the session? Is
it possible that you've missed a route to the pages which should
always have this bean?
Is it possible that people are directly navigating to the page that
throws the error (say via a bookmark, or got a cached search engine
result)?
My advise would be (assuming you have an access log enabled that
contains the session id). Look at the access log. Try to figure out
the route the person took through your site. How long between page
views? Was there some detail that they entered in the bean which was
unserialiasble etc.
I doubt anyone here can tell you the answer to your new problem, it
too dependant on your new environment, however hopefully we will point
you in a good direction to start looking. Also you can start a new
thread as Christopher put but mark it OT. (if you don't believe tomcat
is at fault).
Regards,
Wesley Acheson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] In org.apache.catalina.connector.Request.doGetSession, java.lang.IllegalStateException:
Cannot create a session after the response has been committed
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 9/24/2010 3:38 PM, Brian wrote:
> At least the "can't create session if response has been commited" has
> been solved totally. That is great!!!
Yup. Now you can see all those error messages you've been missing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyc/wAACgkQ9CaO5/Lv0PCiwQCgsfaU6xOj4Dn5NsMLKtiaAC77
Fe0AoKre/bNzU86Gk1/TRrTpKkWMtyJf
=s67J
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] In org.apache.catalina.connector.Request.doGetSession, java.lang.IllegalStateException: Cannot create a session after the response has been committed
Posted by Brian <bb...@yahoo.com>.
Well... I must say that it looks like you are really an expert! I need to check again my app in order to be able to respond all your questions. I started it 5 years ago, so there are a lot of details that I programmed long time ago, and once they seemed to work fine, I gradually forgot about them.
But... for now, it SEEMS that the "dissapearing beans" issue is not happening anymore. However, it takes more time to be sure. Maybe I have been like lucky, and they will happen anytime soon.
At least the "can't create session if response has been commited" has been solved totally. That is great!!!
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, September 24, 2010 12:11 PM
> To: Tomcat Users List
> Subject: Re: [OT] In org.apache.catalina.connector.Request.doGetSession,
> java.lang.IllegalStateException: Cannot create a session after the response
> has been committed
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian,
>
> On 9/24/2010 11:29 AM, Brian wrote:
> >> -----Original Message-----
> >> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> >> Sent: Friday, September 24, 2010 08:44 AM
> >>
> >> Where is it stored? Remember that there are 4 scopes (in increasing
> >> order of
> >> specificity): application, session, request, and page. If your page
> >> is looking in request scope, but the bean is in the session, it won't
> >> be found. Or, alternatively, if you store a bean in the request and
> >> issue a redirect, then the bean has likely been discarded.
> >
> > It is stored in the session, just because I wanted to avoid the
> > problems that happen when you redirect.
>
> Are you sure that the user is hanging-on to the session? If the client doesn't
> support cookies, are you properly issuing a redirect? (If you use Struts's
> ActionForward with redirect=true in S1 or if you use a <result
> type="redirect"> in S2 then you should be okay).
>
> > That makes me think that the "buffer full, then flushed"
> > is maybe the reason why the bean dissappears somehow.
>
> Very unlikely: the bean is put into the session far earlier than the error occurs,
> and the session shouldn't be damaged by anything like what you describe.
>
> >> Could you also be experiencing session timeouts that aren't properly
> >> handled? Does your application use any kind of authentication and
> >> authorization? If not, you could easily be seeing visitors with
> >> expired sessions accessing actions that expect the session to be in a
> certain state.
> >
> > The sessions expire if 2 hours have passed, and if that happens, the
> > system forwards them to another page.
>
> How is that done? Not the forward... the detection of session expiration.
>
> > I mean, in my programming I already considered what should happen if
> > the session suddenly expired, and it should not arrive to this point.
>
> But it might end up there anyway :)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyc25YACgkQ9CaO5/Lv0PC81gCgo/rUKOR7kbFCpShpxaKDfb
> 65
> a6IAmwfqbITWH7w54XGfc2mtVj3/RZHH
> =tD97
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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: [OT] In org.apache.catalina.connector.Request.doGetSession, java.lang.IllegalStateException:
Cannot create a session after the response has been committed
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 9/24/2010 11:29 AM, Brian wrote:
>> -----Original Message-----
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Sent: Friday, September 24, 2010 08:44 AM
>>
>> Where is it stored? Remember that there are 4 scopes (in increasing order of
>> specificity): application, session, request, and page. If your page is looking in
>> request scope, but the bean is in the session, it won't be found. Or,
>> alternatively, if you store a bean in the request and issue a redirect, then the
>> bean has likely been discarded.
>
> It is stored in the session, just because I wanted to avoid the
> problems that happen when you redirect.
Are you sure that the user is hanging-on to the session? If the client
doesn't support cookies, are you properly issuing a redirect? (If you
use Struts's ActionForward with redirect=true in S1 or if you use a
<result type="redirect"> in S2 then you should be okay).
> That makes me think that the "buffer full, then flushed"
> is maybe the reason why the bean dissappears somehow.
Very unlikely: the bean is put into the session far earlier than the
error occurs, and the session shouldn't be damaged by anything like what
you describe.
>> Could you also be experiencing session timeouts that aren't properly
>> handled? Does your application use any kind of authentication and
>> authorization? If not, you could easily be seeing visitors with expired sessions
>> accessing actions that expect the session to be in a certain state.
>
> The sessions expire if 2 hours have passed, and if that happens, the
> system forwards them to another page.
How is that done? Not the forward... the detection of session expiration.
> I mean, in my programming I already considered what should happen if
> the session suddenly expired, and it should not arrive to this point.
But it might end up there anyway :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyc25YACgkQ9CaO5/Lv0PC81gCgo/rUKOR7kbFCpShpxaKDfb65
a6IAmwfqbITWH7w54XGfc2mtVj3/RZHH
=tD97
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] In org.apache.catalina.connector.Request.doGetSession, java.lang.IllegalStateException: Cannot create a session after the response has been committed
Posted by Brian <bb...@yahoo.com>.
Hi Christoper,
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, September 24, 2010 08:44 AM
> To: Tomcat Users List
> Subject: Re: [OT] In org.apache.catalina.connector.Request.doGetSession,
> java.lang.IllegalStateException: Cannot create a session after the response
> has been committed
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian,
>
> On 9/24/2010 2:22 AM, Brian wrote:
> > Well, IT WORKED!
>
> Excellent.
>
> > Now the previous thing that went wrong is able to show its details in
> > the log. What is that? A Struts tag that tries to output the content
> > of a bean that is not present even though it should (this is the Struts tag:
> > <bean:write name="TEXT-NoteNoShippingFees"/>).
>
> How is the bean declared in the page? Or, is it declared in one page and used
> in another?
The previous Struts actions places it in the session object.
> > That bean should always be present, because it is created in the
> > previous Struts action.
>
> Where is it stored? Remember that there are 4 scopes (in increasing order of
> specificity): application, session, request, and page. If your page is looking in
> request scope, but the bean is in the session, it won't be found. Or,
> alternatively, if you store a bean in the request and issue a redirect, then the
> bean has likely been discarded.
It is stored in the session, just because I wanted to avoid the problems that happen when you redirect. That means that the bean will consume memory while the session is alive (instead of just for the time the request or response is alive), but memory is not a big issue here.
That makes me think that the "buffer full, then flushed" is maybe the reason why the bean dissappears somehow.
I have increased the buffer from 8k to 64k, and I will keep an eye on the log to see if it still happens.
> > How can it be missing SOMETIMES, if it is not the only bean that is
> > being created in the previous action, and others of these beans that
> > are created in the action are present in the page? I guess it has
> > something to do with the buffer that gets full sometimes, or am I
> > wrong? What do you think?
>
> You'll have to give us more details. Note that this is not a Struts forum,
> though many of us (including myself) have Struts experience and would be
> glad to help. Technically, you ought to start a new thread since you're asking
> about a new subject (this helps people find answers to their questions when
> searching the archives).
You are right. If the problem still exists, I will seach for a solution in another source dedicated to Struts. This is no more related to Tomcat directly.
> > In fact, I have had LOTs of problems with beans that "dissappear" even
> > though they should be present because they were created in the
> > previous actions. I have been dealing with these "randomic" problem
> > for YEARS, and I applied just a patch for that ("If the bean is not
> > present, redirect to the home page instead of showing an error message
> > and dumping a trace in the log"). That was just a workaround, and not
> > a clean solution. I will try now to use a buffer with 16K, to see if that will
> solve this.
>
> Could you also be experiencing session timeouts that aren't properly
> handled? Does your application use any kind of authentication and
> authorization? If not, you could easily be seeing visitors with expired sessions
> accessing actions that expect the session to be in a certain state.
The sessions expire if 2 hours have passed, and if that happens, the system forwards them to another page.
I mean, in my programming I already considered what should happen if the session suddenly expired, and it should not arrive to this point.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org