Actually - to be clear - we have 2 tomcat instances on the same
machine, but I don't see this being the issue.
So back to the drawing board again :-(
On Wed, Mar 31, 2010 at 6:27 PM, Richard Wilkinson
wrote:
> OK, so so long as all cluster machines are running, they will all have the
> same co
OK, so so long as all cluster machines are running, they will all have the
same contents in their DiskPageMap, and you should never see the exception,
however, if one machine goes down for a bit, any pages visited during that
time will not be transferred to it when it comes back up, meaning that th
The last page is kept in the session such that it is transferred
across the cluster. Each node in the cluster should then update the
local pagestore with that page. Matej has written quite a bit about
this behavior on this list, so searching might help.
Martijn
On Wed, Mar 31, 2010 at 5:02 PM, Ri
> I don't believe that this DiskPageStore is clustered, because it is an
> actual file on the machine. If this is the case then although the current
> page will be clustered by tomcat, the previous pages wont be, so wont be
> available on the other machine. This could cause the exception you are
afaik, the default SecondLevelCacheSessionStore works by keeping the current
page in session (in memory) and uses DiskPageStore as its second level
cache, which stores all the other pages in a file on disk.
I don't believe that this DiskPageStore is clustered, because it is an
actual file on the m
Thanks for the explanation Richard.
We do have setAutomaticMultiWindowSupport set to false, because when
we had it set to true we had some problems (I cannot remember what
exactly - something to do with url mounting I think).
Thing is when I experienced this issue I only had one tab open - it
may
Hi,
Ok, anyone else please correct me if i am wrong, but afaik:
The pagemap holds a finite number of pages in it, each time you access a new
page it gets added to the page map, how many pages it holds depends on which
implementation of page map you are using, which usually depends on which
type o
Hi Richard,
thanks for the reply.
I'll have a look at trying to make the failover fail again - but the
last time we tested it was working fine so unless there is a core
problem with the apache balancer and tomcat I don't know what I can
do.
> There are probably other reasons why you might see a
Hi Martin,
I think we can confidently say that its not a serialization issue as
its a very simple component/panel that is used a lot. The
pageexpiredexception I experience on this component was the first time
we'd seen it. We see these exceptions seemlying randomly in the
production logs.
On We
Not only all the classes need to implement Serializable, but their
properties need to be serializable as well...
public class MyFoo implements Serializable
{
private Connection connection = ...
}
is not completely serializable
martijn
On Fri, Mar 26, 2010 at 3:42 PM, Wayne Pope wrote:
>
Ok,
If you can replicate the problem by the following:
1) shutting down tomcat 1, therefore ensuring that you go to tomcat 2,
2) going to a page on your site (that has some ajax on there),
3) starting up tomcat 1, then shutting down tomcat 2, therefore ensuring
that the next request goes to tomcat
Hi Richard
my mistake we have the following setting:
ProxyPass / balancer://cluster/ stickysession=JSESSIONID nofailover=Off
This problem happens from time to time in production with no pattern
that we can find. We have a 'shared' firewall that hosts the SSL cert,
going to the apache instance wh
Hi Wayne,
As far as I know mod_proxy_balancer does not have sticky sessions on by
default, you have to tell it what cookie to use. Am am assuming that you
have multiple tomcats (or similar) behind apache, are you using any sort of
session replication for them?
Does this exception occur when you
Well as far as I know the default balancer in apache supports this yes.
On Mon, Mar 29, 2010 at 2:22 PM, Martijn Dashorst
wrote:
> Are you using sticky sessions?
>
> Martijn
>
> On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
> wrote:
>> One more bit of info - it was a ajax request that caused thi
Are you using sticky sessions?
Martijn
On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
wrote:
> One more bit of info - it was a ajax request that caused this.
>
> Any ideas?
>
>
> On Fri, Mar 26, 2010 at 3:42 PM, Wayne Pope
> wrote:
>>
>>
>> oh and I doubled check that all the classes implement Se
One more bit of info - it was a ajax request that caused this.
Any ideas?
On Fri, Mar 26, 2010 at 3:42 PM, Wayne Pope wrote:
>
>
> oh and I doubled check that all the classes implement Serializable
>
>
>
>
> Wayne Pope-2 wrote:
>>
>> Hi,
>>
>> we're getting this exception in production sometime
oh and I doubled check that all the classes implement Serializable
Wayne Pope-2 wrote:
>
> Hi,
>
> we're getting this exception in production sometimes, and today I
> experienced it first hand.
> We have a session of 60 mins set in the web.xml - however I got this
> after just 5 mins:
>
>
Hi,
we're getting this exception in production sometimes, and today I
experienced it first hand.
We have a session of 60 mins set in the web.xml - however I got this
after just 5 mins:
org.apache.wicket.protocol.http.PageExpiredException: Cannot find the
rendered page in session
[pagemap=null,com
18 matches
Mail list logo
