[Fwd: Re: Wicket clustering without web server clustering]

[Martin Grotzke]

[resending to the msm-list since the previous message was blocked due to
group settings]

-------- Forwarded Message --------
From: Martin Grotzke <martin....@javakaffee.de>
To: us...@wicket.apache.org
Cc: memcached-se...@googlegroups.com
Subject: Re: Wicket clustering without web server clustering
Date: Mon, 31 May 2010 01:41:13 +0200

Hi Dmitry,

I'm cc'ing the memcached-session-manager list so that we could take this
thread over to this list...

On Sun, 2010-05-30 at 15:38 -0700, DmitryM wrote:
> Martin,
>
> Thanks a lot for the reply.
> Actually, I would appreciate if you helped me.
> I tried your tomcat session manager with my wicket app.
> I followed the configuration instructions for Tomcat you listed on the
> session manager page.
Can you post the actual configuration please?

> But it didn't seem to work for ajax requests.
> I believe I used sticky haproxy configuration (to add session id to the
> request) but it still blew up with PageExpiredException on ajax requests.
To be sure that you're sticky you can also test with just one tomcat.

Do you see anything in the logs that's helpful?

Please can you add this to $CATALINA_HOME/conf/logging.properties and
provide some log output?
de.javakaffee.web.msm.MemcachedBackupSessionManager.level = FINEST
de.javakaffee.web.msm.SessionIdFormat.level = FINEST
de.javakaffee.web.msm.NodeAvailabilityCache.level = FINEST

Btw. you should tell haproxy to consider only a part of the session-id,
as the session-id contains the memcached node encoded (like the
jvm-route), like this:
602F7397FBE4D9932E59A9D0E52FE178-n1
or
602F7397FBE4D9932E59A9D0E52FE178-n1.tc1
if you have configured a jvmroute.

Perhaps haproxy allows to set a pattern, or also the length to use
should be possible (default sessionid length is configurable in tomcat
IIRC).

>
> And there is even more significant issue: the protocol will eventually be
> secured (https) and haproxy (used in production) wouldn't be able to support
> sticky sessions in that case.
For this you should do SSL offloading in front of haproxy (stunnel?).
Are you forced to use haproxy btw? Some time ago I also looked for
alternatives to the usual suspects, and got good results with nginx
(also with SSL and sticky sessions IIRC).

Cheers,
Martin

>
> I can verify one more time my configuration (to make sure I use sticky
> sessions, sync session storage/retrieval, same request renderng etc.) and
> will let you know if it worked for me or not.
>
> Thanks,
> Dmitry

[nskmda]

Hi, Martin

Thanks a lot for your previous help.
I checked my configuration and everything worked fine with sticky
sessions (the issue about using them is at the end of message).

But when I tried to switch to non-sticky sessions, I started getting
PageExpiredExceptions.
The configuration for non-sticky sessions is below:

************ wicket app ************

getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER);
************ end of wicket app ************

************ haproxy **************
global
user nobody
group nogroup
# chroot /home/haproxy
pidfile /haproxy.pid
daemon
debug
# log 127.0.0.1 local0
maxconn 24576
ulimit-n 65536
# nbproc 2

# stats enable # enable web-stats at /haproxy?
stats
# stats uri /haproxy?stats # stats URL set to /admin?stats
# stats auth admin:okmnji # force HTTP Auth to view stats
# stats refresh 5s # refresh rate of stats page


# ===============================================================

defaults applications HTTP
mode http
log global
timeout client 40000 # maximum inactivity time on the
client side
timeout server 40000 # maximum inactivity time on the
server side
timeout connect 4000 # maximum time to wait for a
connection attempt to a server to succeed
option httpclose # disable keepalive (HAProxy does
not yet support the HTTP keep-alive mode)
option abortonclose # enable early dropping of aborted
requests from pending queue
option httpchk # enable HTTP protocol to check on
servers health
option forwardfor # enable insert of X-Forwarded-For
headers
option redispatch # Redispatch to different back-end
if currently assigned one fails.
balance leastconn # decide on which server to use
depending on connection numbers
#cookie SERVERID insert nocache indirect # Set a cookie marking
the server UUID for persistence

listen http_proxy 127.0.0.1:80
balance roundrobin #rdp-cookie #roundrobin # Load Balancing
algorithm
option httpchk
option forwardfor # This sets X-Forwarded-For
## Define your servers to balance
server web1 127.0.0.1:8081 weight 1 maxconn 512 check #cookie web1
check
server web2 127.0.0.1:8082 weight 1 maxconn 512 check #cookie web2
check

************ end of haproxy************

************ tomcat context.xml ************
<Manager
className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:localhost:${tomcat.memcached.node.port.1}
n2:localhost:${tomcat.memcached.node.port.2}"
failoverNodes="n${tomcat.memcached.node.idx}"
requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$"
sessionBackupAsync="true"
sessionBackupTimeout="100"

transcoderFactoryClass="de.javakaffee.web.msm.JavaSerializationTranscoderFactory"
copyCollectionsForSerialization="false"
/>
************ end of tomcat context.xml ************

************ tomcat server.xml ************
no special configuration - just different connector ports for
different instances
<Connector port="${tomcat.server.httpport}" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
************ end of tomcat server.xml ************

************ tomcat logging.properties ************
#Session manager log configuration

de.javakaffee.web.msm.MemcachedBackupSessionManager.level = FINEST
de.javakaffee.web.msm.SessionIdFormat.level = FINEST
de.javakaffee.web.msm.NodeAvailabilityCache.level = FINEST

************ end of tomcat logging.properties ************

I'm still not sure how to attach log file output here...

There is still a problem to use sticky sessions. The app is required
to be as secure as possible, so web traffic is encrypted wherever
possible.
And unfortunately, using haproxy for balancing is a requirement as
well. =(
The target (prod) infrastructure is like this:

- nginx - offloads SSL request to the load balancer (haproxy) cloud
instance (vm)
- haproxy - sends request to an app server cloud instance (vm) - this
request needs to be encrypted as well
- app server (w/wicket) - handles request

So, haproxy should handle requests and responses transparently and
there doesn't seem to be an easy way to use sticky sessions (even that
stickyness is questioned in regards of scalability).

Any response will be highly appreciated.

Thanks,
Dmitry

[Martin Grotzke]

Hi Dmitry,

can you put the attached jar in tomcat/lib and test with this?

It's a patched session manager jar that doesn't store sessions in the
local session map at all but always retrieves it from memcached.

Also please set sessionBackupAsync="false" in the manager configuration.

I tested a very simple wicket app here with two tomcats and your
provided haproxy config (at least I used the listen part),
ONE_PASS_RENDER strategy, HttpSessionStore in newSessionStore and
basically it seems to work.
The only strangy thing I notice is that, when I access a new page the
result of the first action seemed to get lost (e.g. clicking a link
that just increments an AtomicInteger stored as field of the page).
After I changed ONE_PASS_RENDER to REDIRECT_TO_RENDER this issue was
gone.

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[nskmda]

Martin, thanks a lot.
I will definitely give it a shot tomorrow morning first thing.

Regards,
Dmitry

On May 31, 4:20 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

>  memcached-session-manager-1.3.3.jar
> 117KViewDownload

[nskmda]

Martin,

Excellent job, thanks a lot!
It works great!

The app is running in the default rendering mode, session manager is
sync offloading data to memcached, patched version is used.
The cluster of 2 tomcat nodes works fine.
I started both, did some testing.
Got the the page with ajax behavior. Shut down one node. Clicked an
ajax button - it worked!

The only (most likely not related to the session manager itself) thing
is ajax performance - it seemed to take extra 2-3 seconds (compared to
the regular performance) for the ajax action to complete.
My guess is it may be related to the default PageStore used by the app
(it may be a slow DiskPageStore).
I will experiment with that later (may be try to use some other
PageStore implementation, like Victor's one -
http://letsgetdugg.com/2010/02/07/clustering-wicket-for-fun-and-profit/
I would prefer it over Hazelcast since memcached is used by session
manager and by Hibernate second level cache in the app, so introducing
an extra lib would be an overhead).

Thanks again, Martin!
Really appreciate your job.

[Martin Grotzke]

