[JBoss JIRA] (WFLY-2658) (-Djboss.dist) jboss.dist property is not correctly propagated using -Djboss.dist
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2658?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2658:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 970610|https://bugzilla.redhat.com/show_bug.cgi?id=970610] from VERIFIED to CLOSED
> (-Djboss.dist) jboss.dist property is not correctly propagated using -Djboss.dist
> ---------------------------------------------------------------------------------
>
> Key: WFLY-2658
> URL: https://issues.jboss.org/browse/WFLY-2658
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Ondrej Zizka
>
> This JIRA is clone of bz-970610 (https://bugzilla.redhat.com/show_bug.cgi?id=970610)
> When I run testsuite of EAP 6.1.0 using command [1], where JBOSS_HOME is a path EAP 6.1.0, the manualmode tests fail with error [2]:
> It uses path defined in jboss.dist property defined in testsuite/integration/pom.xml instead of the one provided -Djboss.dist which should redefine it.
> [1] ./integration-tests.sh -Dpublic-repos -DallTests -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -Djboss.dist=${JBOSS_HOME} -Dmaven.test.failure.ignore=true -Dsurefire.forked.process.timeout=3600
> [2]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7-redhat-1:run (build-manual-mode-servers) on project jboss-as-ts-integ-manualmode: An Ant BuildException has occured: The following error occurred while executing this line:
> [ERROR] /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/src/test/scripts/manualmode-build.xml:52: /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/build/target/jboss-as-7.2.0.Final-redhat-8/modules does not exist.
> [ERROR] around Ant part ...<ant antfile="/mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/../src/test/scripts/manualmode-build.xml">... @ 4:180 in /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/target/antrun/build-main.xml
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWEB-297:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1090103|https://bugzilla.redhat.com/show_bug.cgi?id=1090103] from VERIFIED to CLOSED
> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
> Key: JBWEB-297
> URL: https://issues.jboss.org/browse/JBWEB-297
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-297.diff
>
>
> Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> public SocketState event(NioChannel channel, SocketStatus status) {
> Http11NioProcessor processor = connections.get(channel.getId());
> SocketState state = SocketState.CLOSED;
> if (processor != null) {
> processor.startProcessing();
> // Call the appropriate event
> try {
> state = processor.event(status);
> } catch (java.net.SocketException e) {
> // SocketExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> } catch (java.io.IOException e) {
> // IOExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> }
> // Future developers: if you discover any other
> // rare-but-nonfatal exceptions, catch them here, and log as
> // above.
> catch (Throwable e) {
> // any other exception or error is odd. Here we log it
> // with "ERROR" level, so it will show up even on
> // less-than-verbose logs.
> CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> } finally {
> if (state != SocketState.LONG) {
> connections.remove(channel.getId());
> recycledProcessors.offer(processor);
> {code}
> If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.
> It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-406) Redesign web session clustering
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-406?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-406:
----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from VERIFIED to CLOSED
> Redesign web session clustering
> -------------------------------
>
> Key: WFLY-406
> URL: https://issues.jboss.org/browse/WFLY-406
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Alpha2
>
>
> The current web session replication code has been around for ages and suffers from a number of issues:
> * By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
> * Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
> * Extra logic/locking is required to invalidate the local session map is required per request
> * AtomicMaps, on which the current implementation relies, have proven buggy
> * Session access outside of the scope of the replication valve is possible and problematic
> * Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
> * The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
> The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-3205) For xa-datasource testConnection should account for deployment classloader
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3205?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3205:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1083457|https://bugzilla.redhat.com/show_bug.cgi?id=1083457] from VERIFIED to CLOSED
> For xa-datasource testConnection should account for deployment classloader
> --------------------------------------------------------------------------
>
> Key: WFLY-3205
> URL: https://issues.jboss.org/browse/WFLY-3205
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.1.0.CR1
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Jay Kumar SenSharma
> Fix For: 8.1.0.Final
>
>
> - The fix mentioned in https://issues.jboss.org/browse/WFLY-2047 is resolves the issue for plain Non-XA dataSources. However if an XA-DataSource is configured with the "ldap" based database connection URL then it fails with the following Error:
> {code}
> 13:49:41,399 ERROR [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000906: Error during crash recovery: java:/OracleXA_DS (Could not create connection): javax.resource.ResourceException: Could not create connection
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:461)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:398)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.open(XAResourceRecoveryImpl.java:343)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:170)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.jts:main" from local module loader @3b70c (finder: local module finder @1e6a820 (roots: /home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules,/home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.jboss.jts:main" from local module loader @3b70c (finder: local module finder @1e6a820 (roots: /home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules,/home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base))]]
> at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:275)
> at oracle.jdbc.xa.client.OracleXADataSource.getPooledConnection(OracleXADataSource.java:454)
> at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:159)
> at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:130)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:444)
> ... 8 morec
> {code}
> - The XA dataSource configuration looks like following:
> {code}
> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
> <datasources>
> <xa-datasource jndi-name="java:/OracleXA_DS" pool-name="OracleXA_DS" enabled="true">
> <xa-datasource-property name="ServerName">
> example.com
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> TestDB
> </xa-datasource-property>
> <xa-datasource-property name="URL">
> jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA
> </xa-datasource-property>
> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
> <driver>oracle</driver>
> <security>
> <user-name>jboss</user-name>
> <password>jboss</password>
> </security>
> </xa-datasource>
> <drivers>
> <driver name="oracle" module="com.oracle.jdbc6"/>
> </drivers>
> </datasources>
> </subsystem>
> {code}
> - When the above datasource is tested via CLI like following then aht above mentioned error is noticed:
> {code}
> /subsystem=datasources/xa-data-source=OracleXA_DS:test-connection-in-pool
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-898) SharedLocalYieldingLockManager.LocalLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-898?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-898:
----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from VERIFIED to CLOSED
> SharedLocalYieldingLockManager.LocalLock
> ----------------------------------------
>
> Key: WFLY-898
> URL: https://issues.jboss.org/browse/WFLY-898
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: MJ Kim
> Assignee: Paul Ferraro
>
> Hi,
>
> Recently my system has been in the QA. (includes Stress test, Endurance test)
> During the endurance test, I found that the heap space was getting exausted, and not removed after full gc.
> When the heap space got close to 90%, the gabage collection was happend every 2 min, and my system was stopped reponding.
> The heap space was not cleaned up, nevertheless I ended the test (no request during a few hours)
>
>
> I downloaded some heap dumps, and found that the SharedLocalYieldingLockManage.LocalLock() resided much of heap space. (above 60%)
> I think the session expiration doesn't operate porperly.
>
> If the SessionBasesClusteredSession class raises the expiration signals with "LocalOnly=True", the lock would not be removed.
>
> Addionally, I reviewed our source code and did a leakage discory test, anything was matter.
>
> Here is my environment. If you want to see my standalone.xml, please post a reply thread.
>
> <Cluster>
> - 8 JVM (4 machine, each 2)
> - JDK : 1.6u31
> - OS : Amazon Linux 64bit
> - JGroups : FILE_PING (The shared storage is GlusterFS volume)
> - Infinispan operation mode : L1 + Distribution / ASYNC / expiration 1min
> - Session handling : web.xml (expiration every 1min)
> (Originally our setting was 30 min. Beacuse the load generator was sending too many requests with new session, I lowered the threshold to 1min)
> - Source code : 7.1.3 Final tag (downloaded from Github)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2593:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1040733|https://bugzilla.redhat.com/show_bug.cgi?id=1040733] from VERIFIED to CLOSED
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
> Key: WFLY-2593
> URL: https://issues.jboss.org/browse/WFLY-2593
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: No Release
> Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
> Reporter: Michael Kozak
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: No Release
>
> Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA.
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from VERIFIED to CLOSED
> deploy directories not cleaned up
> ---------------------------------
>
> Key: WFLY-1547
> URL: https://issues.jboss.org/browse/WFLY-1547
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Shaun Appleton
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
> Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-2499) JMSBridge FailureHandler does not load from specified module
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2499?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2499:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1029836|https://bugzilla.redhat.com/show_bug.cgi?id=1029836] from VERIFIED to CLOSED
> JMSBridge FailureHandler does not load from specified module
> ------------------------------------------------------------
>
> Key: WFLY-2499
> URL: https://issues.jboss.org/browse/WFLY-2499
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1
>
>
> If an error occurs and the JMS bridge tries to reconnect to the JMS provider to look up the JMS resources from its FailureHandler, it fails with the exception:
> Stack trace:
> {noformat}
> 10:37:02,546 INFO [org.hornetq.jms.server] (pool-3-thread-3) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 1,000 ms
> 10:37:03,547 WARN [org.hornetq.jms.server] (pool-3-thread-3) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.apache.qpid.jndi.PropertiesFileInitialContextFactory from classloader ModuleClassLoader for Module "org.hornetq:main" from local module loader @ac44b88 (finder: local module finder @5d3ad33d (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
> at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:64)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:681) [rt.jar:1.6.0_24]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) [rt.jar:1.6.0_24]
> at javax.naming.InitialContext.init(InitialContext.java:240) [rt.jar:1.6.0_24]
> at javax.naming.InitialContext.<init>(InitialContext.java:214) [rt.jar:1.6.0_24]
> at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55) [hornetq-jms-server.jar:]
> at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-server.jar:]
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1222) [hornetq-jms-server.jar:]
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1460) [hornetq-jms-server.jar:]
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2000(JMSBridgeImpl.java:83) [hornetq-jms-server.jar:]
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2049) [hornetq-jms-server.jar:]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
> at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
> {noformat}
> The issue is that the ExecutorService executing the FailureHandler is created when the JMSBridge is instantiated and will not use the ClassLoader from the specified module that gives access to the JMS provider's classes.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years