Re: Tapestry 4.1 injecting the wrong application state object
I recently run into https://issues.apache.org/bugzilla/show_bug.cgi?id=49417 and it reminded me of your case, so take a look, perhaps it's related (assuming the getLocale() change you mentioned didn't help) In short, that bug report mentions: "when you use mod_proxy to connect to a backend tomcat server and apache is configured to timeout before tomcat, a connection to the backend tomcat server is placed back into the pool of existing connections with what ever data that was destined to the original caller waiting to be retrieved by the next caller to take this connection from the pool. In our application which is statefull, this lead to customer's sessions crossing and customer A saw customer B's data." On Sat, Feb 5, 2011 at 13:48, Pepijn Schmitz wrote: > Hi Koka, > > Yes, we use it for every request. The application is not even reachable over > port 80. :-) > > It seems we found the problem though. It looks like it was caused by > overriding getLocale() in our page base class, although I'm not sure the > problem is 100% gone now, and I don't fully understand how that caused the > problem in the first place. We're still waiting for a busy day to know for > sure that the problem is gone now... > > Kind regards, > Pepijn Schmitz > > On 03-02-11 07:25, Koka Kiknadze wrote: >> >> As your problem persists I dare to get back to my initial response. You >> said >>> >>> We're already using HTTPS >> >> Usually HTTPS is used only at the authentication page. Are you sure you >> have >> tested it with HTTPS for every single page? >> > > > -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Tapestry PMC / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry 4.1 injecting the wrong application state object
Hi Koka, Yes, we use it for every request. The application is not even reachable over port 80. :-) It seems we found the problem though. It looks like it was caused by overriding getLocale() in our page base class, although I'm not sure the problem is 100% gone now, and I don't fully understand how that caused the problem in the first place. We're still waiting for a busy day to know for sure that the problem is gone now... Kind regards, Pepijn Schmitz On 03-02-11 07:25, Koka Kiknadze wrote: As your problem persists I dare to get back to my initial response. You said We're already using HTTPS Usually HTTPS is used only at the authentication page. Are you sure you have tested it with HTTPS for every single page? smime.p7s Description: S/MIME Cryptographic Signature
Re: Tapestry 4.1 injecting the wrong application state object
In our case we were lucky enough that we can ask user to change language
only on a given page.
So the solution we adopted was to duplicate that page and to have
listeners for changing language that where pointing to the other page.
This because the language is changed only when page is rendered:
http://tapestry.apache.org/tapestry4.1/usersguide/localization.html
So you have pageA with a link changeLanguageLink pointing to listener
public pageB changeLanguage(String locale){
this.getRequestCycle().getEngine().setLocale(new Locale(locale));
return getPageB();
};
Conversely you have a similar link in pageB returning pageA.
Hope this helps
Il 03/02/2011 9.01, Howard Lewis Ship ha scritto:
> Well, the idea in Tapestry has ever been that the locale for a page is
> fixed, once determined, and it's hard to say what the effect of your
> change would be ... but good detective work getting this far.
>
> I don't currently remember where in Tapestry 4.1 the determination of
> client locale is made; when I have some time, I'll try and look in the
> code and see what turns up.
>
> On Wed, Feb 2, 2011 at 6:28 AM, Pepijn Schmitz wrote:
>> Hi Howard,
>>
>> Further to my last message, I just discovered that I was making a faulty
>> assumption. When the pages are checked out of the pool, the engine locale is
>> used to build the page key, but when they are released to the pool, the
>> *page* locale is used! So overriding getLocale() on the page is indeed
>> causing problems.
>>
>> Can you tell me what the correct way of doing this is? Apart from wanting to
>> give the users the ability to configure their language in their user
>> settings in our application, it is also problematic that the locale that the
>> browser provides is often missing the country, and Java often does not use
>> correct date, time and number formats if the locale does not include the
>> country.
>>
>> And do you have any idea if this could also the root cause of my original
>> problem? I don't really see how, since all this means as far as I can tell
>> is that Tapestry will needlessly instantiate pages, but I still don't see
>> how a page which still contains values from one session can end up on
>> another session.
>>
>> 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
>>> 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
> Schmitzwrote:
>
>> 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
Re: Tapestry 4.1 injecting the wrong application state object
Well, the idea in Tapestry has ever been that the locale for a page is fixed, once determined, and it's hard to say what the effect of your change would be ... but good detective work getting this far. I don't currently remember where in Tapestry 4.1 the determination of client locale is made; when I have some time, I'll try and look in the code and see what turns up. On Wed, Feb 2, 2011 at 6:28 AM, Pepijn Schmitz wrote: > Hi Howard, > > Further to my last message, I just discovered that I was making a faulty > assumption. When the pages are checked out of the pool, the engine locale is > used to build the page key, but when they are released to the pool, the > *page* locale is used! So overriding getLocale() on the page is indeed > causing problems. > > Can you tell me what the correct way of doing this is? Apart from wanting to > give the users the ability to configure their language in their user > settings in our application, it is also problematic that the locale that the > browser provides is often missing the country, and Java often does not use > correct date, time and number formats if the locale does not include the > country. > > And do you have any idea if this could also the root cause of my original > problem? I don't really see how, since all this means as far as I can tell > is that Tapestry will needlessly instantiate pages, but I still don't see > how a page which still contains values from one session can end up on > another session. > > 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 >> 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 Schmitzwrote: > 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>> >>> wrote: >> >> 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 page
Re: Tapestry 4.1 injecting the wrong application state object
As your problem persists I dare to get back to my initial response. You said > We're already using HTTPS Usually HTTPS is used only at the authentication page. Are you sure you have tested it with HTTPS for every single page?
Re: Tapestry 4.1 injecting the wrong application state object
Hi Howard,
Further to my last message, I just discovered that I was making a faulty
assumption. When the pages are checked out of the pool, the engine
locale is used to build the page key, but when they are released to the
pool, the *page* locale is used! So overriding getLocale() on the page
is indeed causing problems.
Can you tell me what the correct way of doing this is? Apart from
wanting to give the users the ability to configure their language in
their user settings in our application, it is also problematic that the
locale that the browser provides is often missing the country, and Java
often does not use correct date, time and number formats if the locale
does not include the country.
And do you have any idea if this could also the root cause of my
original problem? I don't really see how, since all this means as far as
I can tell is that Tapestry will needlessly instantiate pages, but I
still don't see how a page which still contains values from one session
can end up on another session.
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 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
Schmitzwrote:
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
wrote:
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:
...
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 stat
Re: Tapestry 4.1 injecting the wrong application state object
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 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
Schmitzwrote:
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
wrote:
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
Re: Tapestry 4.1 injecting the wrong application state object
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 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
>> Schmitzwrote:
>>
>>> 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
> wrote:
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:
>
>
>
>
>
>
>
>
> ...
>
>
> 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 t
Re: Tapestry 4.1 injecting the wrong application state object
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 Schmitzwrote:
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
wrote:
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:
...
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
Re: Tapestry 4.1 injecting the wrong application state object
Did you find root of the problem? Just curious :)
Good luck
On Tue, Jan 11, 2011 at 11:00 PM, Pepijn Schmitz 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> >wrote:
>>
>> 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:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ...
>>>
>>>
>>> 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
>>>
>>>
>>>
>
>
Re: Tapestry 4.1 injecting the wrong application state object
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 Schmitzwrote:
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:
...
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
Re: Tapestry 4.1 injecting the wrong application state object
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 wrote:
> 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:
>
>
>
>
>
>
>
>
> ...
>
>
> 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
>
>
Tapestry 4.1 injecting the wrong application state object
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:
...
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