On Tue, Jun 1, 2010 at 7:34 PM, nskmda <nsk...@gmail.com> wrote:
> Martin,
>
> Excellent job, thanks a lot!
> It works great!
>
> The app is running in the default rendering mode, session manager is
> sync offloading data to memcached, patched version is used.
> The cluster of 2 tomcat nodes works fine.
> I started both, did some testing.
> Got the the page with ajax behavior. Shut down one node. Clicked an
> ajax button - it worked!

Great it's working for you, so I'll add an option like
'stickySessions' that does what I hacked for you when set to 'false'.

What I'm wondering: how can you run it with the default rendering
mode? REDIRECT_TO_BUFFER stores rendered responses in a map stored in
the WebApplication, so such a buffered response would not be available
in another tomcat (if the redirect after the action hits a different
tomcat)?
See o.a.w.protocol.http.WebApplication.popBufferedResponse(sessionId, bufferId).

Btw, there's already an unreleased serialization strategy based on
kryo, a serialization lib that is one of the fastest according to
http://code.google.com/p/thrift-protobuf-compare/wiki/BenchmarkingV2
... and I've done my own benchmark:
http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategyBenchmark
If you'll use msm I'd recommend to use this. I can send you the
unreleased jar if you want... :-)

>
> The only (most likely not related to the session manager itself) thing
> is ajax performance - it seemed to take extra 2-3 seconds (compared to
> the regular performance) for the ajax action to complete.

2-3 secs are rather long. Can you checkout jmx stats and look what msm
number are, according to
http://code.google.com/p/memcached-session-manager/wiki/JMXStatistics ?
Especially msmStatEffectiveBackupInfo and
msmStatSessionsLoadedFromMemcachedInfo are helpful here.
Also msmStatCachedDataSizeInfo is interesting...

> My guess is it may be related to the default PageStore used by the app
> (it may be a slow DiskPageStore).

So you aren't you using HttpSessionStore already?

> I will experiment with that later (may be try to use some other
> PageStore implementation, like Victor's one -
> http://letsgetdugg.com/2010/02/07/clustering-wicket-for-fun-and-profit/
> I would prefer it over Hazelcast since memcached is used by session
> manager and by Hibernate second level cache in the app, so introducing
> an extra lib would be an overhead).

Yes, looks like an interesting alternative. I've read this post these
days when it was referred by
http://wicketbyexample.com/apache-wicket-clustering-with-multiple-options/
but to me it's not an option since I need the whole session actually
for failover, not only wicket pagemaps.
If you can be sure that nothing get's stored additionally in the
session you might try to rely on this and don't use msms at all.
Plz let me know how it works for you!

Cheers,
Martin

>
> Thanks again, Martin!
> Really appreciate your job.

--
Martin Grotzke
http://www.javakaffee.de/blog/

[nskmda]

Martin,

I almost missed your response, sorry.

I'm actually okay even with base serialization strategy I'm using now.
I will try to check statistics via JMX to make sure, but I believe
this is not related to your session manager at all.

As I was told in Wicket forum there is extra stuff in Session which
may be serialized so, only storing PageMap in memcached won't work, I
still need proper session replication.

Yes, I'm using SecondLevelCacheSessionStore (extends HttpSessionStore)
but it used DiskPageStore.
But as I said I don't think this is an actual reason.

The thing is I added calls logging to my PageStore implementation
(Hazelcast based) and I see that Wicket always stores a page version.
But it doesn't always retrieve it from PageStore. Looks like there is
something they're storing in memory (in Session? anywhere else? =)
and kind of 'quickly' restore it to server a request.
But when it comes to replication (tomcat is down, request hits another
server/session) then that mystical in-memory data is missing and
Wicket has to de-serialize it/request from PageStore or something...
I guess this is where that delay (on ajax action) comes from.

-Dmitry

On Jun 1, 2:30 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

> On Tue, Jun 1, 2010 at 7:34 PM, nskmda <nsk...@gmail.com> wrote:
> > Martin,
>
> > Excellent job, thanks a lot!
> > It works great!
>
> > The app is running in the default rendering mode, session manager is
> > sync offloading data to memcached, patched version is used.
> > The cluster of 2 tomcat nodes works fine.
> > I started both, did some testing.
> > Got the the page with ajax behavior. Shut down one node. Clicked an
> > ajax button - it worked!
>
> Great it's working for you, so I'll add an option like
> 'stickySessions' that does what I hacked for you when set to 'false'.
>
> What I'm wondering: how can you run it with the default rendering
> mode? REDIRECT_TO_BUFFER stores rendered responses in a map stored in
> the WebApplication, so such a buffered response would not be available
> in another tomcat (if the redirect after the action hits a different
> tomcat)?
> See o.a.w.protocol.http.WebApplication.popBufferedResponse(sessionId, bufferId).
>
> Btw, there's already an unreleased serialization strategy based on

> kryo, a serialization lib that is one of the fastest according tohttp://code.google.com/p/thrift-protobuf-compare/wiki/BenchmarkingV2
> ... and I've done my own benchmark:http://code.google.com/p/memcached-session-manager/wiki/Serialization...

> If you'll use msm I'd recommend to use this. I can send you the
> unreleased jar if you want... :-)
>
>
>
> > The only (most likely not related to the session manager itself) thing
> > is ajax performance - it seemed to take extra 2-3 seconds (compared to
> > the regular performance) for the ajax action to complete.
>
> 2-3 secs are rather long. Can you checkout jmx stats and look what msm
> number are, according tohttp://code.google.com/p/memcached-session-manager/wiki/JMXStatistics?
> Especially msmStatEffectiveBackupInfo and
> msmStatSessionsLoadedFromMemcachedInfo are helpful here.
> Also msmStatCachedDataSizeInfo is interesting...
>
> > My guess is it may be related to the default PageStore used by the app
> > (it may be a slow DiskPageStore).
>
> So you aren't you using HttpSessionStore already?
>
> > I will experiment with that later (may be try to use some other
> > PageStore implementation, like Victor's one -
> >http://letsgetdugg.com/2010/02/07/clustering-wicket-for-fun-and-profit/
> > I would prefer it over Hazelcast since memcached is used by session
> > manager and by Hibernate second level cache in the app, so introducing
> > an extra lib would be an overhead).
>
> Yes, looks like an interesting alternative. I've read this post these

> days when it was referred byhttp://wicketbyexample.com/apache-wicket-clustering-with-multiple-opt...

[nskmda]

Martin,

The similar on the second node (after shutting down the first one,
after the first click on ajax button):
Cached Data Size Info: 1/6848/6847/6847
Effective Backup Info: 1/18/18/18
Sessions Loaded From Memcached: 2/10/107/204

Hope, this may help.

-Dmitry

On Jun 1, 2:30 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

> On Tue, Jun 1, 2010 at 7:34 PM, nskmda <nsk...@gmail.com> wrote:
> > Martin,
>
> > Excellent job, thanks a lot!
> > It works great!
>
> > The app is running in the default rendering mode, session manager is
> > sync offloading data to memcached, patched version is used.
> > The cluster of 2 tomcat nodes works fine.
> > I started both, did some testing.
> > Got the the page with ajax behavior. Shut down one node. Clicked an
> > ajax button - it worked!
>
> Great it's working for you, so I'll add an option like
> 'stickySessions' that does what I hacked for you when set to 'false'.
>
> What I'm wondering: how can you run it with the default rendering
> mode? REDIRECT_TO_BUFFER stores rendered responses in a map stored in
> the WebApplication, so such a buffered response would not be available
> in another tomcat (if the redirect after the action hits a different
> tomcat)?
> See o.a.w.protocol.http.WebApplication.popBufferedResponse(sessionId, bufferId).
>
> Btw, there's already an unreleased serialization strategy based on

> kryo, a serialization lib that is one of the fastest according tohttp://code.google.com/p/thrift-protobuf-compare/wiki/BenchmarkingV2
> ... and I've done my own benchmark:http://code.google.com/p/memcached-session-manager/wiki/Serialization...

