-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
8.12.8.6_3
-
None
-
Workaround Exists
Change of version of Mondrian from 3.5.0 to 3.12.0 causes class not found exception.
07:44:03,800 WARN [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue10) Connector worker process failed for atomic-request=NFuIrbxSPuIu.0.3.3: org.teiid.translator.TranslatorException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/mondrianDS at org.teiid.translator.olap.OlapExecutionFactory.getConnection(OlapExecutionFactory.java:87) [translator-olap-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1] at org.teiid.translator.olap.OlapExecutionFactory.getConnection(OlapExecutionFactory.java:45) [translator-olap-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1] at org.teiid.translator.ExecutionFactory.getConnection(ExecutionFactory.java:202) [teiid-api-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1] at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:330) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_102] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) at com.sun.proxy.$Proxy81.execute(Unknown Source) at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_102] at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280) at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102] Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/mondrianDS at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151) at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:69) at org.teiid.translator.olap.OlapExecutionFactory.getConnection(OlapExecutionFactory.java:85) [translator-olap-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1] ... 20 more Caused by: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/mondrianDS at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:410) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:367) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:499) at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:143) ... 22 more Caused by: javax.resource.ResourceException: IJ000658: Unexpected throwable while trying to create a connection: null at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:454) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:457) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:429) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:344) ... 25 more Caused by: javax.resource.ResourceException: Could not create connection at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:351) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:299) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:858) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:413) ... 28 more Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: mondrian.spi.impl.JndiDataSourceResolver from [Module "org.jboss.teiid.translator.olap:main" from local module loader @16f65612 (finder: local module finder @311d617d (roots: /home/jstastny/tmp-workspaces/workspace/modules,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/dv,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.9.CP,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base))] at mondrian.util.ClassResolver$AbstractClassResolver.instantiateSafe(ClassResolver.java:84) at mondrian.rolap.RolapConnection.getDataSourceResolver(RolapConnection.java:471) at mondrian.rolap.RolapConnection.createDataSource(RolapConnection.java:427) at mondrian.rolap.RolapConnection.<init>(RolapConnection.java:135) at mondrian.rolap.RolapConnection.<init>(RolapConnection.java:91) at mondrian.olap.DriverManager.getConnection(DriverManager.java:113) at mondrian.olap.DriverManager.getConnection(DriverManager.java:69) at mondrian.olap4j.MondrianOlap4jConnection.<init>(MondrianOlap4jConnection.java:162) at mondrian.olap4j.FactoryJdbc4Plus$AbstractConnection.<init>(FactoryJdbc4Plus.java:323) at mondrian.olap4j.FactoryJdbc41Impl$MondrianOlap4jConnectionJdbc41.<init>(FactoryJdbc41Impl.java:118) at mondrian.olap4j.FactoryJdbc41Impl.newConnection(FactoryJdbc41Impl.java:32) at mondrian.olap4j.MondrianOlap4jDriver.connect(MondrianOlap4jDriver.java:97) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:323) ... 31 more Caused by: java.lang.ClassNotFoundException: mondrian.spi.impl.JndiDataSourceResolver from [Module "org.jboss.teiid.translator.olap:main" from local module loader @16f65612 (finder: local module finder @311d617d (roots: /home/jstastny/tmp-workspaces/workspace/modules,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/dv,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.9.CP,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1] at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_102] at java.lang.Class.forName(Class.java:348) [rt.jar:1.8.0_102] at mondrian.util.ClassResolver$AbstractClassResolver.forName(ClassResolver.java:92) at mondrian.util.ClassResolver$AbstractClassResolver.instantiateSafe(ClassResolver.java:63) ... 43 more
But the class is present in the new version of Mondrian too, see attached screenshot with decompiled jar structure.
One workaround I found was to add dependency into olap translator's module.xml pointing at the org.mondrian module, which contains the mondrian jar.
But this action is not required when using Mondrian 3.5.0.
[TEIID-4617] Olap translator: Mondrian ClassNotFoundException moving from v 3.5.0 to 3.12.0
Steven Hawkins
added a comment - Response from the ironjacamar forum is that there's no explicit requirement, so they would be reluctant to make a change.
Steven Hawkins
added a comment - Response from the ironjacamar forum is that there's no explicit requirement, so they would be reluctant to make a change. Steven Hawkins
added a comment - And also submitted https://github.com/ironjacamar/ironjacamar/issues/594
Without a source change on some end, the workaround to just add the mondrian module to the translator module is probably the best option.
Steven Hawkins
added a comment - And also submitted https://github.com/ironjacamar/ironjacamar/issues/594
Without a source change on some end, the workaround to just add the mondrian module to the translator module is probably the best option. Steven Hawkins
added a comment - Steven Hawkins
added a comment - Also posted https://groups.google.com/forum/#!topic/ironjacamar-users/ojxxEblpe4g Either case asked in their community for response for the need to use TCCL here http://forums.pentaho.com/showthread.php?215863-Classloading-issues-with-Mondrian-driver-on-WildFly-10
Steven Hawkins
added a comment - ConnectorManager creates a proxy that handles the classloader.
> We need raise an issue with Mondrian folks.
We should confirm first if the JCA layer should be setting the thread context classloader or not. There are probably specific reasons why Mondrain is looking at the thread context.
Steven Hawkins
added a comment - ConnectorManager creates a proxy that handles the classloader.
> We need raise an issue with Mondrian folks.
We should confirm first if the JCA layer should be setting the thread context classloader or not. There are probably specific reasons why Mondrain is looking at the thread context. >> however stack shows that the TCCL is Teiid's translator module, so some where in JCA layer this is being set up
> No, Teiid does explicitly set the tccl for calls into the translator layer.
I remember we had something for this, but could not find the location? where do you see it?
>but that is not a real solution.
We need raise an issue with Mondrian folks.
Steven Hawkins
added a comment - > I do not think Teiid explicitly sets any TCCL in JCA layer
No, I'm saying that should be the responsibility of the JCA layer.
> however stack shows that the TCCL is Teiid's translator module, so some where in JCA layer this is being set up
No, Teiid does explicitly set the tccl for calls into the translator layer.
> Workaround to try is to setup "org.mondrian" as dependency on olap translator module.
Yes, Jan has confirmed that works, but that is not a real solution.
Steven Hawkins
added a comment - > I do not think Teiid explicitly sets any TCCL in JCA layer
No, I'm saying that should be the responsibility of the JCA layer.
> however stack shows that the TCCL is Teiid's translator module, so some where in JCA layer this is being set up
No, Teiid does explicitly set the tccl for calls into the translator layer.
> Workaround to try is to setup "org.mondrian" as dependency on olap translator module.
Yes, Jan has confirmed that works, but that is not a real solution. That seems wrong to depend on context loader for your compile time dependencies. I do not think Teiid explicitly sets any TCCL in JCA layer, however stack shows that the TCCL is Teiid's translator module, so some where in JCA layer this is being set up, which is may be calling classloader is setup as TCCL which is fine IMO.
Workaround to try is to setup "org.mondrian" as dependency on olap translator module.
Steven Hawkins
added a comment - I had suspected this was an olap4j dependency issue, but this makes it clear it is not. This is an issue with how the classloading is being performed by the mondrian driver such that the translator classloader, and not the driver module classloader, is being used.
Any mondrian version starting at 3.6 will have this issue as they introduced a ClassResolver class that defaults to the threadcontext classloader rather than using the class loader of a class in the jar - https://github.com/pentaho/mondrian/commit/ba9d4dfde5735c169291fb1c7ce3c912a2211b65
The thing that seems off here is that I would have thought that the JCA layer would change the threadcontext classloader.
rareddy_mk-kafka is that your expectation as well?
Steven Hawkins
added a comment - I had suspected this was an olap4j dependency issue, but this makes it clear it is not. This is an issue with how the classloading is being performed by the mondrian driver such that the translator classloader, and not the driver module classloader, is being used.
Any mondrian version starting at 3.6 will have this issue as they introduced a ClassResolver class that defaults to the threadcontext classloader rather than using the class loader of a class in the jar - https://github.com/pentaho/mondrian/commit/ba9d4dfde5735c169291fb1c7ce3c912a2211b65
The thing that seems off here is that I would have thought that the JCA layer would change the threadcontext classloader.
rareddy_mk-kafka is that your expectation as well?
Added a doc note and given the lack of interest from the other communities. Deferring any additional work until this is a customer issue.