payara-micro-4.1.1.162 - [SEVERE and java.io.NotSerializableException]

[gilbertoca]

Hi,

I didn't find the mail list to discuss this issue, so sorry if it is not the right place for it.
First one is the SEVERE [1]:

[2016-07-01T09:55:06.488-0300] [Payara Micro 4.1] [SEVERE] [] [javax.enterprise.system.tools.deployment.dol] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1467377706488] [levelValue: 1000] DEP0004:Deployment failed due to the conflict occur for jndi-name: java:app/gace/MyDS for application: gace

The DataSource definition is here [2]. Even complaining about the deployment the app works.
The other one is about NotSerializableException exception:

[2016-07-01T09:55:55.360-0300] [Payara Micro 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=20 _ThreadName=http-listener(10)] [timeMillis: 1467377755360] [levelValue: 800] [[
  Cannot serialize session attribute WELD_S#WELD%ManagedBean%gace|gace|br.gov.to.bem.security.view.AuthorizationBean|null|false for session 68742868922bbed481304b115409
java.io.NotSerializableException: org.apache.shiro.web.subject.support.WebDelegatingSubject
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
    at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:2196)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
    at org.apache.catalina.session.StoreBase.writeSession(StoreBase.java:277)
    at org.glassfish.web.ha.session.management.HAStoreBase.getByteArray(HAStoreBase.java:231)
    at org.glassfish.web.ha.session.management.ReplicationStore.doValveSave(ReplicationStore.java:173)
    at org.glassfish.web.ha.session.management.ReplicationWebEventPersistentManager.doValveSave(ReplicationWebEventPersistentManager.java:150)
    at org.glassfish.web.ha.session.management.HASessionStoreValve.doPostInvoke(HASessionStoreValve.java:179)
    at org.glassfish.web.ha.session.management.HASessionStoreValve.postInvoke(HASessionStoreValve.java:140)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:749)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:526)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
    at java.lang.Thread.run(Thread.java:745)
]]

Every time the app checks the permission through the AuthorizationBean bean[3], this exception is thrown causing the log to keep growing.

I've test the app with Wildfly and TomEE, there is no problem with them.

Regards,

[1] https://gist.github.com/gilbertoca/a45b6b74b1e48293c620eb4629d8720b
[2] https://gist.github.com/gilbertoca/f2a386f52373e2826ff7b99926f9f4e7
[3] https://gist.github.com/gilbertoca/f89e03309ad9bf9f628e9f67a66912fe

[OndroMih]

Hi @gilbertoca, this is the best place so far to raise issues like this. Payara has plans to introduce a mailing list too, but it is not ready yet. However, even with a mailing list, github issues would be the best place to raise issues like this.

Thank you for letting us know, I will investigate from here. When I have questions, I will come back to you.

[lprimak]

@gilbertoca can you try adding <distributable/> from web.xml and see if it helps?
This maybe a workaround for you until this (probable) bug is fixed

[lprimak]

@gilbertoca I would also use SecurityUtils.getSubject() in all the calls instead of saving it to the session, thus bypassing this problem completely. I think this would also be more secure and less error-prone.
Payara is very sensitive with non-serializable objects in the session, probably deservedly so.

[gilbertoca]

Ok, We've followed you advice - use SecurityUtils.getSubject(). No more NotSerializableException exception. Hope you find the Deployment conflict problem. If you need more info, just ask!
Regards!

[lprimak]

@gilbertoca I didn't even notice the "original" issue, can you open a separate ticket and close this one?

[lprimak]

Also, I do not think java:app/gace/MyDS is a JavaEE-compliant data source name.
You should name it just MyDS or better yet jdbc/MyDS
java:app/gace/MyDS is an JNDI lookup name, and when you name it as described above, you can look up the data source in JNDI using java:app/gace/MyDS (or better yet java:app/gace/jdbc/MyDS)

[smillidge]

Payara Micro is clustered out of the box and all deployed applications are treated as "clusterable" in that they are deployed with the availability service enabled. Have you tried running Payara Micro with the --noCluster option?

[gilbertoca]

Done #907 .

I do not think java:app/gace/MyDS is a JavaEE-compliant data source name.

I'm following the topic:

EE.5.2.2 Application Component Environment Namespaces

from Java EE 7 Platform Spec.

[lprimak]

@gilbertoca Let me clarify.
java:app/gace/MyDS is a perfectly valid JNDI lookup name, but is an invalid data source name.

Just name your DS jdbc/MyDS, and you can look it up via java:app/jdbc/MyDS

I think you are confusing JNDI lookup names with resource names as named in the Payara console

[gilbertoca]

Ah, understood! Thank you @lprimak
Can you help me find some examples of resources definition and reference. A resource may be defined (take from the spec):

• in the java:comp namespace, for use by a single component;
• in the java:module namespace, for use by all components in a module;
• in the java:app namespace, for use by all components in an application;
• in the java:global namespace, for use by all applications.

Searching on internet(about this topic) make it even more complicated.
PS.: @smillidge We will test with --noCluster option

[gilbertoca]

@smillidge I've tested the app with --noCluster option. The NotSerializableException exception does not occur.
We will, as I've said, follow the @lprimak advice using SecurityUtils.getSubject() in all the calls instead of saving it to the session.

[smillidge]

OK thanks. Payara Micro is clustered by default so will try to serialize anything you put into the web session unless you use the --noCluster option.

[OndroMih]

It would be convenient if the info message was logged only if there are multiple instances in the cluster (or lower the message severity in that case).

However, I consider this issue as solved, as the other issue is being handled in #907.