Re: SessionStore on database
Hi On Wed, Apr 29, 2020, 19:55 Andrea Del Bene wrote: > Hi, > > if you haven't done it yet you should have a look at WicketStuff data > store projects: > > https://github.com/wicketstuff/core/tree/master/datastores-parent > > > this should give you some good ideas. > The data stores distribute the pages. Something else should be used to distribute the http sessions. > On 29/04/20 17:30, Shengche Hsiao wrote: > > Thomas, thanks for your opinion, I'll try it > > > > On Wed, Apr 29, 2020 at 2:49 PM Thomas Heigl > wrote: > > > >> Hi, > >> > >> There are two options I'm aware of: > >> > >> - You can use a session manager in your application server that stores > your > >> session in the database. I.e. Tomcat's JDBC store. > >> - You can use Spring Session with a JDBC store > >> > >> I recently implemented Spring Session for Wicket with Redis as a backing > >> store. There are minor issues with page locking that require some custom > >> code, but otherwise it works fine. > >> > >> Best regards, > >> > >> Thomas > >> > >> On Wed, Apr 29, 2020 at 5:30 AM ShengChe Hsiao > wrote: > >> > >>> Dear all > >>> > >>> I want to implement cross datacenter session replication for my web > app, > >>> can I persist session on shared database? If it does, how can I do? > >>> > >>> I searched the web, and found org.apache.wicket.protocol.http. > >>> SecondLevelCacheSessionStore.IClusteredPageStore > >>> > >>> I have an idea for implement above interface and persist session on > >> target > >>> database, right? > >>> > >>> > >>> ---> > >>> To boldly go where no man has gone before. > >>> > >>> ---> > >>> We do this not because it is easy. We do this because it is hard. > >>> - > >>> --> > >>> If I have seen further it is by standing on the shoulders of giants. > >>> -- > >>> -> > >>> front...@gmail.com > >>> > >>> > >> > -> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: SessionStore on database
Hi, if you haven't done it yet you should have a look at WicketStuff data store projects: https://github.com/wicketstuff/core/tree/master/datastores-parent this should give you some good ideas. On 29/04/20 17:30, Shengche Hsiao wrote: Thomas, thanks for your opinion, I'll try it On Wed, Apr 29, 2020 at 2:49 PM Thomas Heigl wrote: Hi, There are two options I'm aware of: - You can use a session manager in your application server that stores your session in the database. I.e. Tomcat's JDBC store. - You can use Spring Session with a JDBC store I recently implemented Spring Session for Wicket with Redis as a backing store. There are minor issues with page locking that require some custom code, but otherwise it works fine. Best regards, Thomas On Wed, Apr 29, 2020 at 5:30 AM ShengChe Hsiao wrote: Dear all I want to implement cross datacenter session replication for my web app, can I persist session on shared database? If it does, how can I do? I searched the web, and found org.apache.wicket.protocol.http. SecondLevelCacheSessionStore.IClusteredPageStore I have an idea for implement above interface and persist session on target database, right? ---> To boldly go where no man has gone before. ---> We do this not because it is easy. We do this because it is hard. - --> If I have seen further it is by standing on the shoulders of giants. -- -> front...@gmail.com -> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore on database
Thomas, thanks for your opinion, I'll try it On Wed, Apr 29, 2020 at 2:49 PM Thomas Heigl wrote: > Hi, > > There are two options I'm aware of: > > - You can use a session manager in your application server that stores your > session in the database. I.e. Tomcat's JDBC store. > - You can use Spring Session with a JDBC store > > I recently implemented Spring Session for Wicket with Redis as a backing > store. There are minor issues with page locking that require some custom > code, but otherwise it works fine. > > Best regards, > > Thomas > > On Wed, Apr 29, 2020 at 5:30 AM ShengChe Hsiao wrote: > > > Dear all > > > > I want to implement cross datacenter session replication for my web app, > > can I persist session on shared database? If it does, how can I do? > > > > I searched the web, and found org.apache.wicket.protocol.http. > > SecondLevelCacheSessionStore.IClusteredPageStore > > > > I have an idea for implement above interface and persist session on > target > > database, right? > > > > > > ---> > > To boldly go where no man has gone before. > > > > ---> > > We do this not because it is easy. We do this because it is hard. > > - > > --> > > If I have seen further it is by standing on the shoulders of giants. > > -- > > -> > > front...@gmail.com > > > > > -> > > > -- ---> We do this not because it is easy. We do this because it is hard. ---> ShengChe Hsiao ---> front...@gmail.com front...@tc.edu.tw ---> VoIP : 070-910-2450 --->
Re: SessionStore on database
Hi, There are two options I'm aware of: - You can use a session manager in your application server that stores your session in the database. I.e. Tomcat's JDBC store. - You can use Spring Session with a JDBC store I recently implemented Spring Session for Wicket with Redis as a backing store. There are minor issues with page locking that require some custom code, but otherwise it works fine. Best regards, Thomas On Wed, Apr 29, 2020 at 5:30 AM ShengChe Hsiao wrote: > Dear all > > I want to implement cross datacenter session replication for my web app, > can I persist session on shared database? If it does, how can I do? > > I searched the web, and found org.apache.wicket.protocol.http. > SecondLevelCacheSessionStore.IClusteredPageStore > > I have an idea for implement above interface and persist session on target > database, right? > > > ---> > To boldly go where no man has gone before. > > ---> > We do this not because it is easy. We do this because it is hard. > - > --> > If I have seen further it is by standing on the shoulders of giants. > -- > -> > front...@gmail.com > > -> >
SessionStore on database
Dear all I want to implement cross datacenter session replication for my web app, can I persist session on shared database? If it does, how can I do? I searched the web, and found org.apache.wicket.protocol.http. SecondLevelCacheSessionStore.IClusteredPageStore I have an idea for implement above interface and persist session on target database, right? ---> To boldly go where no man has gone before. ---> We do this not because it is easy. We do this because it is hard. - --> If I have seen further it is by standing on the shoulders of giants. -- -> front...@gmail.com ->
Re: SessionStore
Great wasnt sure if it were memory only.. 2012/10/2 Martin Grigorov > org.apache.wicket.pageStore.memory.HttpSessionDataStore > > On Tue, Oct 2, 2012 at 3:49 PM, nino martinez wael > wrote: > > Hi > > > > Are there a memory only session store? I am seeing a lot of writes from > > tomcat, and wanted to see if using a different session store would help.. > > we are using LDM's extensively. > > > > -- > > Best regards / Med venlig hilsen > > Nino Martinez > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Best regards / Med venlig hilsen Nino Martinez
Re: SessionStore
org.apache.wicket.pageStore.memory.HttpSessionDataStore On Tue, Oct 2, 2012 at 3:49 PM, nino martinez wael wrote: > Hi > > Are there a memory only session store? I am seeing a lot of writes from > tomcat, and wanted to see if using a different session store would help.. > we are using LDM's extensively. > > -- > Best regards / Med venlig hilsen > Nino Martinez -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore life cycle in cluster?
On Fri, Jun 4, 2010 at 10:32 PM, DmitryM wrote: > > Igor, > > Can you please comment on the following couple of points I got? > > 1. "Pulling session from memcached node": I double checked the > recommendation and it looks like fetching session from the memcached node > doesn't take much time (around 200ms at most). But there was a > recommendation about immediate session attributes deserialization after > session replication > (http://apache-wicket.1842946.n4.nabble.com/A-few-clustering-questions-td1863992.html#a1863993). > Do you think it may be a potential issue causing the request processing > delay I experienced? i would use a profiler and see where the time goes, that way you dont have to guess. > 2. The memcached-session-manager's developer suggested I could try to use > plain HttpSessionStore (instead of default SecondLevelCacheSessionStore). > But when I tried his suggestion I got the following stacktrace: > > java.lang.ExceptionInInitializerError ... > which is caused by the Injector usage in one of the classes used by a Page. > Why do you think Application.get() method may blow up? Why isn't the > ThreadLocal application instance get set? unless memcached serializer works asynchronously in its own thread. -igor > > Thanks, > Dmitry > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2244022.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore life cycle in cluster?
m.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes(JavaSerializationTranscoder.java:177) at de.javakaffee.web.msm.TranscoderService.deserializeAttributes(TranscoderService.java:156) at de.javakaffee.web.msm.TranscoderService.deserialize(TranscoderService.java:113) at de.javakaffee.web.msm.MemcachedBackupSessionManager.loadFromMemcached(MemcachedBackupSessionManager.java:736) at de.javakaffee.web.msm.MemcachedBackupSessionManager.findSession(MemcachedBackupSessionManager.java:481) at org.apache.catalina.connector.Request.doGetSession(Request.java:2363) at org.apache.catalina.connector.Request.getSession(Request.java:2098) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:82) at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:75) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:356) at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:150) at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237) at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.mobioid.core.utils.UserLocaleFilter.doFilter(UserLocaleFilter.java:34) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at de.javakaffee.web.msm.SessionTrackerValve.invoke(SessionTrackerValve.java:90) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:637) Caused by: org.apache.wicket.WicketRuntimeException: There is no application attached to current thread http-8082-7 at org.apache.wicket.Application.get(Application.java:179) at org.apache.wicket.injection.web.InjectorHolder.getInjector(InjectorHolder.java:67) at com.mobioid.modules.payment.ui.manage.organization.OrganizationController.(OrganizationController.java:56) at com.mobioid.modules.payment.ui.manage.organization.OrganizationController.(OrganizationController.java:59) ... 91 more which is caused by the Injector usage in one of the classes used by a Page. Why do you think Application.get() method may blow up? Why isn't the ThreadLocal application instance get set? Thanks, Dmitry -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2244022.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore life cycle in cluster?
i would guess that is the time it takes to pull the session from memcached to the tomcat node. -igor On Thu, Jun 3, 2010 at 12:12 PM, DmitryM wrote: > > Igor, > > I was wrong. > When it's a first request hitting a page (after shutting down one of 2 > tomcats) then regardless of the type of request (ajax or bookmarkable page > link) there is a delay of 2+ seconds. > > -Dmitry > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2242198.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore life cycle in cluster?
Igor, I was wrong. When it's a first request hitting a page (after shutting down one of 2 tomcats) then regardless of the type of request (ajax or bookmarkable page link) there is a delay of 2+ seconds. -Dmitry -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2242198.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore life cycle in cluster?
are you sure its ajax only? that seems rather strange to me. if its true then i dont have a clue, you will have to use a profiler to see where the time goes. -igor On Thu, Jun 3, 2010 at 11:26 AM, DmitryM wrote: > > Only the very first one. > > I'm not 100% sure but the session seems to be always retrieved from > memcached... > > That's what I don't quite understand. When all nodes/tomcats in the cluster > are up then request are fast. > And the thing is, if that's not an Ajax action, then the request is > responded at the same speed (like switching between pages in the app). > > -Dmitry > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2242134.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore life cycle in cluster?
Only the very first one. I'm not 100% sure but the session seems to be always retrieved from memcached... That's what I don't quite understand. When all nodes/tomcats in the cluster are up then request are fast. And the thing is, if that's not an Ajax action, then the request is responded at the same speed (like switching between pages in the app). -Dmitry -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2242134.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore life cycle in cluster?
maybe because tomcat2 needs to retrieve the session from memcached, are subsequent requests also slow? or just the first request after the failover? -igor On Thu, Jun 3, 2010 at 11:06 AM, DmitryM wrote: > > Hello, guys > > I managed to have Tomcat cluster working with memcached-session-manager > (http://groups.google.com/group/memcached-session-manager) from Martin. > > Everything works perfectly fine unless tomcats start getting shut down. > I have 2 tomcats running with the session replicated (see above). Then I > shut down one of them. > When on a page with ajax behavior after I click an ajax button the response > to the request gets delayed (about 2-3 seconds extra compared to the case > when all tomcats are live and running). > > I tried this with Wicket's SecondLevelCacheSessionStore(+ DiskPageStore, I > assume) and I also tried to use a Hazelcast-based PageStore (ex. from here: > http://wicketbyexample.com/apache-wicket-clustering-with-multiple-options/). > That bizarre delay happens in both cases. > > Can anyone please try to come up with some explanation what may be happening > in that case? > I guess, the scenario is as follows: > - tomcat cluster with proper session distribution in place, > - request hits tomcat1 and gets page with ajax button > - tomcat1 is shutdown > - ajax button is clicked > - request hits tomcat2 and gets processed successfully (but with delay) > > Thanks in advance, > Dmitry > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2242105.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
SessionStore life cycle in cluster?
Hello, guys I managed to have Tomcat cluster working with memcached-session-manager (http://groups.google.com/group/memcached-session-manager) from Martin. Everything works perfectly fine unless tomcats start getting shut down. I have 2 tomcats running with the session replicated (see above). Then I shut down one of them. When on a page with ajax behavior after I click an ajax button the response to the request gets delayed (about 2-3 seconds extra compared to the case when all tomcats are live and running). I tried this with Wicket's SecondLevelCacheSessionStore(+ DiskPageStore, I assume) and I also tried to use a Hazelcast-based PageStore (ex. from here: http://wicketbyexample.com/apache-wicket-clustering-with-multiple-options/). That bizarre delay happens in both cases. Can anyone please try to come up with some explanation what may be happening in that case? I guess, the scenario is as follows: - tomcat cluster with proper session distribution in place, - request hits tomcat1 and gets page with ajax button - tomcat1 is shutdown - ajax button is clicked - request hits tomcat2 and gets processed successfully (but with delay) Thanks in advance, Dmitry -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SessionStore-life-cycle-in-cluster-tp2242105p2242105.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SessionStore and Detachable Models
You should use LoadableDetachableModel where possible to avoid stale data (and to preserve memory). On Thu, Sep 18, 2008 at 4:14 AM, carloc <[EMAIL PROTECTED]> wrote: > >hi everyone, > > if i use the secondlevelcachesessionstore wicket writes session state into > the disk > instead of the httpsession right? It is also the one that is used by > default. > > so is it safe for me to not use abstractdetachablemodels and just use > compoundpropertymodels since memory is not that big a concern anymore > -- > View this message in context: > http://www.nabble.com/SessionStore-and-Detachable-Models-tp19548105p19548105.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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SessionStore and Detachable Models
hi everyone, if i use the secondlevelcachesessionstore wicket writes session state into the disk instead of the httpsession right? It is also the one that is used by default. so is it safe for me to not use abstractdetachablemodels and just use compoundpropertymodels since memory is not that big a concern anymore -- View this message in context: http://www.nabble.com/SessionStore-and-Detachable-Models-tp19548105p19548105.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]
Re: Tracking logged in users / SessionStore questions
Thank you for your help, Igor. igor.vaynberg wrote: > > no, the session cookie is set and managed by the servlet container > > -igor > > On Sat, Sep 13, 2008 at 1:56 AM, behlma <[EMAIL PROTECTED]> wrote: >> >> Hi Igor, >> actually, the wrong cookie path is set. Could be that this is due to >> nginx >> (my webserver). Just to make sure, is there a way to set the session >> cookie >> path through wicket? >> >> igor.vaynberg wrote: >>> >>> are your cookies disabled? >>> >>> -igor >>> >>> On Thu, Sep 11, 2008 at 11:46 PM, behlma <[EMAIL PROTECTED]> wrote: >>>> >>>> Now another question has popped up. My bulletin board overview page, >>>> the >>>> one >>>> displaying all currently active/guests users and forums is a >>>> (stateless) >>>> BookmarkablePage. To be able to track the (guest) users however, I'm >>>> calling >>>> getSession().bind() in the page's constructor. >>>> >>>> The session gets bound the very first time I access the page (and I'm >>>> displayed as a guest user). The url (www.myurl.com/forum) at this point >>>> however has no notion of jsessionid whatsoever, so if I simply refresh >>>> the >>>> page, a new session gets bound, now displaying two guests. >>>> Consequently, >>>> for >>>> every refresh a new session is spawned. >>>> >>>> Now I understand that this is the correct behaviour, but is there any >>>> way >>>> around people being able to spawn thousands of sessions :) ? >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19450432.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] >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19468728.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] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19479686.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]
Re: Tracking logged in users / SessionStore questions
no, the session cookie is set and managed by the servlet container -igor On Sat, Sep 13, 2008 at 1:56 AM, behlma <[EMAIL PROTECTED]> wrote: > > Hi Igor, > actually, the wrong cookie path is set. Could be that this is due to nginx > (my webserver). Just to make sure, is there a way to set the session cookie > path through wicket? > > igor.vaynberg wrote: >> >> are your cookies disabled? >> >> -igor >> >> On Thu, Sep 11, 2008 at 11:46 PM, behlma <[EMAIL PROTECTED]> wrote: >>> >>> Now another question has popped up. My bulletin board overview page, the >>> one >>> displaying all currently active/guests users and forums is a (stateless) >>> BookmarkablePage. To be able to track the (guest) users however, I'm >>> calling >>> getSession().bind() in the page's constructor. >>> >>> The session gets bound the very first time I access the page (and I'm >>> displayed as a guest user). The url (www.myurl.com/forum) at this point >>> however has no notion of jsessionid whatsoever, so if I simply refresh >>> the >>> page, a new session gets bound, now displaying two guests. Consequently, >>> for >>> every refresh a new session is spawned. >>> >>> Now I understand that this is the correct behaviour, but is there any way >>> around people being able to spawn thousands of sessions :) ? >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19450432.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] >>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19468728.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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tracking logged in users / SessionStore questions
Hi Igor, actually, the wrong cookie path is set. Could be that this is due to nginx (my webserver). Just to make sure, is there a way to set the session cookie path through wicket? igor.vaynberg wrote: > > are your cookies disabled? > > -igor > > On Thu, Sep 11, 2008 at 11:46 PM, behlma <[EMAIL PROTECTED]> wrote: >> >> Now another question has popped up. My bulletin board overview page, the >> one >> displaying all currently active/guests users and forums is a (stateless) >> BookmarkablePage. To be able to track the (guest) users however, I'm >> calling >> getSession().bind() in the page's constructor. >> >> The session gets bound the very first time I access the page (and I'm >> displayed as a guest user). The url (www.myurl.com/forum) at this point >> however has no notion of jsessionid whatsoever, so if I simply refresh >> the >> page, a new session gets bound, now displaying two guests. Consequently, >> for >> every refresh a new session is spawned. >> >> Now I understand that this is the correct behaviour, but is there any way >> around people being able to spawn thousands of sessions :) ? >> >> -- >> View this message in context: >> http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19450432.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] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19468728.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]
Re: Tracking logged in users / SessionStore questions
are your cookies disabled? -igor On Thu, Sep 11, 2008 at 11:46 PM, behlma <[EMAIL PROTECTED]> wrote: > > Now another question has popped up. My bulletin board overview page, the one > displaying all currently active/guests users and forums is a (stateless) > BookmarkablePage. To be able to track the (guest) users however, I'm calling > getSession().bind() in the page's constructor. > > The session gets bound the very first time I access the page (and I'm > displayed as a guest user). The url (www.myurl.com/forum) at this point > however has no notion of jsessionid whatsoever, so if I simply refresh the > page, a new session gets bound, now displaying two guests. Consequently, for > every refresh a new session is spawned. > > Now I understand that this is the correct behaviour, but is there any way > around people being able to spawn thousands of sessions :) ? > > -- > View this message in context: > http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19450432.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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tracking logged in users / SessionStore questions
Now another question has popped up. My bulletin board overview page, the one displaying all currently active/guests users and forums is a (stateless) BookmarkablePage. To be able to track the (guest) users however, I'm calling getSession().bind() in the page's constructor. The session gets bound the very first time I access the page (and I'm displayed as a guest user). The url (www.myurl.com/forum) at this point however has no notion of jsessionid whatsoever, so if I simply refresh the page, a new session gets bound, now displaying two guests. Consequently, for every refresh a new session is spawned. Now I understand that this is the correct behaviour, but is there any way around people being able to spawn thousands of sessions :) ? -- View this message in context: http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19450432.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]
Re: Tracking logged in users / SessionStore questions
Thanks a lot, Martijn. -- View this message in context: http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19283896.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]
Re: Tracking logged in users / SessionStore questions
Take a look at enabling the RequestLogger and querying it. It gives access to sessions and requests. http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/protocol/http/RequestLogger.html Martijn On Tue, Sep 2, 2008 at 6:32 PM, behlma <[EMAIL PROTECTED]> wrote: > > Hi guys, > I'm developing a portal/forum application for my dissertation and wanted to > display a panel with all currently active users. Now I found an old thread > (Wicket 2.0) where Eelco posted an example SessionStore implementation to > solve this specific problem, but that raised some questions. > > 1. Should I subclass HttpSessionStore or SecondLevelCacheSS? What is the > back-button problem with HttpSessionStore? Is there another way to solve > this? > 2. Eelco's implementation seems to be memory only, why would I want that? > What are the advantages/drawbacks? Should I implement a custom database > specific session store? > 3. Not that I'm hitting a million users any time soon, but what would be the > best approach in terms of clustering, just out of interest? > > Thanks in advance > Marco > -- > View this message in context: > http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19273568.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.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tracking logged in users / SessionStore questions
Hi guys, I'm developing a portal/forum application for my dissertation and wanted to display a panel with all currently active users. Now I found an old thread (Wicket 2.0) where Eelco posted an example SessionStore implementation to solve this specific problem, but that raised some questions. 1. Should I subclass HttpSessionStore or SecondLevelCacheSS? What is the back-button problem with HttpSessionStore? Is there another way to solve this? 2. Eelco's implementation seems to be memory only, why would I want that? What are the advantages/drawbacks? Should I implement a custom database specific session store? 3. Not that I'm hitting a million users any time soon, but what would be the best approach in terms of clustering, just out of interest? Thanks in advance Marco -- View this message in context: http://www.nabble.com/Tracking-logged-in-users---SessionStore-questions-tp19273568p19273568.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]
Re: sessionstore is too big
> is there risk changing from wicket 1.3-beta2 to beta3 in nearly completely > implemented application? It *should* be better. But you might want to test this very well yourself, and check JIRA for newly introduced issues. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sessionstore is too big
And an other question: is there risk changing from wicket 1.3-beta2 to beta3 in nearly completely implemented application? 2007/9/24, Benjamin Ernst <[EMAIL PROTECTED]>: > > Because our Application in an intrannet-Apllication the user should stay > logged-in their whole workday. So our session-timeout is 12 hours and the > sessions don't expire for a long time. Could that be a problem too? > > And it could be that we killed the tomcat a few tims. > I will watch for session-directory size and how it grows. Is there a way > to check wether a session in this dircetory is no longer in use? > > Benjamin > > > 2007/9/24, Johan Compagner <[EMAIL PROTECTED]>: > > > > Yes we listen to unBind events, so they should be deleted. > > The only way that doesn't happen currently that i can think of if you > > kill > > tomcat the hard way > > then the current sessions will never normally expire and will never be > > cleaned > > > > johan > > > > > > > > On 9/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > On 9/24/07, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > how do you stop tomcat when you stop it (if you do that) > > > > Make sure that you never kill tomcat, If you do that then you have > > to > > > delete > > > > the dirs yourself. > > > > > > But even without shutting down, those old sessions should be removed, > > > no? I mean, as far as I remember, we explicitly delete them when they > > > expire. > > > > > > Eelco > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > >
Re: sessionstore is too big
If you upgrade Wicket, there's new page store called DiskPageStore. for this pagestore you can set limits for pagemap file size and limit for entire session (so the session never grows beyond that limit) -Matej On 9/24/07, Benjamin Ernst <[EMAIL PROTECTED]> wrote: > Because our Application in an intrannet-Apllication the user should stay > logged-in their whole workday. So our session-timeout is 12 hours and the > sessions don't expire for a long time. Could that be a problem too? > > And it could be that we killed the tomcat a few tims. > I will watch for session-directory size and how it grows. Is there a way to > check wether a session in this dircetory is no longer in use? > > Benjamin > > > 2007/9/24, Johan Compagner <[EMAIL PROTECTED]>: > > > > Yes we listen to unBind events, so they should be deleted. > > The only way that doesn't happen currently that i can think of if you kill > > tomcat the hard way > > then the current sessions will never normally expire and will never be > > cleaned > > > > johan > > > > > > > > On 9/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > On 9/24/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > how do you stop tomcat when you stop it (if you do that) > > > > Make sure that you never kill tomcat, If you do that then you have to > > > delete > > > > the dirs yourself. > > > > > > But even without shutting down, those old sessions should be removed, > > > no? I mean, as far as I remember, we explicitly delete them when they > > > expire. > > > > > > Eelco > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sessionstore is too big
Because our Application in an intrannet-Apllication the user should stay logged-in their whole workday. So our session-timeout is 12 hours and the sessions don't expire for a long time. Could that be a problem too? And it could be that we killed the tomcat a few tims. I will watch for session-directory size and how it grows. Is there a way to check wether a session in this dircetory is no longer in use? Benjamin 2007/9/24, Johan Compagner <[EMAIL PROTECTED]>: > > Yes we listen to unBind events, so they should be deleted. > The only way that doesn't happen currently that i can think of if you kill > tomcat the hard way > then the current sessions will never normally expire and will never be > cleaned > > johan > > > > On 9/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > On 9/24/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > how do you stop tomcat when you stop it (if you do that) > > > Make sure that you never kill tomcat, If you do that then you have to > > delete > > > the dirs yourself. > > > > But even without shutting down, those old sessions should be removed, > > no? I mean, as far as I remember, we explicitly delete them when they > > expire. > > > > Eelco > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: sessionstore is too big
Jetty cleans the temp dir on startup automatically, Tomcat probably doesn't do it. Still, this shouldn't happen on production, because we clean the files when session is unbound. But when you just kill tomcat, there is no way we can clean sessions. Unless we check on startup if the folder is empty for given session store. I'm not sure we should do that though. -Matej On 9/24/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > Yes we listen to unBind events, so they should be deleted. > The only way that doesn't happen currently that i can think of if you kill > tomcat the hard way > then the current sessions will never normally expire and will never be > cleaned > > johan > > > > On 9/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > On 9/24/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > how do you stop tomcat when you stop it (if you do that) > > > Make sure that you never kill tomcat, If you do that then you have to > > delete > > > the dirs yourself. > > > > But even without shutting down, those old sessions should be removed, > > no? I mean, as far as I remember, we explicitly delete them when they > > expire. > > > > Eelco > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sessionstore is too big
Yes we listen to unBind events, so they should be deleted. The only way that doesn't happen currently that i can think of if you kill tomcat the hard way then the current sessions will never normally expire and will never be cleaned johan On 9/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > On 9/24/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > how do you stop tomcat when you stop it (if you do that) > > Make sure that you never kill tomcat, If you do that then you have to > delete > > the dirs yourself. > > But even without shutting down, those old sessions should be removed, > no? I mean, as far as I remember, we explicitly delete them when they > expire. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: sessionstore is too big
On 9/24/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > how do you stop tomcat when you stop it (if you do that) > Make sure that you never kill tomcat, If you do that then you have to delete > the dirs yourself. But even without shutting down, those old sessions should be removed, no? I mean, as far as I remember, we explicitly delete them when they expire. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sessionstore is too big
how do you stop tomcat when you stop it (if you do that) Make sure that you never kill tomcat, If you do that then you have to delete the dirs yourself. But maybe somehow there is a loophole that stops us from deleting the file. On 9/24/07, Benjamin Ernst <[EMAIL PROTECTED]> wrote: > > First of all: thanks for your help! > > Do you have any idea how to find that out? Where can I see how and when > wicket tries to delete the session? > > Benjamin > > 2007/9/24, Eelco Hillenius <[EMAIL PROTECTED]>: > > > > > we have a problem with the sessions that wicket stores in the > > filesystem. It > > > seems that the sessions that are stored here > > > "[TOMCAT-DIR]\work\Catalina\[HOST]\[WEB-APP-NAME\sessions\" are not > > deleted > > > after they are no longer in use. The size of this directory is now > grown > > to > > > 2.5Gb, which is way too big. Is there a way to let wicket delete old > > > sessions? > > > > > > We are using wicket 1.3-beta2 with Apache Tomcat 5.5.23. > > > > Hmmm. You should try to find out why they aren't being deleted. We > > sure do our best! > > > > Btw, if you upgrade to beta 3, you'll get a more efficient page store > > implementation as the default. > > > > Eelco > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: sessionstore is too big
First of all: thanks for your help! Do you have any idea how to find that out? Where can I see how and when wicket tries to delete the session? Benjamin 2007/9/24, Eelco Hillenius <[EMAIL PROTECTED]>: > > > we have a problem with the sessions that wicket stores in the > filesystem. It > > seems that the sessions that are stored here > > "[TOMCAT-DIR]\work\Catalina\[HOST]\[WEB-APP-NAME\sessions\" are not > deleted > > after they are no longer in use. The size of this directory is now grown > to > > 2.5Gb, which is way too big. Is there a way to let wicket delete old > > sessions? > > > > We are using wicket 1.3-beta2 with Apache Tomcat 5.5.23. > > Hmmm. You should try to find out why they aren't being deleted. We > sure do our best! > > Btw, if you upgrade to beta 3, you'll get a more efficient page store > implementation as the default. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: sessionstore is too big
> we have a problem with the sessions that wicket stores in the filesystem. It > seems that the sessions that are stored here > "[TOMCAT-DIR]\work\Catalina\[HOST]\[WEB-APP-NAME\sessions\" are not deleted > after they are no longer in use. The size of this directory is now grown to > 2.5Gb, which is way too big. Is there a way to let wicket delete old > sessions? > > We are using wicket 1.3-beta2 with Apache Tomcat 5.5.23. Hmmm. You should try to find out why they aren't being deleted. We sure do our best! Btw, if you upgrade to beta 3, you'll get a more efficient page store implementation as the default. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sessionstore is too big
Hi, we have a problem with the sessions that wicket stores in the filesystem. It seems that the sessions that are stored here "[TOMCAT-DIR]\work\Catalina\[HOST]\[WEB-APP-NAME\sessions\" are not deleted after they are no longer in use. The size of this directory is now grown to 2.5Gb, which is way too big. Is there a way to let wicket delete old sessions? We are using wicket 1.3-beta2 with Apache Tomcat 5.5.23. Benjamin
