[GLASSFISH-15811] Parameter associate-with-thread fails when activated for more than one pool Created: 03/Feb/11  Updated: 21/Dec/11

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: marsangr Assignee: skgaju
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

I can reproduce GLASSFISH-15577 in v2.1.1
Could the same fix be applied to its trunk?



 Comments   
Comment by Jagadish [ 03/Feb/11 ]

yes, this is applicable for 2.x also.
Transferring to sustenance team.
Gajanan, please transfer this to appropriate team/engineer.

Comment by scatari [ 11/Jun/11 ]

Not a required fix to support release drivers of 3.1.1.

Comment by Joe Di Pol [ 21/Dec/11 ]

This appears to have been fixed in 3.x (GLASSFISH-15586). Excluding from 3.1.x releases.





[GLASSFISH-17266] custom resource factory cannot access webmodule during lifecycle events Created: 01/Sep/11  Updated: 21/Oct/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mangrove Assignee: skgaju
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk6,winxp


Attachments: Zip Archive NetBeansProjects.zip    
Tags: 3_1_x-exclude

 Description   

When one has a custom factory class deployed under domain/lib and a resource is created which uses this factory to create an injectable class located in a webapp, then the following (or similar) exception is thrown during appserver startup:

javax.naming.CommunicationException: serial context communication ex [Root exception is java.lang.ClassNotFoundException: a.Config]
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.naming.NamingManagerImpl.bindObjects(NamingManagerImpl.java:391)
at com.sun.enterprise.web.WebModuleContextConfig.configureResource(WebModuleContextConfig.java:227)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:167)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:159)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:6476)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4977)
at com.sun.enterprise.web.WebModule.start(WebModule.java:353)
at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
at com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: a.Config
at com.sun.enterprise.util.ConnectorClassLoader.loadClass(ConnectorClassLoader.java:222)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at a.ConfigFactory.getObjectInstance(ConfigFactory.java:21)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:414)
... 17 more

The cause is that when the LifecycleStarter task is created in VirtualServer then the current thread's contextClassLoader is the ConnectorClassLoader and so that's the one which gets inherited by the RunnableBase.

I think if an injectable resource class is allowed to be local to a webapp then the appropriate classLoader should be utilized when doing any kind of work with the factories.

Proposed solution: VirtualServer might set the current thread's contextClassLoader to the webapp's loader every time it creates a runnable task for a WebModule and then set it back to the old value.

Couldn't reproduce it in v3.1. Attached are the factory jar under domain/lib and the webapp and here's the resource entry in domain.xml:

<custom-resource enabled="true" factory-class="a.ConfigFactory" jndi-name="testconfig" object-type="user" res-type="a.Config"/>



 Comments   
Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

This bug is not applicable for 3.1 from what I understand from submitter's note.

Comment by Jagadish [ 21/Oct/11 ]

https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/v3/built-in-custom-resources
Above test-case that has a custom resource's factory which loads the JavaBean class copied in domain/lib directory, works fine in GlassFish 3.0 and above.

Marking as not applicable for 3.x and above.

Comment by Jagadish [ 21/Oct/11 ]

Transferring to Gajanan for evaluation in GlassFish 2.x.
Gajanan: Please transfer to appropriate team member.





[GLASSFISH-19564] the resource is available on the target when "delete-resource-ref" is executed Created: 22/Jan/13  Updated: 28/Jan/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Wu Jie Assignee: skgaju
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GLASSFISH-18800 Mail session resource remains usable ... Closed

 Description   

The resource which the resource-ref is deleted from target(DAS, standalone instance or cluster) is still available(can be lookup by the naming context on the target).

for example.
1.the jdbc resource "jdbc/__TimerPool" is available on DAS(server).
2.asadmin delete-resource-ref jdbc/__TimerPool
3.after step2. the "jdbc/__TimerPool" is still available on DAS(server).

the other resources(connector-resource, admin-object-resource, mail-resource, custom-resource, jndi-resource) have the same issue.

it seems that the ResourceNamingService#unpublishObject() is not invoked when the resource-ref was deleted.



 Comments   
Comment by Wu Jie [ 22/Jan/13 ]

the resource will be unavailabe after the target's restart.

Comment by Wu Jie [ 22/Jan/13 ]

