[GLASSFISH-20296] Make endpoint component naming context available during call to endpointDeactivation Created: 12/Apr/13  Updated: 30/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: marina vatkina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: connectors

 Description   

To handle CONNECTOR_SPEC-4, the Connectors 1.7 spec says the following in Section Para #3 of Section 13.4.4:
– snip –
The application server must make the application component environment
namespace of the endpoint (that is being activated), available to the resource adapter
during the call to the endpointActivation and endpointDeactivation
methods. The resource adapter may use this JNDI context to access other resources.
– snip –

Though GLASSFISH-19452 provides the naming context during endpointActivation, GF doesn't provide the endpoint naming context to the resource adapter during the call to endpointDeactivation. Please fix this.



 Comments   
Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Hi Guojun
Can you please take a look into this issue ASAP?

Need your eval for this issue for inclusion into or exclusion from 4.0.

Comment by guojun.shan [ 22/Apr/13 ]

Amy Yang said GLASSFISH-19452 should has covered this issue.
Could you please verify it?
thanks.

Comment by Sivakumar Thyagarajan [ 23/Apr/13 ]

We still observe this issue. Please find our observations while running a test RA that performs a lookup of a resource defined in a MDB's component context in endpointDeactivation.

— snip —
[2013-04-23T15:27:33.604+0530] [glassfish 4.0] [INFO] [] [] [tid:
_ThreadID=133 _ThreadName=Thread-7] [timeMillis: 1366711053604]
[levelValue: 800] [[
[SimpleResourceAdapterImpl] ==> endpointDeactivation called...]]

[2013-04-23T15:27:33.605+0530] [glassfish 4.0] [SEVERE] [] [] [tid:
_ThreadID=133 _ThreadName=Thread-8] [timeMillis: 1366711053605]
[levelValue: 1000] [[
javax.naming.NamingException: Lookup failed for 'java:comp/env/MyDB'
in
SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NamingException: Invocation exception: Got null ComponentInvocation ]
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at
connector.SimpleResourceAdapterImpl.endpointDeactivation(SimpleResourceAdapterImpl.java:91)
at
com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:364)
at org.glassfish.ejb.mdb.MessageBeanContainer
$ASyncClientShutdownTask.run(MessageBeanContainer.java:1020)
at java.util.concurrent.Executors
$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask
$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.naming.NamingException: Invocation exception: Got null
ComponentInvocation
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.getComponentId(GlassfishNamingManagerImpl.java:842)
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:714)
at
com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:161)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 12 more]]

[2013-04-23T15:27:33.605+0530] [glassfish 4.0] [SEVERE] [] [] [tid:
_ThreadID=133 _ThreadName=Thread-8] [timeMillis: 1366711053605]
[levelValue: 1000] [[
java.lang.Exception
at org.glassfish.ejb.mdb.MessageBeanContainer
$ASyncClientShutdownTask.setDone(MessageBeanContainer.java:1051)
at org.glassfish.ejb.mdb.MessageBeanContainer
$ASyncClientShutdownTask.run(MessageBeanContainer.java:1030)
at java.util.concurrent.Executors
$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask
$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)]]

[2013-04-23T15:27:33.610+0530] [glassfish 4.0] [INFO] [] [] [tid:
_ThreadID=46 _ThreadName=Thread-7] [timeMillis: 1366711053610]
[levelValue: 800] [[
bean removed]]
— snip —

Reproducing this should be easy:

  • Take an existing test that uses resource adapters to deliver to MDBs
  • In the RA's endpointDeactivation, lookup a resource defined in the MDB's component context.

It appears that the ComponentInvocation is null because the endpointDeactivation is called in an asynchronous task execution through the threadpoolexecutor, and the invocation context is maintained in an inheritablethreadlocal that is not carried forward to the async thread.

Comment by guojun.shan [ 24/Apr/13 ]

re-assign to Amy yang.

Comment by amy.yang [ 28/Apr/13 ]

i've sent the patch to Marina and will be on vacation for 3 days.

Comment by marina vatkina [ 29/Apr/13 ]