> If you'll use msm I'd recommend to use this. I can send you the
> unreleased jar if you want... :-)
>
>
>
> > The only (most likely not related to the session manager itself) thing
> > is ajax performance - it seemed to take extra 2-3 seconds (compared to
> > the regular performance) for the ajax action to complete.
>
> 2-3 secs are rather long. Can you checkout jmx stats and look what msm
> number are, according tohttp://code.google.com/p/memcached-session-manager/wiki/JMXStatistics?
> Especially msmStatEffectiveBackupInfo and
> msmStatSessionsLoadedFromMemcachedInfo are helpful here.
> Also msmStatCachedDataSizeInfo is interesting...
>
> > My guess is it may be related to the default PageStore used by the app
> > (it may be a slow DiskPageStore).
>
> So you aren't you using HttpSessionStore already?
>
> > I will experiment with that later (may be try to use some other
> > PageStore implementation, like Victor's one -
> >http://letsgetdugg.com/2010/02/07/clustering-wicket-for-fun-and-profit/
> > I would prefer it over Hazelcast since memcached is used by session
> > manager and by Hibernate second level cache in the app, so introducing
> > an extra lib would be an overhead).
>
> Yes, looks like an interesting alternative. I've read this post these

> days when it was referred byhttp://wicketbyexample.com/apache-wicket-clustering-with-multiple-opt...

[nskmda]

Martin, here is the statistics on ajax request right after click
(after the node was started and another node shut down):
- initial values - all 0s
- after ajax button click (count/min/avg/max):
Cached Data Size info: 1/6884/6884/6884
Effective Backup Info: 1/30/30/30
Sessions Loaded From Memcached Info: 2/8/118/228

What do you think it means?

Regards,
Dmitry

On Jun 1, 2:30 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

> On Tue, Jun 1, 2010 at 7:34 PM, nskmda <nsk...@gmail.com> wrote:
> > Martin,
>
> > Excellent job, thanks a lot!
> > It works great!
>
> > The app is running in the default rendering mode, session manager is
> > sync offloading data to memcached, patched version is used.
> > The cluster of 2 tomcat nodes works fine.
> > I started both, did some testing.
> > Got the the page with ajax behavior. Shut down one node. Clicked an
> > ajax button - it worked!
>
> Great it's working for you, so I'll add an option like
> 'stickySessions' that does what I hacked for you when set to 'false'.
>
> What I'm wondering: how can you run it with the default rendering
> mode? REDIRECT_TO_BUFFER stores rendered responses in a map stored in
> the WebApplication, so such a buffered response would not be available
> in another tomcat (if the redirect after the action hits a different
> tomcat)?
> See o.a.w.protocol.http.WebApplication.popBufferedResponse(sessionId, bufferId).
>
> Btw, there's already an unreleased serialization strategy based on

> kryo, a serialization lib that is one of the fastest according tohttp://code.google.com/p/thrift-protobuf-compare/wiki/BenchmarkingV2
> ... and I've done my own benchmark:http://code.google.com/p/memcached-session-manager/wiki/Serialization...

> If you'll use msm I'd recommend to use this. I can send you the
> unreleased jar if you want... :-)
>
>
>
> > The only (most likely not related to the session manager itself) thing
> > is ajax performance - it seemed to take extra 2-3 seconds (compared to
> > the regular performance) for the ajax action to complete.
>
> 2-3 secs are rather long. Can you checkout jmx stats and look what msm
> number are, according tohttp://code.google.com/p/memcached-session-manager/wiki/JMXStatistics?
> Especially msmStatEffectiveBackupInfo and
> msmStatSessionsLoadedFromMemcachedInfo are helpful here.
> Also msmStatCachedDataSizeInfo is interesting...
>
> > My guess is it may be related to the default PageStore used by the app
> > (it may be a slow DiskPageStore).
>
> So you aren't you using HttpSessionStore already?
>
> > I will experiment with that later (may be try to use some other
> > PageStore implementation, like Victor's one -
> >http://letsgetdugg.com/2010/02/07/clustering-wicket-for-fun-and-profit/
> > I would prefer it over Hazelcast since memcached is used by session
> > manager and by Hibernate second level cache in the app, so introducing
> > an extra lib would be an overhead).
>
> Yes, looks like an interesting alternative. I've read this post these

> days when it was referred byhttp://wicketbyexample.com/apache-wicket-clustering-with-multiple-opt...

[nskmda]

Martin,

I double checked the behaviour and it looks like it doesn't matter if
that's ajax action or not.
After one of the nodes is down the first action always takes 2+ extra
seconds to complete

Any suggestions?

Dmitry

[Martin Grotzke]

Hi Dmitry,

On Thu, Jun 3, 2010 at 9:38 PM, nskmda <nsk...@gmail.com> wrote:
> Martin, here is the statistics on ajax request right after click
> (after the node was started and another node shut down):
> - initial values - all 0s
> - after ajax button click (count/min/avg/max):
> Cached Data Size info: 1/6884/6884/6884

The number of bytes sent to memcached -> 6.8kb (this is ok, not too much)

> Effective Backup Info: 1/30/30/30
The time in millis that was spent in the request thread for session
backup, so your request took 30ms longer to complete here. Also ok.

> Sessions Loaded From Memcached Info: 2/8/118/228

Two sessions were loaded from memcached, 8ms was the min time, 118 was
average, and 228 was the max time it took to load a session.
I wonder why 2 sessions were loaded from memcached. The time it took is ok IMO.

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[Martin Grotzke]

Are you testing against haproxy? To make sure that haproxy is not the
cause you can run 2 tomcats on localhost on different ports and first
request tomcat1 and afterwards tomcat2. Does this also take such a
long time?

Can you use just HttpSessionStore to be sure that everything is just
stored in the session? And there are not other things besides
tomcat/wicket/msm are involved?

It would be cool if you could provide a simple quickstart app that
demonstrates the issue so that I could have a look at it.

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[nskmda]

Martin,

I will try your suggestion about skipping haproxy later.
But I tried to switch to plain HttpSessionStore and get the following:

java.lang.ExceptionInInitializerError
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:
25)
at
sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:
122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
at java.lang.reflect.Field.getLong(Field.java:528)
at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:
1614)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:
1583)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:
1496)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:
480)
at org.apache.wicket.Component.readObject(Component.java:4457)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:
974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1849)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes(JavaSerializationTranscoder.java:
177)
at
de.javakaffee.web.msm.TranscoderService.deserializeAttributes(TranscoderService.java:
156)
at
de.javakaffee.web.msm.TranscoderService.deserialize(TranscoderService.java:
113)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.loadFromMemcached(MemcachedBackupSessionManager.java:
736)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.findSession(MemcachedBackupSessionManager.java:
481)
at org.apache.catalina.connector.Request.doGetSession(Request.java:
2363)
at org.apache.catalina.connector.Request.getSession(Request.java:
2098)
at
org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:
833)
at
org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:
82)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:
75)
at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:
150)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:
237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:
167)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
206)
at
com.mobioid.core.utils.UserLocaleFilter.doFilter(UserLocaleFilter.java:
34)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
191)
at
de.javakaffee.web.msm.SessionTrackerValve.invoke(SessionTrackerValve.java:
90)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
852)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
489)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.apache.wicket.WicketRuntimeException: There is no
application attached to current thread http-8082-7
at org.apache.wicket.Application.get(Application.java:179)
at
org.apache.wicket.injection.web.InjectorHolder.getInjector(InjectorHolder.java:
67)
at
com.mobioid.modules.payment.ui.manage.organization.OrganizationController.<init>(OrganizationController.java:
56)
at
com.mobioid.modules.payment.ui.manage.organization.OrganizationController.<clinit>(OrganizationController.java:
59)
... 91 more


I have InjectorHolder.getInjector().inject(this); to inject Spring
dependencies in one of the classes (just plain utility class, nothing
special) and that causes that issue.
Apparently, it blows up in the Wicket Application class where it's
trying to do current.get() where current is a ThreadLocal<Application>
reference.
Looks like when the session is deserialized the Application.set() is
not called for some reason (which doesn't set current
ThreadLocal<Application> reference).

I saw some recommendation (related to the 'standard' multicast Tomcat
clustering with Wicket) to configure Tomcat session deserialization
policy on session replication (http://apache-wicket.
1842946.n4.nabble.com/A-few-clustering-questions-
td1863992.html#a1863993):

"The only thing to consider, as I
mentioned before, is to configure your container to deserialize
session attributes immediately after being replicated to another
cluster node. Wicket uses this to save the serialized page to target
node's diskpagestore. "

But that recommendation was related to using
SecondLevelCacheSessionStore. I'm not sure if it is still relevant
when using plain HttpSessionStore.

But, btw, what if your session manager deserialized session data after
replication? Do you think it would resolve the issue with the delay
I'm currently seeing?

-Dmitry

On Jun 4, 4:17 pm, Martin Grotzke <martin.grot...@googlemail.com>

[Martin Grotzke]

Hi Dmitry,

I think the issue is that the
HttpSessionSecurityContextRepository.loadContext (called from
SecurityContextPersistenceFilter) invokes request.getSession(), before
wicket could initialize the Application ThreadLocal:

>        at
> org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:
> 833)
>        at
> org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:
> 82)
>        at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:
> 75)

