Guten Tag Martin Grigorov, am Sonntag, 23. November 2014 um 12:20 schrieben Sie:
> 4) you start Tomcat and it tries to load the persisted sessions > 4.1) Since Wicket stores its data > as org.apache.wicket.pageStore.DefaultPageStore.SerializedPage (a triple of > pageId (int) / sessionId (String) / pageData (byte[])) it is Wicket's job > to deserialize the pageData byte[] to SomePage instance. I'm pretty sure this is not what is happening and the provided stacktrace makes clear that Wicket is doing everything. The only thing where Tomcat comes into play is the actual class loading itself, but that's correct of course because Tomcat provides at least a parent classloader to use. Wicket does serialize and deserialize the pages on it's own just because of an incoming request. > In both cases I think Tomcat will just log an error that an old session > cannot be loaded and continue with the start of the application. > Am I correct or Tomcat fails to start ? Tomcat doesn't log anything and just succeeds to start, at least I didn't find any log messages from Tomcat in Eclipse and requesting other pages from Wicket after ClassNotFoundException succeeded as well. Simply because there were newly created. > Please paste the complete exception if I am not correct. I attached the saved HTML file with everything Wicket told me, but there's nothing more interesting than what I've already posted in my fist mail. > No. > Wicket cleans up its data storages at session invalidation time (per > sessionId) or at application stop (for all sessions). > So there is nothing to load at start time and no knowledge about old stuff. If that was true, Tomcat wouldn't be able to run into any problems with a serialized session as well because there wouldn't be anything left from Wicket to serialize. Or does Wicket only clear persistent storage in files, but retains it's session data? That wouldn't make much sense to me, because the problem would remain. Besides that, I just tested with a request for some page: Wicket did create a folder to save the serialized page during runtime of Tomcat. So I stopped Tomcat to see if the folder gets deleted or such and it didn't, instead Wicket created the additional file "DiskDataStoreIndex" as serialized Java object, which clearly contains the path to the serialized page. Afterwards I restarted Tomcat, issued another request, "DiskDataStoreIndex" got read (monitored using ProcMon) and afterwards deleted. The only thing I didn't see was reading the former persisted page... But the former behavior corresponds to the code: DiskDataStore.destroy doesn't just empty anything, data gets persisted in a file and there's even a load method to load the data. So the only interesting thing is if pages are used as well after the restart or not: Application.internalDestroy does call a lot of destroy methods, but DiskDataStore.destroy e.g. is implemented to persist data, while other caches seem to really be just cleared, like that for markup. Which is the codepath where I can see that persisted pages get forgotten on shutdown of Wicket? Following Application.internalDestroy and it's call of internalGetPageManager().destroy(); lead me to DiskDataStore which clearly doesn't destroy the data... A simple explanation for my problem could as well be that I didn't restart the Tomcat and that during it's restart it works like you say, but in that case I want to make sure that really session and persistent page store are abandoned and currently it doesn't look so... Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: [email protected] AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
