MSM with Tomcat 7.0.27

[Thomas Andraschko‏]

Hi Martin,

i get following exception when starting MSM with 7.0.27:

SCHWERWIEGEND: Begin event threw error
java.lang.VerifyError: class de.javakaffee.web.msm.MemcachedBackupSessionManager overrides final method start.()V
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
    at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144)
    at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1276)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
    at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:179)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1343)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2755)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
    at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1537)
    at org.apache.catalina.startup.Catalina.load(Catalina.java:601)
    at org.apache.catalina.startup.Catalina.load(Catalina.java:649)
    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.load(Bootstrap.java:281)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:449)

Can this be fixed in MSM?

Regards,
Thomas

[Martin Grotzke‏]

Hi Thomas,

I suspect you have some wrong jars in tomcat/lib (tc6 jar). Can you
check this / list the jars of this directory?

Cheers,
Martin

--
Brakhane, Grotzke und Langbehn Informatiker und Physiker PartG
Breitenfelder Str. 13c, 20251 Hamburg
Amtsgericht Hamburg, PR 795

[Martin Grotzke‏]

Btw, my business work load is currently that high that I won't have time
to work on msm this week. For now you can use the 1.6.2-SNAPSHOT
(attached) which should work fine as long as you're not using form based
authentication with stateless sessions.

To get form based auth (and static content that does not trigger session
backups) fully working with stateless sessions there's some more work to
do left with tomcat 7.0.22+, so probably this won't make it into 1.6.2.

For 1.6.2 I need to finish some cleanup and writing unit+integration tests.

Cheers,
Martin


On 05/14/2012 01:29 PM, Thomas Andraschko wrote:

[Thomas Andraschko‏]

Hi Martin,

damn, you are right!

Oh, cool! I can try it but i also moved the failover logic to an Filter in OWB and it works now :)

Thanks!
THomas

2012/5/14 Martin Grotzke <martin....@googlemail.com>

[Martin Grotzke‏]

On 05/14/2012 01:48 PM, Thomas Andraschko wrote:
> Hi Martin,
>

> damn, you are right!
>
> Oh, cool! I can try it but i also moved the failover logic to an Filter
> in OWB and it works now :)

If you want you can post details what/how you implemented it, so that I
can check that it does not interfere with msm functionality (then also
post your msm config as I have to check against this). Though - when you
tested it it should be fine :-)

Cheers,
Martin

>
> Thanks!
> THomas
>
> 2012/5/14 Martin Grotzke <martin....@googlemail.com

> <mailto:martin....@googlemail.com>>

[Thomas Andraschko‏]

Hi Martin,

also, it works really fine :)
I just implemented a ServletFilter which calls the chain first and then prepares the failover in/for the session.
I think this should work in all cases because it will be done in the request and before requestDestroyed.

Or do i miss something?

Thanks!
Thomas

2012/5/14 Martin Grotzke <martin....@googlemail.com>

[Martin Grotzke‏]

On 05/14/2012 10:52 PM, Thomas Andraschko wrote:
> Hi Martin,
>

> also, it works really fine :)

Great :-)

> I just implemented a ServletFilter which calls the chain first and then
> prepares the failover in/for the session.
> I think this should work in all cases because it will be done in the
> request and before requestDestroyed.

If you're using sticky sessions this should be fairly straightforward
and s.th. like what I hacked these days in the servlet-filter branch
(https://github.com/magro/memcached-session-manager/commit/eae654a7).

>
> Or do i miss something?

I don't think so. Only handling non-sticky sessions requires a little
bit more effort and stuff like container managed form based auth would
not be possible with a servlet filter.

Cheers,
Martin

[Thomas Andraschko‏]

Ahh, cool stuff :)
So the servlet-filter branch would also work with other containers?

> I don't think so. Only handling non-sticky sessions requires a little
> bit more effort and stuff like container managed form based auth would
> not be possible with a servlet filter.

What do i need for non-sticky sessions?

2012/5/16 Martin Grotzke <martin....@googlemail.com>

[Martin Grotzke‏]

On 05/21/2012 04:17 PM, Thomas Andraschko wrote:
> Ahh, cool stuff :)
> So the servlet-filter branch would also work with other containers?

Yes.

>
>> I don't think so. Only handling non-sticky sessions requires a little
>> bit more effort and stuff like container managed form based auth would
>> not be possible with a servlet filter.
>
> What do i need for non-sticky sessions?

Stuff that's not yet implemented for non-sticky sessions:
1) Saving a backup of the session in a different memcached to support
memcached failover
1) memcached failover
1.1.) saving a backup of the session in a different memcached
1.2.) handle memcached failover: load session from 2ndary/backup
memcached when the primary is not available, store session in the next
memcached for backup, change session id
2) secure sessionId generation (currently in
MemcachedSessionManagerRequestNonstickySession)
3) Implementation of
MemcachedSessionManagerRequestNonstickySession.isRequestedSessionIdValid

General functionality not yet implemented:
- Configuration of the MemcachedSessionManagerFilter (sticky/non-sticky,
memcached-configuration, serialization related stuff)
- Tests

Probably this list is not complete, it's only what comes to my mind
directly.

Cheers,
Martin



>
> 2012/5/16 Martin Grotzke <martin....@googlemail.com
> <mailto:martin....@googlemail.com>>

>
> On 05/14/2012 10:52 PM, Thomas Andraschko wrote:
> > Hi Martin,
> >
> > also, it works really fine :)
> Great :-)
>
> > I just implemented a ServletFilter which calls the chain first and
> then
> > prepares the failover in/for the session.
> > I think this should work in all cases because it will be done in the
> > request and before requestDestroyed.
> If you're using sticky sessions this should be fairly straightforward

> and s.th <http://s.th>. like what I hacked these days in the

> servlet-filter branch
> (https://github.com/magro/memcached-session-manager/commit/eae654a7).
>
> >
> > Or do i miss something?
> I don't think so. Only handling non-sticky sessions requires a little
> bit more effort and stuff like container managed form based auth would
> not be possible with a servlet filter.
>
> Cheers,
> Martin
>
>