I also had similar issues which are solved with the KryoTranscoder.
You might try this and see if it also solves this issue for you.
Just add the attached jars to $WEB-INF/lib and change the following
config attributes for the Manager:

transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
customConverter="de.javakaffee.web.msm.serializer.kryo.WicketSerializerFactory,de.javakaffee.web.msm.serializer.kryo.CGLibProxySerializerFactory"

If you're using jodatime you can also add
de.javakaffee.web.msm.serializer.kryo.JodaDateTimeRegistration to the
customConverters.

> But, btw, what if your session manager deserialized session data after
> replication? Do you think it would resolve the issue with the delay
> I'm currently seeing?

I don't think this would change s.th. as the measured timings (via
jmx, the ones you provided before) are ok. Also conceptually it's not
possible, because we cannot know to which node the next request is
going. And we definitely don't want to push all sessions to all
tomcats for scalability reasons.

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[Martin Grotzke]

On Sat, Jun 5, 2010 at 1:05 AM, Martin Grotzke
<martin....@googlemail.com> wrote:
>> Sessions Loaded From Memcached Info: 2/8/118/228
> Two sessions were loaded from memcached, 8ms was the min time, 118 was
> average, and 228 was the max time it took to load a session.
> I wonder why 2 sessions were loaded from memcached. The time it took is ok IMO.

I thought about this again and it's totally clear why a session could
be loaded more than once per request from memcached. I simply missed
to store the session per request in tomcat, which is still what should
be done.
I just changed this, but right now I'm seeing weird things from tomcat
which need more investigation. Still I wanted to let you know that I'm
looking into this.

But I also think that this is not causing the 2 seconds according to
the information you provided.

Cheers,
Martin

[nskmda]

Martin,

I'm trying your suggestion with Kryo suggestion (though I was not 100%
sure if I needed to put those jars into Catalina /lib instead - that
stuff didn't seem to be required for the application itself..).
Anyway, I'm getting the following exceptions:

SEVERE: Exception during cleanup after start failed
java.lang.NullPointerException
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.stop(MemcachedBackupSessionManager.java:
1100)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:
4611)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:
4512)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:
791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:
771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:
546)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:
637)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:
563)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:
498)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:
321)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:
119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:
443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:
519)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:
710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)

at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)


...

SEVERE: Error deploying web application directory Mobio-1.0-SNAPSHOT
java.lang.NoClassDefFoundError: com/esotericsoftware/kryo/Kryo
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory.getTranscoder(KryoTranscoderFactory.java:
61)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory.createTranscoder(KryoTranscoderFactory.java:
47)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.createTranscoderService(MemcachedBackupSessionManager.java:
315)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.init(MemcachedBackupSessionManager.java:
281)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.init(MemcachedBackupSessionManager.java:
241)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.start(MemcachedBackupSessionManager.java:
1090)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:
4476)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:
791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:
771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:
546)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:
1041)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:
964)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:
502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:
321)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:
119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:
443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:
519)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:
710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)

at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: java.lang.ClassNotFoundException:
com.esotericsoftware.kryo.Kryo
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1516)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1361)
... 29 more


Any suggestions?

Regards,
Dmitry

On Jun 5, 1:34 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

> ...
>
> read more »
>
>  kryo-1.02-r110-sources.jar
> 74KViewDownload
>
>  kryo-serializers-0.6.jar
> 68KViewDownload
>
>  msm-kryo-serializer-1.3.3.jar
> 22KViewDownload

[Martin Grotzke]

Sorry, I missed some deps used by kryo, this is probably the reason
for this. Also add them to WEB-INF/lib.

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[Martin Grotzke]

On Sun, Jun 6, 2010 at 2:01 AM, Martin Grotzke

<martin....@googlemail.com> wrote:
> On Sat, Jun 5, 2010 at 1:05 AM, Martin Grotzke
> <martin....@googlemail.com> wrote:
>>> Sessions Loaded From Memcached Info: 2/8/118/228
>> Two sessions were loaded from memcached, 8ms was the min time, 118 was
>> average, and 228 was the max time it took to load a session.
>> I wonder why 2 sessions were loaded from memcached. The time it took is ok IMO.
> I thought about this again and it's totally clear why a session could
> be loaded more than once per request from memcached. I simply missed
> to store the session per request in tomcat, which is still what should
> be done.
> I just changed this, but right now I'm seeing weird things from tomcat
> which need more investigation. Still I wanted to let you know that I'm
> looking into this.

Here's an update msm jar which stores the session per request in the
local session map, and removes it at the end from the request. So for
one request all invocations of request.getSession will only trigger a
single lookup in memcached. If you're experiencing anything else
please let me know!

Cheers,
Martin

[Martin Grotzke]

Hi Dmitry,

I just cleaned up my sample wicket webapp and pushed it to github:
http://github.com/magro/msm-sample-webapp

It's configured to support non-sticky sessions and is what I use for
testing this right now.

Cheers,
Martin

[nskmda]

Martin,

I will give it a try as soon as I can get my app started. =)

Right now I'm still getting the following:

java.lang.RuntimeException: Could not load serializer
de.javakaffee.web.msm.serializer.kryo.WicketSerializerFactory
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.loadCustomConverter(KryoTranscoder.java:
273)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.createKryo(KryoTranscoder.java:
182)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.<init>(KryoTranscoder.java:
114)

at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory.getTranscoder(KryoTranscoderFactory.java:
61)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory.createTranscoder(KryoTranscoderFactory.java:
47)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.createTranscoderService(MemcachedBackupSessionManager.java:
315)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.init(MemcachedBackupSessionManager.java:
281)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.init(MemcachedBackupSessionManager.java:
241)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.start(MemcachedBackupSessionManager.java:

1086)

Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:
39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:
27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.createInstance(KryoTranscoder.java:
309)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.processElement(KryoTranscoder.java:
288)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.loadCustomConverter(KryoTranscoder.java:
270)
... 31 more
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
de.javakaffee.web.msm.serializer.kryo.WicketChildListSerializerFactory
at
de.javakaffee.web.msm.serializer.kryo.WicketSerializerFactory.<init>(WicketSerializerFactory.java:
42)
... 38 more

I've put all jars you provided to WEB-INF/lib (in my app)...
I'm not 100% sure about kryo-1.02-r110-sources.jar - it has all the
Java classes but no code. Do I need to compile it first (because I
could not find binaries for 1.02 version of Kryo, only for 1.01)

-Dmitry

On Jun 6, 3:31 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

[Martin Grotzke]

D'oh, my fault. The correct kryo jar is attached.

Sorry, I hope it didn't take you too much time.

Cheers,
Martin

[nskmda]

Martin,

Sorry about the delay.

Unfortunately, I still have a problem with the HttpSessionStore.

Here is the server's context.xml config for the app:

<Manager
className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:localhost:11211 n2:localhost:11211"
failoverNodes="n2"

requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$"

sessionBackupAsync="false"
sessionBackupTimeout="100"

transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"

customConverter="de.javakaffee.web.msm.serializer.kryo.WicketSerializerFactory,de.javakaffee.web.msm.serializer.kryo.CGLibProxySerializerFactory"
copyCollectionsForSerialization="false"
/>

The libraries in the tomcat's /lib:

memcached-2.4.2.jar
memcached-session-manager-1.3.3.jar - 88KB (this one is the
HttpSessionStore-related, last one you posted for me)

The libraries in the webapp WEB-INF/lib:
kryo-1.02-r110.jar
kryo-serializers-0.6.jar
minlog-1.2.jar
msm-kryo-serializer-1.3.3.jar
reflectasm-0.8.jar

The tomcat server starts fine, but on the first (ajax though) request
from the login page (input fields validation), I get the following
exception:

