Re: Serialized Session Data in Websphere
We are aware of this issue: WICKET-6457 (since yesterday). The dev@ list is discussing releasing patches for 6.x and 7.x. Martijn On Wed, Aug 30, 2017 at 4:22 PM, Entropy wrote: > Our operations team just discovered huge growth of files in a temp folder > named [app_name]Wicket-filestore. We're on Wicket 6 (well, most of our > apps > are). There's clearly some stuff in there that shouldn't be, and our devs > are going to need to be more frugal with what they throw into the user > session. > > However, there's quite alot of files that are months old. This seems odd, > because my understanding is that Wicket deletes these upon session > invalidation. And it must be doing that for the most part, or there would > be ALOT more of these things, I suspect. > > But maybe there are circumstances where it's not cleaning up? Does the > cleanup fire when the app is stopped? When Websphere is restarted? I am > thinking I am going to instruct our ops team to write a script to > automatically delete any files in this directory older than a day. > > I am wanting to check that folks agree that such an action is appropriate, > and what circumstances are known that might cause this buildup. Shutdown > is > the only one I can think of (no, the server hasn't been crashing). > > -- > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum- > f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Serialized Session Data in Websphere
Hi, These files are deleted when a session is invalidated. If WebSphere invalidates the sessions during stop then they should be deleted. It should be easy for you to test this. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Aug 30, 2017 at 5:22 PM, Entropy wrote: > Our operations team just discovered huge growth of files in a temp folder > named [app_name]Wicket-filestore. We're on Wicket 6 (well, most of our > apps > are). There's clearly some stuff in there that shouldn't be, and our devs > are going to need to be more frugal with what they throw into the user > session. > > However, there's quite alot of files that are months old. This seems odd, > because my understanding is that Wicket deletes these upon session > invalidation. And it must be doing that for the most part, or there would > be ALOT more of these things, I suspect. > > But maybe there are circumstances where it's not cleaning up? Does the > cleanup fire when the app is stopped? When Websphere is restarted? I am > thinking I am going to instruct our ops team to write a script to > automatically delete any files in this directory older than a day. > > I am wanting to check that folks agree that such an action is appropriate, > and what circumstances are known that might cause this buildup. Shutdown > is > the only one I can think of (no, the server hasn't been crashing). > > -- > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum- > f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Serialized Session Data in Websphere
Our operations team just discovered huge growth of files in a temp folder named [app_name]Wicket-filestore. We're on Wicket 6 (well, most of our apps are). There's clearly some stuff in there that shouldn't be, and our devs are going to need to be more frugal with what they throw into the user session. However, there's quite alot of files that are months old. This seems odd, because my understanding is that Wicket deletes these upon session invalidation. And it must be doing that for the most part, or there would be ALOT more of these things, I suspect. But maybe there are circumstances where it's not cleaning up? Does the cleanup fire when the app is stopped? When Websphere is restarted? I am thinking I am going to instruct our ops team to write a script to automatically delete any files in this directory older than a day. I am wanting to check that folks agree that such an action is appropriate, and what circumstances are known that might cause this buildup. Shutdown is the only one I can think of (no, the server hasn't been crashing). -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Websocket replacing a panel which uses websockets
Done https://issues.apache.org/jira/browse/WICKET-6458 On 29 August 2017 at 18:29, Martin Grigorov wrote: > Hi, > > Please file a ticket! > It should be easy to implement it. > Thanks! > > On Aug 29, 2017 17:15, "Peter Henderson" > wrote: > > > Hi All, > > > > I've run into a possible bug. > > > > I've a page which initially shows a "loading..." animation panel. > > This panel uses web sockets to trigger background loading. > > (WebSocketBehavior::onConnected starts the background loading) > > > > > > When the background loading has completed > > (onEvent => event.getPayload => WebSocketPushPayload => ???) > > I replace the loading place holder panel with the real data panel. > > > > > > > > The real data panel may also want to use web sockets, and show a loading > > animation. > > (Turtles all the way down) > > > > The problem I'm seeing, is that the WebSocketBehavior::onConnected method > > is not being called on the replaced panel. > > > > > > So my questions:- > > > > Am I doing something wrong? > > Is this the expected behaviour? > > (or) Is this a Bug? > > > > > > > > > > A fairly simple example [1] although it's in Scala. > > > > [1] https://github.com/bollinger/WebSocketPanelReplace > > > > The interesting class is > > https://github.com/bollinger/WebSocketPanelReplace/blob/ > > master/src/main/scala/com/starjar/ws/WsLoadingPanel.scala > > > > Many thanks > > > > Peter. > > > > > > > > -- > > Peter Henderson > > > -- Peter Henderson Director Starjar Ltd. www.starjar.com 0330 088 1662
