Re: Session Replication

  • From: Anthony Levesque <alev50@...>
  • To: issues@...
  • Subject: Re: Session Replication
  • Date: Thu, 18 Jul 2013 16:13:59 +0200

Joe,

Here is the scenario I played :

1 - Start cluster
2 - Deploy web app
3 - Connect through load balancer -> instance 2
4 - Log on
5 - Stop instance 2
6 - Refresh browser -> instance 1
7 - Session lost + StreamCorruptedException
8 - Stop cluster

Logs are attached.

Thanks for help.

Regards,

Anthony

2013/7/17 Fialli Joe <joe.fialli@...>

>  Anthony,
>
> Forgot to include an easy way to collect all log files, see inline below.
>
> -Joe
>
>
> On 7/17/13 5:00 PM, Fialli Joe wrote:
>
> Anthony,
>
> Please turn on logging for enterprise.system.container.web to FINEST.
> That will provide classname of session being serialized and deserialized.
> Hopefully, this will give you a starting point to review the classes being
> serialized.
>
> When you send along log files, try to send all of them.
>
> Forgot to mention to use "asadmin collect-log-files --target
> <your-cluster-name>"  ....
>
> Documentation for this asadmin command and all its options are here:
> http://docs.oracle.com/cd/E18930_01/html/821-2433/collect-log-files-1.html
>
>
> Start test scenario with clean server logs and provide all of them.
> You edited out the initialization of the replication stores (which use the
> class names of the sessions),  that would have provided
> the names of the top level session classes.  Try to limit the failure
> scenario to one stack trace in server log, to keep server log volume down.
>
> There is a possibility it is a class loading issue.  I did notice that a
> delegated class loader for the container was getting used sometimes
> and then when replication was deserializing, it just was using default
> classloader, not container class loader.  Not sure why that is
> happening and additional web container logging may allow us to diagnose
> that.
>
> -Joe Fialli, Oracle Corporation
>
> On 7/17/13 12:38 PM, Anthony Levesque wrote:
>
> Hello,
>
> Thank you very much for your help.
>
> However, I have been struggling on the issue all the day without much
> progress.
>
> I would at least need to know which class is being deserialized and cause
> the exception since my web app is rather big.
>
> I have tried to play with the debugger and the transient fields on some
> suspected controllers without any success.
>
> There is no exception in the logs of the other instance.
>
> I send you attached to this mail my last server log in case of you can see
> more things than me.
>
> Is there a way to see the content of a serialized session ? Where is it
> stored ?
>
> For your information, it happens on the first form submit (login page in
> JSF) and then the app is broken.
>
> My framework is RichFaces 3.3-JSF2.
>
> Regards,
>
> Anthony
>
> 2013/7/16 Fialli Joe <joe.fialli@...>
>
>> Alev50,
>>
>> Please see comments inline below.
>>
>> -Joe Fialli, Oracle Corporation
>>
>>
>> On 7/16/13 1:41 PM, alev50@... wrote:
>>
>>> Hello,
>>>
>>> I am a Java EE developer working on a web app for GlassFish 3.1.2 Final
>>> (JSF 2 + Spring 3 + JPA). I am facing a blocking clustering issue and
>>> would like to get some help or hint to go further.
>>>
>>> I have created a simple cluster with 2 instances. My web app is
>>> deployed on the cluster with “Availibity” enabled and “distributable”
>>> property in web.xml. My controllers are serializable.
>>>
>>  The following exception points to a serialize/deserialize issue with
>> your object.
>>
>>
>> [#|2013-07-16T19:13:36.476+0200|WARNING|glassfish3.1.2|javax.enterprise
>> .system.container.web.org.glassfish.web.ha.session.management|_ThreadID
>> =21;_ThreadName=Thread-2;|Exception occurred in getSession
>> java.io.StreamCorruptedException: invalid type code: 00
>>
>>
>>  You have sent along the exception produced when reading the serialized
>> form of the session.  Where there any exception when the serialized form
>> was created ?  (look in server log of other cluster member in a 2
>> instance cluster).
>> Any failures when creating the serialized form could provide further
>> assistance
>> in understanding when the stream became corrupted.
>>
>> From the stack trace, there is no evidence that customized
>> readObject/writeObject
>> (or readExternal/writeExternal) caused serialized stream corruption.
>> But it is an obvious question to ask in this case.  If there is any
>> customization
>> of your controller object or any classes of the instances reachable from
>> the controller,
>> I recommend a junit serialize/deserialize test of the controller with
>> sample
>> data that matches the failure case (if that is possible).  A confirmation
>> that serialize/deserialize works for your
>> controller classes is the first step for researching this issue.
>>
>> Sometimes there are fields in a class that should be marked as transient
>> so their data is not serialized.
>> (since the value would not make sense outside of the original JVM.  For
>> example, a pointer to a GUI
>> component should not be serialized outside its original JVM.
>>
>> Hope these suggestions help isolate the issue.
>>
>>
>>  Here is the stack I get repeatedly :
>>>
>>> [#|2013-07-16T19:13:36.476+0200|FINER|glassfish3.1.2|javax.enterprise.s
>>> ystem.container.web.org.glassfish.web.loader|_ThreadID=21;_ThreadName=T
>>> hread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName
>>> =loadClass;|loadClass(com.transat.ga2010.service.TitreServiceImpl)|#]
>>>
>>> [#|2013-07-16T19:13:36.476+0200|FINER|glassfish3.1.2|javax.enterprise.s
>>> ystem.container.web.org.glassfish.web.loader|_ThreadID=21;_ThreadName=T
>>> hread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName
>>> =loadClass;|  Returning class from cache|#]
>>>
>>> [#|2013-07-16T19:13:36.476+0200|WARNING|glassfish3.1.2|javax.enterprise
>>> .system.container.web.org.glassfish.web.ha.session.management|_ThreadID
>>> =21;_ThreadName=Thread-2;|Exception occurred in getSession
>>> java.io.StreamCorruptedException: invalid type code: 00
>>>         at
>>> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1354)
>>>         at
>>> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1969
>>> )
>>>         at
>>> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
>>>         at
>>> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:177
>>> 5)
>>>         at
>>> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
>>>         at
>>> java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>>>         at
>>> org.apache.catalina.session.StandardSession.deserialize(StandardSession
>>> .java:1144)
>>>         at
>>> org.apache.catalina.session.StoreBase.readSession(StoreBase.java:288)
>>>         at
>>> org.glassfish.web.ha.session.management.ReplicationStore.getSession(Rep
>>> licationStore.java:533)
>>>         at
>>> org.glassfish.web.ha.session.management.ReplicationStore.getSession(Rep
>>> licationStore.java:485)
>>>         at
>>> org.glassfish.web.ha.session.management.ReplicationStore.loadFromBackin
>>> gStore(ReplicationStore.java:404)
>>>         at
>>> org.glassfish.web.ha.session.management.ReplicationStore.load(Replicati
>>> onStore.java:387)
>>>         at
>>> org.apache.catalina.session.PersistentManagerBase.doSwapIn(PersistentMa
>>> nagerBase.java:1052)
>>>         at
>>> org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentMana
>>> gerBase.java:1010)
>>>         at
>>> org.glassfish.web.ha.session.management.ReplicationManagerBase.findSess
>>> ion(ReplicationManagerBase.java:156)
>>>         at
>>> org.apache.catalina.connector.Request.isRequestedSessionIdValid(Request
>>> .java:2686)
>>>         at
>>> org.apache.catalina.connector.Request.parseSessionCookiesId(Request.jav
>>> a:3711)
>>>         at
>>> org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdap
>>> ter.java:625)
>>>         at
>>> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.jav
>>> a:271)
>>>         at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
>>> 231)
>>>         at
>>> com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.cal
>>> l(ContainerMapper.java:317)
>>>         at
>>> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMa
>>> pper.java:195)
>>>         at
>>> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860
>>> )
>>>         at
>>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
>>>         at
>>> com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
>>>         at
>>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilte
>>> r.java:229)
>>>         at
>>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProto
>>> colChain.java:137)
>>>         at
>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
>>> 104)
>>>         at
>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
>>> 90)
>>>         at
>>> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:7
>>> 9)
>>>         at
>>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTas
>>> k.java:54)
>>>         at
>>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.ja
>>> va:59)
>>>         at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
>>>         at
>>> com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPoo
>>> l.java:532)
>>>         at
>>> com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.j
>>> ava:513)
>>>         at java.lang.Thread.run(Thread.java:662)
>>> |#]
>>>
>>> [#|2013-07-16T19:13:36.476+0200|FINE|glassfish3.1.2|javax.enterprise.sy
>>> stem.container.web.org.glassfish.web.ha.session.management|_ThreadID=21
>>> ;_ThreadName=Thread-2;ClassName=org.glassfish.web.ha.session.management
>>> .ReplicationManagerBase;MethodName=findSession;|in findSession:
>>> version=1|#]
>>>
>>> [#|2013-07-16T19:13:36.476+0200|FINE|glassfish3.1.2|javax.enterprise.sy
>>> stem.container.web.org.glassfish.web.ha.session.management|_ThreadID=21
>>> ;_ThreadName=Thread-2;ClassName=org.glassfish.web.ha.session.management
>>> .ReplicationManagerBase;MethodName=findSession;|Required version 1|#]
>>>
>>> I imagine you have a lot of work with the new version of GlassFish, but
>>> I wish you could have a look at it. Maybe the bug problem still exists
>>> in the new version.
>>>
>>
>>
>
>
>

Attachment: logs_180713_1612.zip
Description: Zip archive



Session Replication

alev50 07/16/2013

Re: Session Replication

Fialli Joe 07/16/2013

Re: Session Replication

Anthony Levesque 07/17/2013

Re: Session Replication

Fialli Joe 07/17/2013

Re: Session Replication

Fialli Joe 07/17/2013

Re: Session Replication

Anthony Levesque 07/18/2013

Re: Session Replication

Fialli Joe 07/18/2013

Re: Session Replication

Anthony Levesque 07/19/2013
Terms of Use; Privacy Policy; Copyright ©2013-2015 (revision 20150226.965aeb8)
 
 
Close
loading
Please Confirm
Close