I looked into the src, and found that
1.GlassfishNamingManager#publishObject() is invoked when resource-ref is created.
e.g. the stack of jdbc resource's creation.

Daemon Thread [pool-43-thread-1] (Suspended (entry into method publishObject in GlassfishNamingManagerImpl))
GlassfishNamingManagerImpl.publishObject(Name, Object, boolean) line: 203
GlassfishNamingManagerImpl.publishObject(String, Object, boolean) line: 189
ResourceNamingService.publishObject(GenericResourceInfo, String, Object, boolean) line: 153
ResourceNamingService.publishObject(ResourceInfo, Object, boolean) line: 159
ResourcesBinder.bindResource(ResourceInfo, Resource) line: 101
ResourcesBinder.deployResource(ResourceInfo, Resource) line: 84
ResourceManager$PropertyChangeHandler.handleAddEvent(T) line: 450
ResourceManager$PropertyChangeHandler.changed(TYPE, Class<T>, T) line: 321
ConfigSupport.sortAndDispatch(PropertyChangeEvent[], Changed, Logger) line: 289
ResourceManager.changed(PropertyChangeEvent[]) line: 275
Transactions$ConfigListenerJob.process(ConfigListener) line: 401
Transactions$ConfigListenerJob.process(Object) line: 391
Transactions$ConfigListenerNotifier$1$1.call() line: 281
Transactions$ConfigListenerNotifier$1$1.call() line: 279
FutureTask$Sync.innerRun() line: 334
FutureTask<V>.run() line: 166
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1110
ThreadPoolExecutor$Worker.run() line: 603
Thread.run() line: 722

2.GlassfishNamingManager#unpublishObject is not invoked when resource-ref is invoked.
e.g. the stack of jdbc resource's deletion.

Daemon Thread [pool-123-thread-1] (Suspended (entry into method isEnabled in ResourcesUtil))
owns: JdbcResourceDeployer (id=375)
ResourcesUtil.isEnabled(BindableResource, ResourceInfo) line: 713(※1)
JdbcResourceDeployer.deleteResource(JdbcResource, ResourceInfo) line: 151
JdbcResourceDeployer.undeployResource(Object) line: 146
ResourceManager$PropertyChangeHandler.handleRemoveEvent(T) line: 478
ResourceManager$PropertyChangeHandler.changed(TYPE, Class<T>, T) line: 335
ConfigSupport.sortAndDispatch(PropertyChangeEvent[], Changed, Logger) line: 318
ResourceManager.changed(PropertyChangeEvent[]) line: 275
Transactions$ConfigListenerJob.process(ConfigListener) line: 401
Transactions$ConfigListenerJob.process(Object) line: 391
Transactions$ConfigListenerNotifier$1$1.call() line: 281
Transactions$ConfigListenerNotifier$1$1.call() line: 279
FutureTask$Sync.innerRun() line: 334
FutureTask<V>.run() line: 166
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1110
ThreadPoolExecutor$Worker.run() line: 603
Thread.run() line: 722

ResourcesUtil.isEnabled is always false by debug. because of that, GlassfishNamingManager#unpublishObject will be not invoked when resource-ref is deleted.

Comment by Wu Jie [ 22/Jan/13 ]

the reason that why ResourcesUtil.isEnabled always returns false when resource-ref is deleted is related to the flow of delete-resource-ref.
the flow of delete-resource-ref as following.
1.delete resource-ref from specified target.
2.unpublish the resource from the naming context of the specified target.
2-1. is the resource on the specified target enable?
2-2. if step 2-1 is "YES", execute GlassfishNamingManager#unpublishObject().
2-3. if step 2-1 is "NO", return without executing GlassfishNamingManager#unpublishObject().

it may be more clearly by looking the stack of delete-resource-ref.
e.g. the stack of jdbc resource's deletion.

