Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 809060

Summary: Getting CNFE: org.infinispan.loaders.jdbc.connectionfactory.ManagedConnectionFactory when using jdbc cache store
Product: [JBoss] JBoss Data Grid 6 Reporter: Martin Gencur <mgencur>
Component: unspecifiedAssignee: Tristan Tarrant <ttarrant>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0.0CC: jdg-bugs
Target Milestone: ---   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
As a result of a race condition between the server module and the Infinispan subsystem, a server configured with JDBC cache store may occasionally fail to start. The server either started as expected or failed to start. </para> <para> This occurred when the Memcached server attempted to obtain the memcachedCache before the Infinispan subsystem had a chance to start it (even in EAGER mode). As the server module was forcing its own classloader as TCCL, the cache could not find the necessary classes needed by the cache loaders. </para> <para> This behavior is now fixed and a server configured with the JDBC cache store no longer experiences and unexpected starting failures.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2025-02-10 03:19:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Standalone.xml config none

Description Martin Gencur 2012-04-02 11:23:43 UTC 
Created attachment 574468 [details]
Standalone.xml config

Description of problem:

I'm not able to start a JDG server when jdbc cache store is configured but this happens only sometimes. Example of such error can be found here: https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/edg-60-jdbc-cache-stores-rhel6-jdk6/67/DATABASE=oracle11gR2,jdk=java16_default,label=dev88-rhel6-x86/testReport/junit/com.jboss.datagrid.test.cachestore.jdbc.stringbased/JdbcStringBasedCacheStorePassivationDisabledTest/testPreloadWithoutPurge/

I was able to reproduce it on my laptop after few attempts to start the JDG server. Attaching standalone.xml configuration...


How reproducible:

Start JDG with the attached config.
Comment 1 Tristan Tarrant 2012-04-03 08:17:20 UTC 
Looks like it's getting the TCCL instead of the module classloader of the infinispan subsystem.
Investigating
Comment 2 Tristan Tarrant 2012-04-04 12:47:24 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
This happens very rarely when starting the server, and it cannot happen if the server started successfully. The solution is to restart the server.
Comment 3 Martin Gencur 2012-04-04 12:54:25 UTC 
Solution? You mean workaround ? :-)
Comment 4 Misha H. Ali 2012-04-04 16:10:56 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-This happens very rarely when starting the server, and it cannot happen if the server started successfully. The solution is to restart the server.+A server configured with JDBC cache store may occasionally fail to start. If the server starts as expected, this configuration does not cause any problems. If the server fails to start, restarting the server resolves the problem.
Comment 5 Martin Gencur 2012-05-02 08:53:32 UTC 
This problem still exists. An example can be found e.g. at https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/edg-60-jdbc-cache-stores-rhel6-jdk6/DATABASE=sybase155,jdk=java16_default,label=dev88-rhel6-x86/69/console, also happening with other databases in the same run.
Comment 6 Tristan Tarrant 2012-05-07 13:05:10 UTC 
This was due to a race condition between the server module and the infinispan subsystem and it happened whenever the Memcached server (as it is the only server which does so) attempted to obtain the memcachedCache before the Infinispan subsystem had a chance to start it (even in EAGER mode).
As the server module was forcing its own classloader as TCCL, the cache could not find the necessary classes needed by the cache loaders.
Comment 7 Martin Gencur 2012-05-11 10:45:58 UTC 
Verified with ER8. I'm not able to reproduce the bug anymore.
Comment 8 Misha H. Ali 2012-06-05 22:25:02 UTC 
This bug is marked for inclusion in the JDG 6 GA Release Notes. Added notes based on c#6 about cause.
Comment 9 Misha H. Ali 2012-06-05 22:25:02 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,7 @@
-A server configured with JDBC cache store may occasionally fail to start. If the server starts as expected, this configuration does not cause any problems. If the server fails to start, restarting the server resolves the problem.+As a result of a race condition between the server module and the Infinispan subsystem, a server configured with JDBC cache store may occasionally fail to start. The server either started as expected or failed to start. 
+</para>
+<para>
+This occurred when the Memcached server attempted to obtain the memcachedCache before the Infinispan subsystem had a chance to start it (even in EAGER mode). As the server module was forcing its own classloader as TCCL, the cache could not find the necessary classes needed by the cache loaders.
+</para>
+<para>
+This behavior is now fixed and a server configured with the JDBC cache store no longer experiences and unexpected starting failures.
Comment 11 Red Hat Bugzilla 2025-02-10 03:19:28 UTC 
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.