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:ch...@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:ch...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