2010-06-10 09:10:53,309 ERROR - RequestCycle - Error
attaching this container for rendering: [MarkupContainer [Component id
= loginFeedbackPanel]]
org.apache.wicket.WicketRuntimeException: Error attaching this
container for rendering: [MarkupContainer [Component id =
loginFeedbackPanel]]
at
org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:
1739)
at org.apache.wicket.Component.onBeforeRender(Component.java:3855)
at org.apache.wicket.Component.internalBeforeRender(Component.java:
1061)
at org.apache.wicket.Component.prepareForRender(Component.java:2240)
at org.apache.wicket.Component.prepareForRender(Component.java:2262)
at
org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:
804)
at
org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:
680)
at
org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:
590)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:
105)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:
1258)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:
479)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
312)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
206)
at

org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:
198)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:
76)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
206)

at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:344)
at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:
110)
at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:
84)

at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
at

org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:
98)

at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
at

com.mobioid.core.security.mobioOTC.MobioOTCAuthenticationFilter.doFilter(MobioOTCAuthenticationFilter.java:
140)

at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
at

org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:
188)

at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
at

org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:
188)

at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
at

org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:
80)

at org.springframework.security.web.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
at

org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:
150)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:
237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:
167)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:

206)
at
com.mobioid.core.utils.UserLocaleFilter.doFilter(UserLocaleFilter.java:
34)
at

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
191)
at
de.javakaffee.web.msm.SessionTrackerValve.invoke(SessionTrackerValve.java:

93)

at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102)
at

org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
852)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
489)
at java.lang.Thread.run(Thread.java:637)

Caused by: java.lang.NullPointerException
at org.apache.wicket.markup.html.panel.FeedbackPanel
$1.isVisible(FeedbackPanel.java:128)
at org.apache.wicket.Component.determineVisibility(Component.java:
4423)
at org.apache.wicket.Component.internalBeforeRender(Component.java:
1050)
at org.apache.wicket.Component.beforeRender(Component.java:1095)
at
org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:
1727)
... 53 more

And the console log seems to be fine (no exceptions, just messages
like the following):

Jun 10, 2010 9:12:49 AM de.javakaffee.web.msm.SessionTrackerValve
invoke
FINE: >>>>>> Request starting: /Mobio-1.0-SNAPSHOT/
==================
Jun 10, 2010 9:12:49 AM
de.javakaffee.web.msm.MemcachedBackupSessionManager loadFromMemcached
FINE: Loading session from memcached:
F386436DACE153927E97A8DEDEC40E89-n2
Jun 10, 2010 9:12:49 AM
de.javakaffee.web.msm.MemcachedBackupSessionManager loadFromMemcached
FINE: Found session with id F386436DACE153927E97A8DEDEC40E89-n2
2010-06-10 09:12:49.184 INFO
net.spy.memcached.transcoders.SerializingTranscoder: Compressed [B
from 19353 to 3093
Jun 10, 2010 9:12:49 AM
de.javakaffee.web.msm.MemcachedBackupSessionManager remove
FINE: remove invoked, removeFromMemcached: false, id:
F386436DACE153927E97A8DEDEC40E89-n2
Jun 10, 2010 9:12:49 AM de.javakaffee.web.msm.SessionTrackerValve
invoke
FINE: <<<<<< Request finished: /Mobio-1.0-SNAPSHOT/
==================

I guess, I can try to stick to the previous configuration (with
SecondLevelCacheSessionStore + DiskPageStore).
I saw that session manager retrieved session from memcached pretty
quickly (looking at the console output) but then there was a delay
when deserializer was working.
I may need to profile it and see where that delay comes from.

-Dmitry

On Jun 7, 12:55 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

[Martin Grotzke]

Ok. Alternatively you might also provide a quickstart that allows me
to reproduce your issues so I could also have a look at it. I really
wonder what's different for your application...

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[nskmda]

Martin,

Thanks a lot for all the efforts.
But it doesn't seem to be feasible (at least right now) to have an app
with all the filters/components we're using.
But it looks like there was some Wicket-specific behaviour which
caused one of our pages to not display properly.

Anyway, the performance of the default SecondLevelCacheSessionStore +
DiskPageStore seems to be okay (we may want to implement specific
PageStore later).

I actually tried to profile the application/server.
In the case of one node just shut down and the second node just
brought up the delay I saw was caused by the memcached's own
Transcoder (it took it about 1.4 sec to deserialize data from the
session). I'm not sure if it's is actually being used by the
JavaSerializationTranscoderFactory.
But anyway, in that edge case it seems to be acceptable (so far).

Regards,
Dmitry

On Jun 10, 9:55 am, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

> Ok. Alternatively you might also provide a quickstart that allows me
> to reproduce your issues so I could also have a look at it. I really
> wonder what's different for your application...
>
> Cheers,
> Martin
>
>
>
> On Thu, Jun 10, 2010 at 6:37 PM, nskmda <nsk...@gmail.com> wrote:
> > Martin,
>
> > Sorry about the delay.
>
> > Unfortunately, I still have a problem with the HttpSessionStore.
>
> > Here is the server's context.xml config for the app:
>
> > <Manager
> > className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
> >    memcachedNodes="n1:localhost:11211 n2:localhost:11211"
> >    failoverNodes="n2"
> >    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$"
> >    sessionBackupAsync="false"
> >    sessionBackupTimeout="100"
>

> > transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscode rFactory"
>
> > customConverter="de.javakaffee.web.msm.serializer.kryo.WicketSerializerFact ory,de.javakaffee.web.msm.serializer.kryo.CGLibProxySerializerFactory"

> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio nFilterChain.java:
> > 235)
> >        at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC hain.java:
> > 206)
> >        at

> > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilter Internal(OpenSessionInViewFilter.java:
> > 198)
> >        at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequest Filter.java:
> > 76)

> >        at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio nFilterChain.java:
> > 235)
> >        at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC hain.java:

> > org.springframework.security.web.context.SecurityContextPersistenceFilter.d oFilter(SecurityContextPersistenceFilter.java:

> > 80)
> >        at org.springframework.security.web.FilterChainProxy
> > $VirtualFilterChain.doFilter(FilterChainProxy.java:356)
> >        at

> > org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy .java:
> > 150)
> >        at
> > org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(Delegat ingFilterProxy.java:
> > 237)
> >        at
> > org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFil terProxy.java:
> > 167)
> >        at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio nFilterChain.java:
> > 235)
> >        at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC hain.java:

> > 206)
> >        at
> > com.mobioid.core.utils.UserLocaleFilter.doFilter(UserLocaleFilter.java:
> > 34)
> >        at

> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio nFilterChain.java:
> > 235)
> >        at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC hain.java:
> > 206)
> >        at
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j ava:
> > 233)
> >        at
> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j ava:

> ...
>
> read more »

[Martin Grotzke]

Hi Dmitry,

On Fri, Jun 11, 2010 at 1:59 AM, nskmda <nsk...@gmail.com> wrote:
> I actually tried to profile the application/server.
> In the case of one node just shut down and the second node just
> brought up the delay I saw was caused by the memcached's own
> Transcoder (it took it about 1.4 sec to deserialize data from the
> session). I'm not sure if it's is actually being used by the
> JavaSerializationTranscoderFactory.

Which method took 1.4 sec?

Btw: last night I looked again at the exception you provided (NPE at
org.apache.wicket.markup.html.panel.FeedbackPanel$1.isVisible(FeedbackPanel.java:128))
and could reproduce this: There's an anonymous inner class created in
the constructor which is missing the reference to the outer class in
the deserialized form. This should work already, though I asked on the
kryo mailing list if they could have a look at this. I'll let you know
if there are any news.

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[Martin Grotzke]

Hi Dmitry,

I have an updated msm-kryo-serializer jar for you, this should fix the
issue with the NPE in FeedbackPanel$1.isVisible.

I'd be interested if you app is fine then with HttpSessionStore.

Cheers,
Martin

[nskmda]

Martin,

> Which method took 1.4 sec?

I ran profiler again and
mem.spy.memcached.transcoders.BaseSerializingTranscoder.decompress
seems to use that time (or around that).
But it doesn't look that critical.
Probably, I misread the output of the profiler but the Transcoder
seems to take about 2 ms (not s).

> Btw: last night I looked again at the exception you provided (NPE at

> org.apache.wicket.markup.html.panel.FeedbackPanel$1.isVisible(FeedbackPanel .java:128))

> and could reproduce this: There's an anonymous inner class created in
> the constructor which is missing the reference to the outer class in
> the deserialized form. This should work already, though I asked on the
> kryo mailing list if they could have a look at this. I'll let you know
> if there are any news.

