1.3.4 fixed this issue.... >From the release notes [1]:
* cross session leakage due to a dangling thread local in exceptional circumstances * memory leak in localizer (WICKET-1667) Martijn [1] http://wicket.apache.org/news.html#News-ApacheWicket1.3.4released%21 On Fri, Jan 8, 2010 at 2:56 PM, Martijn Dashorst <[email protected]> wrote: > There has been a session leak somewhere in 1.3 iirc. This has to do > with the thread locals that store Session, RequestCycle and > Application during a request not being removed correctly. > > Martijn > > On Fri, Jan 8, 2010 at 2:38 PM, allgo <[email protected]> wrote: >> >> ok will do. >> But just a question to the experts - have you heard of this issue before? >> I went through the links below >> http://old.nabble.com/Storing-user-entity-in-session--tt22113666.html#a22113666 >> http://old.nabble.com/Wicket-Session-and-threading-tt14595666.html#a14599963 >> >> >> and apparently storing hibernate session object in wicket session was >> causing similar issues. >> Am doing the same and could this be one possible reason. >> >> I will try an upgrade, but unfortunately as I told I had tried for long to >> replicate this is dev but in vain. Only way could be to release in Live and >> test. But that would need quite a bit of convincing of my superiors (which >> is a bit tricky for a junior developer like me - the application had been >> coded and released 2 yrs back and no upgrade doen since those developers >> left !! :-) ). But worth a shot. >> >> If it is a hibernate issue I can store the account Id instead of teh Account >> object itself in wicket session and do a minor release. >> >> I will try an upgrade for 1.3.7 in the mean time in dev and see if I need >> any code / API changes. >> >> Regards, >> Soumya >> >> >> >> Martijn Dashorst wrote: >>> >>> Seriously... *BETA*? upgrade and then come back if things are still wrong. >>> >>> Martijn >>> >>> On Fri, Jan 8, 2010 at 1:21 PM, allgo <[email protected]> wrote: >>>> >>>> 1.3.0-beta3 actually. Copied it from the Manifest file >>>> >>>> Martijn Dashorst wrote: >>>>> >>>>> 1.3.0? >>>>> >>>>> Martijn >>>>> >>>>> On Fri, Jan 8, 2010 at 1:12 PM, allgo <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> The wicket version is 1.3. Sorry should have mentioned that. >>>>>> >>>>>> As such the User A, after he logs on is getting assigned the Account >>>>>> object >>>>>> of User B. And after soem logs we can see that User B had logged on a >>>>>> while >>>>>> before. Hence that Accoutn object was definitely fetched a whiel >>>>>> before. >>>>>> I >>>>>> did see a few threads which say Hibernate may eb a culprit but am not >>>>>> sure >>>>>> thats the case here. >>>>>> >>>>>> Please do let me know if you need any more info. >>>>>> Thanks, >>>>>> SSP >>>>>> >>>>>> Martijn Dashorst wrote: >>>>>>> >>>>>>> A wicket version number would be helpful... >>>>>>> >>>>>>> Martijn >>>>>>> >>>>>>> On Fri, Jan 8, 2010 at 12:17 PM, Soumya <[email protected]> >>>>>>> wrote: >>>>>>>> Hi all, >>>>>>>> I am fairly a newbie in wicket and would appreciate your help! >>>>>>>> >>>>>>>> I >>>>>>>> have a wicket application which are used on Live by more than 500 >>>>>>>> users. Now the problem which has arisen is - say User A logs on - he >>>>>>>> is >>>>>>>> able to view details of User B. It has happened for different users >>>>>>>> and >>>>>>>> I am trying to dig the real reason. >>>>>>>> >>>>>>>> Here is my code details - >>>>>>>> 1) I use Hibernate to fetch 'Account' objects from backend passing on >>>>>>>> the >>>>>>>> username/password. >>>>>>>> >>>>>>>> 2) I use >>>>>>>> MyAppSession extends WebSession >>>>>>>> { >>>>>>>> private Account account; >>>>>>>> >>>>>>>> public InboundSession(Request request) >>>>>>>> { >>>>>>>> super(request); >>>>>>>> } >>>>>>>> >>>>>>>> public void setAccount(Account account) >>>>>>>> { >>>>>>>> this.account = account; >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> public Account getAccount() >>>>>>>> { >>>>>>>> return account; >>>>>>>> } >>>>>>>> >>>>>>>> public boolean isUserLoggedIn() >>>>>>>> { >>>>>>>> return account !=null; >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> So >>>>>>>> effectively I check if the Account object in session is null or not >>>>>>>> and >>>>>>>> accordingly decide whether a user is logged in or not. >>>>>>>> >>>>>>>> 2) In Login class I pass on the username/password to >>>>>>>> HibernateAccountDao >>>>>>>> and fetch the Account object. >>>>>>>> Account account = accountDao.getAccount(username, password) >>>>>>>> MyAppSession session = (MyAppSession )getSession(); >>>>>>>> session.setAccount(account); >>>>>>>> setResponsePage(Home.class); >>>>>>>> >>>>>>>> So effectively I fetch the accout object using hibernate and store it >>>>>>>> in >>>>>>>> wicket session. >>>>>>>> But I am not sure how these account objects are getting mixed up >>>>>>>> between >>>>>>>> users. >>>>>>>> >>>>>>>> Please can someone lead me to the route cause of the issue? >>>>>>>> >>>>>>>> >>>>>>>> Thanks in advance! >>>>>>>> SSP >>>>>>>> >>>>>>>> >>>>>>>> The INTERNET now has a personality. YOURS! See your Yahoo! >>>>>>>> Homepage. >>>>>>>> http://in.yahoo.com/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>>>>>> Apache Wicket 1.4 increases type safety for web applications >>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075050.html >>>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>>>> Apache Wicket 1.4 increases type safety for web applications >>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075144.html >>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> >>> -- >>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>> Apache Wicket 1.4 increases type safety for web applications >>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27076056.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.4 increases type safety for web applications > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