step1. delete resource-ref from specified target.
Daemon Thread [admin-thread-pool-4848(3)] (Suspended (breakpoint at line 387 in Server$Duck))
Server$Duck.deleteResourceRef(Server, String) line: 387 (※2)
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
Method.invoke(Object, Object...) line: 601
GlassFishConfigBean(Dom).invokeDuckMethod(Method, Object, Object[]) line: 959
GlassFishConfigBean(Dom).invoke(Object, Method, Object[]) line: 912
TranslatedConfigView.invoke(Object, Method, Object[]) line: 119
$Proxy14.deleteResourceRef(String) line: not available
DeleteResourceRef.execute(AdminCommandContext) line: 108
CommandRunnerImpl$1.execute(AdminCommandContext) line: 348
CommandRunnerImpl.doCommand(CommandModel, AdminCommand, AdminCommandContext) line: 363
CommandRunnerImpl.doCommand(CommandRunnerImpl$ExecutionContext, AdminCommand) line: 1066
CommandRunnerImpl.access$1200(CommandRunnerImpl, CommandRunnerImpl$ExecutionContext, AdminCommand) line: 95
CommandRunnerImpl$ExecutionContext.execute(AdminCommand) line: 1291
CommandRunnerImpl$ExecutionContext.execute() line: 1259
PublicAdminAdapter(AdminAdapter).doCommand(String, GrizzlyRequest, ActionReport, Payload$Outbound) line: 461
PublicAdminAdapter(AdminAdapter).service(GrizzlyRequest, GrizzlyResponse) line: 212
PublicAdminAdapter(GrizzlyAdapter).service(Request, Response) line: 179
HK2Dispatcher.dispath(Adapter, ClassLoader, Request, Response) line: 117
ContainerMapper$Hk2DispatcherCallable.call() line: 354
ContainerMapper.service(Request, Response) line: 195
ProcessorTask.invokeAdapter() line: 860
ProcessorTask.doProcess() line: 757
ProcessorTask.process(InputStream, OutputStream) line: 1056
DefaultProtocolFilter.execute(Context) line: 229
HttpProtocolChain(DefaultProtocolChain).executeProtocolFilter(Context, int) line: 137
HttpProtocolChain(DefaultProtocolChain).execute(Context, int) line: 104
HttpProtocolChain(DefaultProtocolChain).execute(Context) line: 90
HttpProtocolChain.execute(Context) line: 79
ProtocolChainContextTask.doCall() line: 54
ProtocolChainContextTask(SelectionKeyContextTask).call() line: 59
ProtocolChainContextTask(ContextTask).run() line: 71
SyncThreadPool$SyncThreadWorker(AbstractThreadPool$Worker).doWork() line: 532
SyncThreadPool$SyncThreadWorker(AbstractThreadPool$Worker).run() line: 513
HttpWorkerThread(Thread).run() line: 722

step2. unpublish the resource from the naming context of the specified target.
Daemon Thread [pool-26-thread-1] (Suspended (breakpoint at line 372 in Server$Duck))
owns: JdbcResourceDeployer (id=195)
Server$Duck.getResourceRef(Server, String) line: 372(※3)
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
Method.invoke(Object, Object...) line: 601
GlassFishConfigBean(Dom).invokeDuckMethod(Method, Object, Object[]) line: 959
GlassFishConfigBean(Dom).invoke(Object, Method, Object[]) line: 912
TranslatedConfigView.invoke(Object, Method, Object[]) line: 119
$Proxy14.getResourceRef(String) line: not available
ResourcesUtil.isResourceReferenceEnabled(ResourceInfo) line: 892
ResourcesUtil.isEnabled(BindableResource, ResourceInfo) line: 725 (※4)
JdbcResourceDeployer.deleteResource(JdbcResource, ResourceInfo) line: 151
JdbcResourceDeployer.undeployResource(Object) line: 146
ResourceManager$PropertyChangeHandler.handleRemoveEvent(T) line: 478
ResourceManager$PropertyChangeHandler.changed(TYPE, Class<T>, T) line: 335
ConfigSupport.sortAndDispatch(PropertyChangeEvent[], Changed, Logger) line: 318
ResourceManager.changed(PropertyChangeEvent[]) line: 275
Transactions$ConfigListenerJob.process(ConfigListener) line: 401
Transactions$ConfigListenerJob.process(Object) line: 391
Transactions$ConfigListenerNotifier$1$1.call() line: 281
Transactions$ConfigListenerNotifier$1$1.call() line: 279
FutureTask$Sync.innerRun() line: 334
FutureTask<V>.run() line: 166
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1110
ThreadPoolExecutor$Worker.run() line: 603
Thread.run() line: 722