I'm not sure what you meant saying 'should work already'. But I will
really appreciate any new information.

Regards,
Dmitry

[Martin Grotzke]

Hi Dmitry,

On Mon, Jun 14, 2010 at 7:15 PM, nskmda <nsk...@gmail.com> wrote:
> Martin,
>
>> Which method took 1.4 sec?
>
> I ran profiler again and
> mem.spy.memcached.transcoders.BaseSerializingTranscoder.decompress
> seems to use that time (or around that).
> But it doesn't look that critical.
> Probably, I misread the output of the profiler but the Transcoder
> seems to take about 2 ms (not s).

2ms are ok, so this is not be the reason for the long delay you're experiencing.

>
>> Btw: last night I looked again at the exception you provided (NPE at
>> org.apache.wicket.markup.html.panel.FeedbackPanel$1.isVisible(FeedbackPanel .java:128))
>> and could reproduce this: There's an anonymous inner class created in
>> the constructor which is missing the reference to the outer class in
>> the deserialized form. This should work already, though I asked on the
>> kryo mailing list if they could have a look at this. I'll let you know
>> if there are any news.
>
> I'm not sure what you meant saying 'should work already'. But I will
> really appreciate any new information.

If you missed my last mail (not too hard with this rather long thread
:-)): I had attached an updated version of msm-kryo-serializer, this
should fix the issue with FeedbackPanel$1.isVisible. Just add this to
WEB-INF/lib (replaces the former jar) and the NPE should be gone.

Cheers,
Martin

>
> Regards,
> Dmitry

[nskmda]

Hi, Martin

I'm actually missed your response (and somehow GG didn't allow me to
post my reply to it).
I gave the new serializer a try (along with switching to
HttpSessionStore).

Looks like it works better but still there is an issue (I didn't
mention that limitation before): our app is having a open-session-in-
view Spring request filter.
And I got the following exception from kryo:

2010-06-21 09:16:05,837 ERROR - azyInitializationException - failed to
lazily initialize a collection of role:
com.mobioid.core.domain.User.children, no session or session was
closed
org.hibernate.LazyInitializationException: failed to lazily initialize
a collection of role: com.mobioid.core.domain.User.children, no
session or session was closed
at
org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:
380)
at
org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:
372)
at
org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:
119)
at org.hibernate.collection.PersistentBag.size(PersistentBag.java:
248)
at
com.esotericsoftware.kryo.serialize.CollectionSerializer.writeObjectData(CollectionSerializer.java:
72)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.writeObjectData(FieldSerializer.java:
161)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.writeObjectData(ReferenceFieldSerializer.java:
52)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.writeObjectData(FieldSerializer.java:
161)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.writeObjectData(ReferenceFieldSerializer.java:
52)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.writeObjectData(FieldSerializer.java:
161)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.writeObjectData(ReferenceFieldSerializer.java:
52)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.writeObjectData(FieldSerializer.java:
161)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.writeObjectData(ReferenceFieldSerializer.java:
52)
at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:446)
at
com.esotericsoftware.kryo.serialize.MapSerializer.writeObjectData(MapSerializer.java:
104)
at com.esotericsoftware.kryo.Serializer.writeObject(Serializer.java:
43)
at com.esotericsoftware.kryo.Kryo.writeObject(Kryo.java:474)
at
com.esotericsoftware.kryo.ObjectBuffer.writeObject(ObjectBuffer.java:
246)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.serializeAttributes(KryoTranscoder.java:
248)
at
de.javakaffee.web.msm.TranscoderService.serializeAttributes(TranscoderService.java:
140)
at
de.javakaffee.web.msm.BackupSessionTask.serializeAttributes(BackupSessionTask.java:
150)
at
de.javakaffee.web.msm.BackupSessionTask.call(BackupSessionTask.java:
101)
at
de.javakaffee.web.msm.BackupSessionTask.call(BackupSessionTask.java:1)
at de.javakaffee.web.msm.BackupSessionService
$SynchronousExecutorService.submit(BackupSessionService.java:324)
at
de.javakaffee.web.msm.BackupSessionService.backupSession(BackupSessionService.java:
195)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.backupSession(MemcachedBackupSessionManager.java:
690)
at
de.javakaffee.web.msm.SessionTrackerValve.backupSession(SessionTrackerValve.java:
162)
at
de.javakaffee.web.msm.SessionTrackerValve.invoke(SessionTrackerValve.java:
95)

at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
852)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
489)
at java.lang.Thread.run(Thread.java:637)

Jun 21, 2010 9:16:05 AM de.javakaffee.web.msm.BackupSessionService
backupSession

I'm not sure why it's working fine with the
SecondLevelCacheSessionStore though.
Any ideas?

-Dmitry

On Jun 14, 2:29 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

>  msm-kryo-serializer-1.3.3.jar
> 22KViewDownload

[Martin Grotzke]

Hi Dmitry,

please add
de.javakaffee.web.msm.serializer.kryo.HibernateCollectionsSerializerFactory
to the customConverter attribute and let me know if this resolves this issue.

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[nskmda]

Hi, Martin

I tried the updated version with the
HibernateCollectionsSerializerFactory and I got this now:
(I had 2 nodes running, then I shut down one node (while having an
Ajax panel shown on a page. Then I tried to close that panel with Ajax
request and got the exception below - request hit the second node
which was still alive)

SEVERE: An exception or error occurred in the container during the
request processing
java.lang.ExceptionInInitializerError
at
sun.reflect.GeneratedSerializationConstructorAccessor44.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
de.javakaffee.kryoserializers.KryoReflectionFactorySupport.newInstanceFrom(KryoReflectionFactorySupport.java:
72)
at
de.javakaffee.kryoserializers.KryoReflectionFactorySupport.newInstance(KryoReflectionFactorySupport.java:
66)
at com.esotericsoftware.kryo.Serializer.newInstance(Serializer.java:
75)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
76)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:514)
at
com.esotericsoftware.kryo.serialize.ArraySerializer.readArray(ArraySerializer.java:
182)
at
com.esotericsoftware.kryo.serialize.ArraySerializer.readObjectData(ArraySerializer.java:
147)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:514)
at
com.esotericsoftware.kryo.serialize.ArraySerializer.readArray(ArraySerializer.java:
182)
at
com.esotericsoftware.kryo.serialize.ArraySerializer.readObjectData(ArraySerializer.java:
147)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.readObjectData(FieldSerializer.java:
199)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializer.readObjectData(ReferenceFieldSerializer.java:
81)
at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:514)
at
com.esotericsoftware.kryo.serialize.MapSerializer.readObjectData(MapSerializer.java:
129)
at com.esotericsoftware.kryo.Serializer.readObject(Serializer.java:
61)
at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:533)
at
com.esotericsoftware.kryo.ObjectBuffer.readObject(ObjectBuffer.java:
208)
at
de.javakaffee.web.msm.serializer.kryo.KryoTranscoder.deserializeAttributes(KryoTranscoder.java:
237)
at
de.javakaffee.web.msm.TranscoderService.deserializeAttributes(TranscoderService.java:

156)
at
de.javakaffee.web.msm.TranscoderService.deserialize(TranscoderService.java:
113)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.loadFromMemcached(MemcachedBackupSessionManager.java:

729)
at
de.javakaffee.web.msm.MemcachedBackupSessionManager.findSession(MemcachedBackupSessionManager.java:
481)
at
org.apache.catalina.connector.Request.isRequestedSessionIdValid(Request.java:
2162)
at
org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:
610)
at
org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:
514)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
296)

at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
852)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
489)
at java.lang.Thread.run(Thread.java:637)

Caused by: org.apache.wicket.WicketRuntimeException: There is no

application attached to current thread http-8081-7

at org.apache.wicket.Application.get(Application.java:179)
at
org.apache.wicket.injection.web.InjectorHolder.getInjector(InjectorHolder.java:
67)
at

com.mobioid.modules.payment.ui.manage.PaymentTypeController.<init>(PaymentTypeController.java:
31)
at
com.mobioid.modules.payment.ui.manage.PaymentTypeController.<clinit>(PaymentTypeController.java:
34)
... 48 more

I managed to go through the login page though...
I'm not sure if it makes sense to spend more time on this.
SecondLevelCacheSessionStore + DiskPageStore seem to work fine for us.

-Dmitry

[Martin Grotzke]

