Hi Howard,I know, but I've been through my code with a fine-toothed comb and as far as I can tell I'm doing everything right. I'm not storing any references to page objects, and all page objects I use in my code (to return from listeners) I'm getting from abstract getters annotated with @InjectPage.
I noticed that Tapestry kept instantiating pages, even though there should be plenty lying around in the page pool. I don't know whether that's a separate problem, or related to my original problem, but it didn't seem right. With some debugging I noticed that when the page objects are released back to the pool, the engine locale has changed! For instance, when the page is retrieved from the pool, the engine locale is "nl", but when it is returned, it is "nl_NL". The result is that the page key is different, and the objects are "released" back to a different pool, from which they are never retrieved!
I have overridden getLocale() in the page base class I created for my application, to look up the locale in the user settings if a user is logged in. Could that be the problem? I don't see how though, since the locale for the page key is retrieved from the engine, and I'm not changing that, I'm just returning a different locale from getLocale() in my base class.
If that could be the cause of the problem, then what is the correct way of allowing a user to choose their language other than using their browser setting (which many people don't know about, or don't want to change because they might want to use different languages on different sites)?
Kind regards, Pepijn Schmitz On 26-01-11 21:40, Howard Lewis Ship wrote:
It isn't familiar to me. Once possible way things could go awry would be for you to keep a reference to some page as a property of some other page ... that can result in data moving into and out of the page without Tapestry's normal lifecycle to initialize it and clean it out. I'd look along those lines. On Wed, Jan 26, 2011 at 3:21 AM, Pepijn Schmitz<capt...@chaos.demon.nl> wrote:No, not yet! :-( Anyone else have any idea? In short: my Page objects occasionally get the wrong application state object injected by Tapestry 4.1! I've been looking into it, but it's very hard to see what's going on with all the synthetic classes created by Hivemind. But one clue I got by making a heap dump and analysing it: all application state objects (of closed sessions) were still in memory, with references from Page classes in a TapestryKeyedObjectPool! I'm pretty sure the Page properties are supposed to be cleaned out at the end of a request cycle, when the page is returned to the pool, but apparently for some reason that is not happening! Is this a familiar problem to anyone? Kind regards, Pepijn Schmitz On 25-01-11 11:59, Koka Kiknadze wrote:Did you find root of the problem? Just curious :) Good luck On Tue, Jan 11, 2011 at 11:00 PM, Pepijn Schmitz<capt...@chaos.demon.nl>wrote:Hi, Thanks! But I don't think that's it. We're already using HTTPS, but also that would not explain how the correct application state object can be on the HttpSession, even though Tapestry injected the wrong one... We are using Apache 2 using mod_proxy as a front-end though. Apache takes care of the SSL and forwards the requests to Glassfish over HTTP. I'll look into the possibility that something is going wrong there, although it seems unlikely due to the above reason... Cheers, Pepijn On 11-01-11 19:04, Koka Kiknadze wrote:I did have exactly similar problem couple of years ago - JSF app worked fine from intranet, but messed up user sessions when accessed from WAN side. So initial suspect was the squid proxy configuration of our ISP. The problem disappeared as soon as we turned encryption on for the whole site (so that proxy could not mess things up). Well, as the performance was acceptable even with HTTPS we just left everything as is. Hence I'd suggest temporarily requiring HTTPS for the whole site and if the problem disappears, you'll know for sure it's not your application or tapestry to be blamed. Good luck. On Tue, Jan 11, 2011 at 8:37 PM, Pepijn Schmitz<tapes...@chaos.demon.nlwrote:Hi everyone,I'm having a bizarre problem with Tapestry, and I'm hoping someone here might be able to point me to a solution. Before I go into detail I'd like to describe the problem generally, in the hopes that it might be a known problem or someone may have encountered something similar. The problem is that Tapestry 4.1.6 sometimes injects the wrong application state object on my pages! As you can imagine, this plays havoc with my application, with users seeing other users' details, or even worse, changing other users' information! It's a support and security nightmare. I'm using Tapestry 4.1.6, and I'm using annotations instead of XML files. My pages all descend from a base class: public abstract SupplierDNAPage extends BasePage { @InjectState public abstract SupplierDnaSession getSupplierDnaSession(); @InjectStateFlag public abstract boolean getSupplierDnaSessionExists(); ... } hivemodule.xml contains the following: <?xml version="1.0" encoding="UTF-8"?> <module id="com.supplierdna" version="0.0.0"> <contribution configuration-id="tapestry.state.ApplicationObjects"> <state-object name="supplier-dna-session" scope="session"> <create-instance class="com.supplierdna.logic.SupplierDnaSession"/> </state-object> </contribution> ... </module> SupplierDNA is the name of the company I'm writing this for. As I understand it, this is the correct way of using application state objects. And most of the time, it works perfectly. When testing locally I have no problems with wrong application state being injected, and our demo system also doesn't have the problem. The problems seem to start when the server is heavily loaded. Then, sometimes, getSupplierDnaSession() will return an application state object from a different session!!! I have verified this by adding a pageBeginRender() listener method to the base class, and a client address property to the session. The listener method checks whether the client address stored on the session it gets from Tapestry is the same as the client address from the current request, and throws an exception if this is not the case. On our production server, this happens dozens of times a day! The method also directly retrieves the application state object from the HttpSession and compares it to the one it got from Tapestry, and it turns out that the application state object on the HttpSession is the correct one, but somehow Tapestry is injecting a different one! This seems to rule out the web container as being the culprit (which is Glassfish 2 update 2, in this case). Obviously this is a complex problem with a potentially huge number of contributing factors, but first I'd just like to know whether this sounds familiar to anyone? Is there a known problem with Tapestry which could cause this? Has anyone ever experienced something similar? Many thanks in advance for any help you can give me! Kind regards, Pepijn Schmitz --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
smime.p7s
Description: S/MIME Cryptographic Signature