Before you spend another day on troubleshooting again: check WICKET-6457. It's a regression caused by the fix for WICKET-6387 which will cause the pagestore to keep growing on some containers (like wildfly). It is fixed in 7.8.1 which is in the process of being released at this moment.
Emond On donderdag 7 september 2017 11:45:19 CEST Brian Cullen wrote: > As is the way with these things I find that this issue has already been > addressed by WICKET-6387 and is fixed in Wicket 7.8. > I wish I had found that earlier. > > Brian. > > > > -----Original Message----- > From: Brian Cullen [mailto:brian.cul...@cdl.co.uk] > Sent: 07 September 2017 11:42 > To: 'users@wicket.apache.org' <users@wicket.apache.org> > Subject: Possible Issues with Page Store > > Hello, > > I'm working with Wicket 7.7 and have hit something I don't understand > relating to how pages are written and retrieved from the DiskDataStore. I'm > not sure if this is the correct list to post this but I would appreciate > any assistance people can provide. > Essentially the issue I'm having is that as part of the end of the request > cycle the commitRequest method is called on the PageManager. This > eventually translates to a call to storeTouchedPages on the > PageStoreManager. As I understand it this method creates a session entry if > necessary and then stores the page instances with it - this, by default, > leads to the DiskDataStore saving each page asynchronously. > The issue I have is where the setSessionAttributes method is called after > storing the pages. This leads to the session attribute listeners being > called. In this case the object is of type PageStoreManager$SessionEntry > which clears the page store when the valueUnbound method is invoked on it. > If you are using the default asynch page store then there is always a > chance that the page will be stored after the setSessionAttributes method > call clears the page store but there doesn't seem to be any guarantee of > this - if it was a synchronous store it will never work as far as I can > tell. > Obviously this will only be an issue if the page isn't in the session cache > for some reason but to my limited understanding of this area it doesn't > seem like the functionality is correct. Can anyone advise, is this a bug or > am I looking at this the wrong way? > Finally, on a related point, when I was investigating this issue I noticed > that the asynchronous flag of the application StoreSettings is never used. > There is a check at DefaultPageManagerProvider:60 to make sure that the > underlying data source can support asynchronous operation but I would have > thought that the StoreSettings should also be checked as part of this if > statement - is that the case? > Regards, > > Brian. > <http://www.cdl.co.uk/> > > > > <http://twitter.com/CDL_Software> <http://www.facebook.com/CDL-Software> > <http://www.linkedin.com/company/cdl-cheshire-datasystems-ltd-> > > Please consider the environment - Do you really need to print this email? > > This email is intended only for the person(s) named above and may contain > private and confidential information. If it has come to you in error, > please destroy and permanently delete any copy in your possession, and > contact us on +44 (0)161 480 4420. The information in this email is > copyright © CDL Group Holdings Limited. We cannot accept liability for any > loss or damage sustained as a result of software viruses. It is your > responsibility to carry out such virus checking as is necessary before > opening any attachment. > Cheshire Datasystems Limited uses software which automatically screens > incoming emails for inappropriate content and attachments. If the software > identifies such content or attachment, the email will be forwarded to our > Technology department for checking. You should be aware that any email that > you send to Cheshire Datasystems Limited is subject to this procedure. > --------------------------------------------------------------------------- > --- Cheshire Datasystems Limited, Strata House, Kings Reach Road, Stockport, > SK4 2HD Registered in England and Wales with company number 3991057 VAT > registration: 727 1188 33 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