Hi Dmitry,

agreed, because SecondLevelCacheSessionStore + DiskPageStore seem to
work fine for you it's not worth it putting that much time into this.

I'd still be interested in solving this, but for this we should have a
simple quickstart webapp that contains the important stuff and allows
to reproduce these issues. Creating this would also need time... :-)

So I hope it's working fine for you now, if there are any things to
solve let me know :-)

Cheers,
Martin

--
Martin Grotzke
http://www.javakaffee.de/blog/

[Matt Ashley]

Hi Martin and Dmitry,

I know this post is extremely old, but it is right up my alley and I'm wondering if you can help me out. We recently clustered our Wicket app using and AWS load balancer and tomcat memcached session manager. No sticky sessions. It seems as though we can navigate to different pages without an issue (request going to all nodes). However, when a Wicket Ajax call goes to a different node than the node that original created the page we received component not found exceptions.

Our tomcat memcached session config is as follows:

<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"

memcachedNodes="memcachedserver:11211"

sticky="false"

            sessionBackupAsync="false"

            lockingMode="all"

sessionBackupTimeout="5000"

operationTimeout="5000"

requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"

/>

We tried implementing the wicket and joda data kryo serializers, but ran into a lot of problems so we are just using default java serialization for now. Or wicket configuration is:

@Override

public void init(){

super.init();

getRequestCycleSettings().setRenderStrategy(RenderStrategy.ONE_PASS_RENDER);

//Store previous PageMaps in HttpSession instead of on local disk for clustering.

setPageManagerProvider(new DefaultPageManagerProvider(this){

@Override

protected IDataStore newDataStore() {

return new HttpSessionDataStore(getPageManagerContext(), new PageNumberEvictionStrategy(100));

}

});

Not sure if this is a wicket issue or a memcached session manager issue. I've posted a message on the wicket forum too. http://apache-wicket.1842946.n4.nabble.com/Wicket-6-Clustering-Component-Not-Found-Exception-td4673610.html

Using Tomcat 8, wicket 6.11, and memcached session manager 1.8.3.

Thanks for any help you can provide!

Matt

[Martin Grotzke]

Hi Matt,

have you gone through all messages? While quickly scanning some messages
I saw e.g. some REDIRECT_TO_RENDER being mentioned. If you've not yet
done this please check discussed solutions.

Apart from this I'd suggest to use 1.9.1 which I released last week,
just to have the latest version which makes debugging easier.

If you cannot find a solution I'd suggest that you create a reproducable
sample app based on
https://github.com/magro/memcached-session-manager/tree/master/samples
(you may also check out the rather old
https://github.com/magro/msm-sample-webapp).

Cheers,
Martin

> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "memcached-session-manager" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to memcached-session-...@googlegroups.com
> <mailto:memcached-session-...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Matt Ashley]

Hi Martin,

Thank you for your quick reply. I had to wait for the weekend for further testing. I've upgraded to the latest version of memcached session manager 1.9.1 but that didn't work. Someone on the wicket forum suggested I update an attribute in the session every request to set it as changed/dirty so I tried that as well and that didn't work. They also suggested that I added logging to the HttpSessionDataStore class.

The logging turned up something intriguing. The first ajax request went to the server that initially loaded the page. The 2nd ajax request went to another node where the component not found error occurred. The page length in bytes is about 2k bytes smaller on the failed request than the working request. Same page Id (0). Any thoughts on why that might be? 

Please see logs below, and thank you for any help you can provide!

LOG - NODE 1 - Loaded the initial page - WORKED
20-Feb-2016 09:47:15.262 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.MemcachedSessionService.loadFromMemcached Loading session from memcached: E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:15.262 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.LockingStrategy.lock Locking session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:15.269 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.LockingStrategy.acquireLock Locked session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:15.269 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.LockingStrategy.lock Locked session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:15.274 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'Wicket:SessionUnbindingListener-wicket.Title1Crate' with value 'org.apache.wicket.session.HttpSessionStore$SessionBindingListener@695de0f1' 
20-Feb-2016 09:47:15.280 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:page:store:memory' with value 'org.apache.wicket.pageStore.memory.PageTable@125b2442' 
20-Feb-2016 09:47:15.280 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:session' with value 'com._806technologies.title1cratecore.components.T1CSession@1da97278' 
20-Feb-2016 09:47:15.280 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:timestamp' with value 'Sat Feb 20 09:46:46 CST 2016' 
20-Feb-2016 09:47:15.281 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:wicket:persistentPageManagerData - wicket.Title1Crate' with value 'org.apache.wicket.page.PageStoreManager$SessionEntry@5f9a337e' 
20-Feb-2016 09:47:15.282 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.MemcachedSessionService.loadFromMemcached Found session with id E24FAB17D7B8C7AD74186C659F219E9D 
DEBUG - ServletWebRequest          - Calculating context relative path from: context path '', filterPrefix '', uri '/wicket/page' 
DEBUG - CompoundRequestMapper      - One compatible mapper found for URL 'wicket/page?0-1.IBehaviorListener.0-pnlMain-pnlUploaderPanel-cntFileUploader&wicket-ajax=true&wicket-ajax-baseurl=eCrate' -> 'Mapper: org.apache.wicket.core.request.mapper.PageInstanceMapper; Score: 2147483647' 
DEBUG - PageAccessSynchronizer     - 'http-apr-443-exec-1' attempting to acquire lock to page with id '0' 
DEBUG - PageAccessSynchronizer     - http-apr-443-exec-1 acquired lock to page 0 
INFO  - BlockTimer                 - getDataObject, t=4 milliseconds 
WARN  - AmazonS3Client             - No content length specified for stream data.  Stream contents will be buffered in memory and could result in out of memory errors. 
INFO  - BlockTimer                 - getDataObject, t=2 milliseconds 
INFO  - BlockTimer                 - getDataObject, t=9 milliseconds 
DEBUG - Page                       - ending request for page [Page class = com._806technologies.title1crateweb.MainPage, id = 0, render count = 1], request org.apache.wicket.protocol.http.servlet.ServletWebRequest@449d2f28 
DEBUG - Page                       - ending request for page [Page class = com._806technologies.title1crateweb.MainPage, id = 0, render count = 1], request org.apache.wicket.protocol.http.servlet.ServletWebRequest@449d2f28 
INFO  - 806HttpSessionDataStoreLog - StoreData session id: E24FAB17D7B8C7AD74186C659F219E9D page id: 0 byte length: 7097
INFO  - T806WebApplication         - Writing Timestamp to session. 
DEBUG - PageAccessSynchronizer     - 'http-apr-443-exec-1' released lock to page with id '0' 
DEBUG - PageAccessSynchronizer     - 'http-apr-443-exec-1' notifying blocked threads 
20-Feb-2016 09:47:16.335 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.BackupSessionService.backupSession Starting for session id E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:16.335 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.BackupSessionTask.call Starting for session id E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:16.337 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'Wicket:SessionUnbindingListener-wicket.Title1Crate' with value 'org.apache.wicket.session.HttpSessionStore$SessionBindingListener@695de0f1' 
20-Feb-2016 09:47:16.338 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:page:store:memory' with value 'org.apache.wicket.pageStore.memory.PageTable@125b2442' 
20-Feb-2016 09:47:16.338 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:session' with value 'com._806technologies.title1cratecore.components.T1CSession@1da97278' 
20-Feb-2016 09:47:16.338 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:timestamp' with value 'Sat Feb 20 09:47:16 CST 2016' 
INFO  - 806HttpSessionDataStoreLog - calling isReplicated 
20-Feb-2016 09:47:16.338 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:wicket:persistentPageManagerData - wicket.Title1Crate' with value 'org.apache.wicket.page.PageStoreManager$SessionEntry@5f9a337e' 
20-Feb-2016 09:47:16.339 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.BackupSessionTask.doBackupSession Trying to store session in memcached: E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:16.351 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.BackupSessionTask.call Finished for session id E24FAB17D7B8C7AD74186C659F219E9D, returning status SUCCESS 
20-Feb-2016 09:47:16.351 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.BackupSessionTask.releaseLock Releasing lock for session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:16.366 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.LockingStrategy.onAfterBackupSession Stored session validity info for session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:47:16.366 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.RequestTrackingHostValve.logDebugRequestSessionCookie Have request session cookie: domain=null, maxAge=-1, path=null, value=E24FAB17D7B8C7AD74186C659F219E9D, version=0, secure=false 
20-Feb-2016 09:47:16.367 FINE [http-apr-443-exec-1] de.javakaffee.web.msm.RequestTrackingHostValve.invoke <<<<<< Request finished: POST /wicket/page ================== 


LOG - NODE 2 - COMP. NOT FOUND
20-Feb-2016 09:48:46.103 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.MemcachedSessionService.loadFromMemcached Loading session from memcached: E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.103 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.LockingStrategy.lock Locking session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.111 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.LockingStrategy.acquireLock Locked session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.111 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.LockingStrategy.lock Locked session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.116 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'Wicket:SessionUnbindingListener-wicket.Title1Crate' with value 'org.apache.wicket.session.HttpSessionStore$SessionBindingListener@5124ccb5' 
20-Feb-2016 09:48:46.117 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:page:store:memory' with value 'org.apache.wicket.pageStore.memory.PageTable@46fba8b1' 
20-Feb-2016 09:48:46.117 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:session' with value 'com._806technologies.title1cratecore.components.T1CSession@340020df' 
20-Feb-2016 09:48:46.117 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:timestamp' with value 'Sat Feb 20 09:48:32 CST 2016' 
20-Feb-2016 09:48:46.118 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.deserializeAttributes   loading attribute 'wicket:wicket.Title1Crate:wicket:persistentPageManagerData - wicket.Title1Crate' with value 'org.apache.wicket.page.PageStoreManager$SessionEntry@746e2b24' 
20-Feb-2016 09:48:46.120 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.MemcachedSessionService.loadFromMemcached Found session with id E24FAB17D7B8C7AD74186C659F219E9D 
DEBUG - ServletWebRequest          - Calculating context relative path from: context path '', filterPrefix '', uri '/wicket/page' 
DEBUG - CompoundRequestMapper      - One compatible mapper found for URL 'wicket/page?0-1.IBehaviorListener.0-pnlMain-pnlUploaderPanel-cntFileUploader&wicket-ajax=true&wicket-ajax-baseurl=eCrate' -> 'Mapper: org.apache.wicket.core.request.mapper.PageInstanceMapper; Score: 2147483647' 
DEBUG - PageAccessSynchronizer     - 'http-apr-443-exec-7' attempting to acquire lock to page with id '0' 
DEBUG - PageAccessSynchronizer     - http-apr-443-exec-7 acquired lock to page 0 
ERROR - DefaultExceptionMapper     - Unexpected error occurred 
org.apache.wicket.core.request.handler.ComponentNotFoundException: Could not find component 'pnlMain:pnlUploaderPanel:cntFileUploader' on page 'class com._806technologies.title1crateweb.MainPage 
        at org.apache.wicket.core.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:182) 
        at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.getComponent(ListenerInterfaceRequestHandler.java:90) 
        at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:231) 
        at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:861) 
        at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) 
        at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) 
        at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) 
        at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) 
        at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) 
        at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) 
        at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) 
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) 
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
        at com._806technologies.utils.AWSELBHttpsRedirectFilter.doFilter(AWSELBHttpsRedirectFilter.java:45) 
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) 
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) 
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) 
        at de.javakaffee.web.msm.RequestTrackingContextValve.invoke(RequestTrackingContextValve.java:99) 
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) 
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) 
        at de.javakaffee.web.msm.RequestTrackingHostValve.invoke(RequestTrackingHostValve.java:156) 
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) 
        at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:617) 
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) 
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518) 
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091) 
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658) 
        at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2463) 
        at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2452) 
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) 
        at java.lang.Thread.run(Thread.java:745) 