※2 resource-ref is deleted from the specified target.

        public static void deleteResourceRef(Server server, String refName) throws TransactionFailure {
            final ResourceRef ref = getResourceRef(server, refName);
            if (ref != null) {
                ConfigSupport.apply(new SingleConfigCode<Server>() {

                    public Object run(Server param) {
                        return param.getResourceRef().remove(ref);
                    }
                }, server);
            }
        }

※3 Server#getResourceRef() returns null because of ※2(Server#deleteResourceRef).

        public static ResourceRef getResourceRef(Server server, String refName) {
            for (ResourceRef ref : server.getResourceRef()) {
                if (ref.getRef().equals(refName)) {
                    return ref;
                }
            }
            return null;
        }

※4 ResourcesUtil#isEnabled returns false because of null that ※3 returned.
the code of JdbcResourceDeployer#deleteResource()

    private void deleteResource(JdbcResource jdbcResource, ResourceInfo resourceInfo) throws Exception {

        if (ResourcesUtil.createInstance().isEnabled(jdbcResource, resourceInfo)) {★

            runtime.deleteConnectorResource(resourceInfo);
            ConnectorRegistry.getInstance().removeResourceFactories(resourceInfo);
            //In-case the resource is explicitly created with a suffix (__nontx or __PM), no need to delete one
            if (ConnectorsUtil.getValidSuffix(resourceInfo.getName()) == null) {
                String pmJndiName = ConnectorsUtil.getPMJndiName(resourceInfo.getName());
                ResourceInfo pmResourceInfo = new ResourceInfo(pmJndiName, resourceInfo.getApplicationName(),
                        resourceInfo.getModuleName());
                runtime.deleteConnectorResource(pmResourceInfo);
                ConnectorRegistry.getInstance().removeResourceFactories(pmResourceInfo);
            }

            //Since 8.1 PE/SE/EE - if no more resource-ref to the pool
            //of this resource in this server instance, remove pool from connector
            //runtime
            checkAndDeletePool(jdbcResource);
        } else {
            _logger.log(Level.FINEST, "core.resource_disabled", new Object[]{jdbcResource.getJndiName(),
                    ConnectorConstants.RES_TYPE_JDBC});
        }
    }

runtime.deleteConnectorResource(resourceInfo) is not invoked because the statement which marked as "★" returns false.

Comment by Jagadish [ 25/Jan/13 ]

Transferring to Naman for investigation

Comment by naman_mehta [ 28/Jan/13 ]

Observation on GF 4.0:

/space/gfv3/v3setup/glassfish3/glassfish/bin$ ./asadmin list-jndi-entries --context jdbc
__default: org.glassfish.resourcebase.resources.api.ResourceProxy
__TimerPool: org.glassfish.resourcebase.resources.api.ResourceProxy
Command list-jndi-entries executed successfully.
/space/gfv3/v3setup/glassfish3/glassfish/bin$ ./asadmin delete-resource-ref jdbc/__TimerPool
resource-ref jdbc/__TimerPool deleted successfully.
Command delete-resource-ref executed successfully.
/space/gfv3/v3setup/glassfish3/glassfish/bin$ ./asadmin list-jndi-entries --context jdbc
__default: org.glassfish.resourcebase.resources.api.ResourceProxy
Command list-jndi-entries executed successfully.

Observation on GF 3.1.2.2:

/space/gfv3/v3setup/glassfish3/glassfish/bin$ ./asadmin list-jndi-entries --context jdbc
__default: org.glassfish.javaee.services.ResourceProxy
__TimerPool: org.glassfish.javaee.services.ResourceProxy
Command list-jndi-entries executed successfully.
/space/gfv3/v3setup/glassfish3/glassfish/bin$ ./asadmin delete-resource-ref jdbc/__TimerPool
resource-ref jdbc/__TimerPool deleted successfully.
Command delete-resource-ref executed successfully.
/space/gfv3/v3setup/glassfish3/glassfish/bin$ ./asadmin list-jndi-entries --context jdbc
__default: org.glassfish.javaee.services.ResourceProxy
__TimerPool: org.glassfish.javaee.services.ResourceProxy
Command list-jndi-entries executed successfully.

This issue has been fixed in GF 4.0 release but still not fixed under 3.1.2.2 so assigning the same to Gajanan.

Comment by naman_mehta [ 28/Jan/13 ]

This issue is similar to 18800 which is for mail-session but during fix we fixed the same for all resources.





Generated at Wed Jun 03 00:17:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.