Fixed with
Sending ejb-full-container/src/main/java/org/glassfish/ejb/mdb/MessageBeanContainer.java
Transmitting file data .
Committed revision 61699.

Note1: the test 'unsetup' target needs the order of undeploy and unsetJdbc reversed so that the XAPointbase is still available during undeploy.

Note2: endpointDeactivation during shutdown is still broken - there is no EJB container in the picture:
[2013-04-29T01:06:06.247-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=129 _ThreadName=Thread-4] [timeMillis: 1367222766247] [levelValue: 1000] [[
javax.naming.NamingException: Lookup failed for 'java:comp/env/MyDB' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NamingException: Invocation exception: Got null ComponentInvocation ]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at connector.SimpleResourceAdapterImpl.endpointDeactivation(SimpleResourceAdapterImpl.java:100)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.deactivateEndPoints(ActiveInboundResourceAdapterImpl.java:113)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.destroy(ActiveInboundResourceAdapterImpl.java:102)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl$RAShutdownTask.run(ResourceAdapterAdminServiceImpl.java:624)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.naming.NamingException: Invocation exception: Got null ComponentInvocation

Comment by Sivakumar Thyagarajan [ 29/Apr/13 ]

Thanks Marina for the fix. I was able to verify the fix and this works. I have fixed the test through
$ svn commit .
Sending connector1.6/build.xml
Sending connector1.6/ra/src/connector/SimpleResourceAdapterImpl.java
Transmitting file data ..
Committed revision 61712.

I will follow up with you about the shutdown Exception. I am not able to reproduce that. Are you able to reproduce that using the latest build? There was a undeployment ordering issue that was fixed through GLASSFISH-20403 that may have caused this issue, but that has been fixed. When I try to reproduce this using the steps below, I don't see the issue:

  • run "ant init-common build setup runtest" under appserv-tests/devtests/connector/v3/connector1.6
  • stop-domain
  • check server.log. I see the correct order (MDB being deactivated first, and then the RA.stop)

– server.log snippet –
[2013-04-29T20:39:44.057+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=124 _ThreadName=Thread-3] [timeMillis: 1367248184057] [levelValue: 800] [[
bean removed]]

[2013-04-29T20:39:44.062+0530] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.inbound] [tid: _ThreadID=125 _ThreadName=__ejb-thread-pool1] [timeMillis: 1367248184062] [levelValue: 800] [[
No resource-adapter-mid specified, defaulting to the resource-adapter [ generic-ra ] that supports the requested message-listener [ connector.MyMessageListener ]]]

[2013-04-29T20:39:44.063+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=125 _ThreadName=Thread-3] [timeMillis: 1367248184063] [levelValue: 800] [[
[SimpleResourceAdapterImpl] ==> endpointDeactivation called...]]

[2013-04-29T20:39:44.065+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=125 _ThreadName=Thread-3] [timeMillis: 1367248184065] [levelValue: 800] [[
lookedup in RA endpointDeactivation:com.sun.gjc.spi.jdbc40.DataSource40@1eecd5d]]

[2013-04-29T20:39:44.089+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=126 _ThreadName=Thread-3] [timeMillis: 1367248184089] [levelValue: 800] [[
[SimpleResourceAdapterImpl] ==> 999. Simple RA stop...]]

[2013-04-29T20:39:44.089+0530] [glassfish 4.0] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=124 _ThreadName=Thread-34] [timeMillis: 1367248184089] [levelValue: 800] [[
RAR7094: generic-ra shutdown successful.]]

– server.log snippet –

Comment by Sivakumar Thyagarajan [ 30/Apr/13 ]

Heard from Marina that this may be due to the reordering bug. The shutdown issue is not valid anymore.

Comment by marina vatkina [ 30/Apr/13 ]

Siva, the 'Got null ComponentInvocation' exception on shutdown is there if undeploy fails - try reverting the order of unsetup operations in the test. Something gets into an inconsistent state in that case.

The regular shutdown is fine, and I do see the log message 'lookedup in RA endpointDeactivation:com.sun.gjc.spi.jdbc40.DataSource40@1eceee8d'

Generated at Thu Jul 02 04:46:25 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.