DEBUG - Page                       - ending request for page [Page class = com._806technologies.title1crateweb.MainPage, id = 0, render count = 1], request org.apache.wicket.protocol.http.servlet.ServletWebRequest@30560be1 
DEBUG - Page                       - ending request for page [Page class = com._806technologies.title1crateweb.MainPage, id = 0, render count = 1], request org.apache.wicket.protocol.http.servlet.ServletWebRequest@30560be1 
INFO  - 806HttpSessionDataStoreLog - StoreData session id: E24FAB17D7B8C7AD74186C659F219E9D page id: 0 byte length: 5198
INFO  - T806WebApplication         - Writing Timestamp to session. 
DEBUG - PageAccessSynchronizer     - 'http-apr-443-exec-7' released lock to page with id '0' 
DEBUG - PageAccessSynchronizer     - 'http-apr-443-exec-7' notifying blocked threads 
20-Feb-2016 09:48:46.826 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.BackupSessionService.backupSession Starting for session id E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.827 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.BackupSessionTask.call Starting for session id E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.827 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'Wicket:SessionUnbindingListener-wicket.Title1Crate' with value 'org.apache.wicket.session.HttpSessionStore$SessionBindingListener@5124ccb5' 
20-Feb-2016 09:48:46.827 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:page:store:memory' with value 'org.apache.wicket.pageStore.memory.PageTable@46fba8b1' 
20-Feb-2016 09:48:46.828 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:session' with value 'com._806technologies.title1cratecore.components.T1CSession@340020df' 
20-Feb-2016 09:48:46.828 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:timestamp' with value 'Sat Feb 20 09:48:46 CST 2016' 
INFO  - 806HttpSessionDataStoreLog - calling isReplicated 
20-Feb-2016 09:48:46.828 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:wicket:persistentPageManagerData - wicket.Title1Crate' with value 'org.apache.wicket.page.PageStoreManager$SessionEntry@746e2b24' 
20-Feb-2016 09:48:46.828 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.BackupSessionTask.doBackupSession Trying to store session in memcached: E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.840 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.BackupSessionTask.call Finished for session id E24FAB17D7B8C7AD74186C659F219E9D, returning status SUCCESS 
20-Feb-2016 09:48:46.840 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.BackupSessionTask.releaseLock Releasing lock for session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.856 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.LockingStrategy.onAfterBackupSession Stored session validity info for session E24FAB17D7B8C7AD74186C659F219E9D 
20-Feb-2016 09:48:46.858 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.RequestTrackingHostValve.logDebugRequestSessionCookie Have request session cookie: domain=null, maxAge=-1, path=null, value=E24FAB17D7B8C7AD74186C659F219E9D, version=0, secure=false 
20-Feb-2016 09:48:46.859 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.RequestTrackingHostValve.invoke <<<<<< Request finished: POST /wicket/page ================== 
20-Feb-2016 09:48:47.117 FINE [http-apr-443-exec-6] de.javakaffee.web.msm.RequestTrackingHostValve.invoke >>>>>> Request starting: GET /wicket/bookmarkable/org.apache.wicket.markup.html.pages.InternalErrorPage (requestedSessionId E24FAB17D7B8C7AD74186C659F219E9D) ==================

Thanks,

Matt

> an email to memcached-session-manager+unsub...@googlegroups.com
> <mailto:memcached-session-manager+unsubscribe@googlegroups.com>.

[Martin Grotzke]

Can you share your test app somehow on github, optimally as a sample in https://github.com/magro/memcached-session-manager/tree/master/samples?

> an email to memcached-session-...@googlegroups.com
> <mailto:memcached-session-...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "memcached-session-manager" group.

To unsubscribe from this group and stop receiving emails from it, send an email to memcached-session-...@googlegroups.com.

[Matt Ashley]

Through some deep logging and debugging with the way Wicket stores pages I believe we have fixed the issue. The Wicket in memory cache size needed to be set to 0. It was set to 40 by default in the version of Wicket we were using. This was causing the 2nd node to use an older version of the page that did not have all the components. I believe this in memory page cache was not serialized to the session.

20-Feb-2016 09:48:46.828 FINE [http-apr-443-exec-7] de.javakaffee.web.msm.JavaSerializationTranscoder.writeAttributes   storing attribute 'wicket:wicket.Title1Crate:timestamp' with value 'Sat Feb 20 09:48:46 CST 2016' <br style="color:rgb(0,0,0);font-family:Verdana,Ge

[Martin Grotzke]

Great to hear that you solved it!

--

[Matt Ashley]

Thanks so much for your responses! I know that was a very old thread. I’m glad we upgraded to 1.9.1 too!

--

---
You received this message because you are subscribed to a topic in the Google Groups "memcached-session-manager" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/memcached-session-manager/zyLci-8FWBI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to memcached-session-...@googlegroups.com.