June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4723) Clustering TS: make the default stack SYNC and REPL

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-4723: ----------------------------------- Summary: Clustering TS: make the default stack SYNC and REPL Key: AS7-4723 URL: https://issues.jboss.org/browse/AS7-4723 Project: Application Server 7 Issue Type: Feature Request Components: Clustering, Test Suite Affects Versions: 7.1.1.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 7.1.2.Final (EAP) As per discussion with Jason on AS7 ML. This will enable us to * run faster (no sleep) * and avoid painful intermittent failures -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
2
0 / 0

[JBoss JIRA] (AS7-3253) Test DS connection in pool, gone?

by Heiko Braun (Created) (JIRA)

Test DS connection in pool, gone? --------------------------------- Key: AS7-3253 URL: https://issues.jboss.org/browse/AS7-3253 Project: Application Server 7 Issue Type: Bug Reporter: Heiko Braun Fix For: 7.1.0.Final There used to be an operation to verify a datasource connection. On recent master it's gone? [ERROR] "outcome" => "failed", [ERROR] "failure-description" => "JBAS015850: No handler for operation test-connection-in-pool at address [ [ERROR] (\"profile\" => \"default\"), [ERROR] (\"subsystem\" => \"datasources\"), [ERROR] (\"data-source\" => \"ExampleDS\") [ERROR] ]", -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2301) Get rid of System.out.println statement

by Juraj Tomasov (JIRA)

Get rid of System.out.println statement --------------------------------------- Key: JBRULES-2301 URL: https://jira.jboss.org/jira/browse/JBRULES-2301 Project: Drools Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.0.M1 Reporter: Juraj Tomasov Assignee: Mark Proctor Priority: Minor System.out.println statement is currently used in 280 project files. I propose to replace them with logger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

9
18
0 / 0

[JBoss JIRA] (AS7-3808) CacheLoaderException: Root not directory or IO error occurred

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-3808: ----------------------------------- Summary: CacheLoaderException: Root not directory or IO error occurred Key: AS7-3808 URL: https://issues.jboss.org/browse/AS7-3808 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.0.Final Reporter: Radoslav Husar Assignee: Paul Ferraro Fix For: 7.1.1.Final While testing failover on undeploy, I ran into rather cryptic exception: "Root not directory or IO error occurred" The machine shouldnt run into IO errors, probably related AS7-3161? Can we get a better wording here as well? {noformat} [JBossINF] 20:48:40,309 ERROR [org.infinispan.loaders.AbstractCacheStore] (Scheduled-eviction-thread-3) ISPN000045: Problems encountered while purging expired: org.infinispan.loaders.CacheLoaderException: Root not directory or IO error occurred [JBossINF] at org.infinispan.loaders.file.FileCacheStore.purgeInternal(FileCacheStore.java:205) [infinispan-core-5.1.1.FINAL.jar:5.1.1.FINAL] [JBossINF] at org.infinispan.loaders.AbstractCacheStore$2.run(AbstractCacheStore.java:106) [infinispan-core-5.1.1.FINAL.jar:5.1.1.FINAL] [JBossINF] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:41) [infinispan-core-5.1.1.FINAL.jar:5.1.1.FINAL] [JBossINF] at org.infinispan.loaders.AbstractCacheStore.purgeExpired(AbstractCacheStore.java:103) [infinispan-core-5.1.1.FINAL.jar:5.1.1.FINAL] [JBossINF] at org.infinispan.eviction.EvictionManagerImpl.processEviction(EvictionManagerImpl.java:118) [infinispan-core-5.1.1.FINAL.jar:5.1.1.FINAL] [JBossINF] at org.infinispan.eviction.EvictionManagerImpl$ScheduledTask.run(EvictionManagerImpl.java:144) [infinispan-core-5.1.1.FINAL.jar:5.1.1.FINAL] [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_30] [JBossINF] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [rt.jar:1.6.0_30] [JBossINF] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [rt.jar:1.6.0_30] [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [rt.jar:1.6.0_30] [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.6.0_30] [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [rt.jar:1.6.0_30] [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30] [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30] [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
17
0 / 0

[JBoss JIRA] (JBRULES-3551) KnowledgeRuntimeLogger should be activable by enabling category logging and send it's output to slf4j

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3551: ----------------------------------------- Summary: KnowledgeRuntimeLogger should be activable by enabling category logging and send it's output to slf4j Key: JBRULES-3551 URL: https://issues.jboss.org/browse/JBRULES-3551 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (expert) Environment: http://docs.jboss.org/drools/release/5.4.0.Final/drools-expert-docs/html_... Reporter: Geoffrey De Smet Assignee: Mark Proctor Drools's audit logging should log to slf4j, so the user can easily configure advanced logging features such as rolling files, zipped files, ... Also enabling the logging should be user friendly. So instead of this: {code} KnowledgeRuntimeLogger logger = KnowledgeRuntimeLoggerFactory.newFileLogger(ksession, "logdir/mylogfile"); ... logger.close(); {code} They just enable it in the logger configuration (logback.xml or log4j.xml): {code} <logger name="org.drools.logger.audit" level="trace"/> {code} This way, drools's audit logging is no longer the odd duck in the normal logging output. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
1
0 / 0

[JBoss JIRA] (AS7-4260) Exception acquiring ownership of X

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-4260: ----------------------------------- Summary: Exception acquiring ownership of X Key: AS7-4260 URL: https://issues.jboss.org/browse/AS7-4260 Project: Application Server 7 Issue Type: Bug Reporter: Radoslav Husar {noformat} 13:09:28,290 WARN [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session qLQps+CQJxEi6pJTBSzis0g3 failed; switching to a brute force cleanup. Problem is JBAS018060: Exception acquiring ownership of qLQps+CQJxEi6pJTBSzis0g3 {noformat} {noformat} 12:55:49,556 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.ejb] (Incoming-2,null) JBAS010248: New cluster view for partition ejb: 6 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@327579f6 delta: -1, merge: false) 12:55:49,557 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf21/ejb|6] [perf21/ejb, perf20/ejb, perf18/ejb] 12:56:31,694 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20-10.16.90.58-8009-211) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of MvwC8KGWTuKPjD1-JjLW7URZ at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.ClusteredSession.expire(ClusteredSession.java:1260) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:1208) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:598) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.DistributableSessionManager.add(DistributableSessionManager.java:917) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1407) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:686) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:85) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.13.Final.jar:] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.13.Final.jar:] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.13.Final.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//clusterbench/MvwC8KGWTuKPjD1-JjLW7URZ from cluster at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439) at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372) at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] ... 23 more {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

8
28
0 / 0

[JBoss JIRA] (AS7-3146) HibernatePersistenceProviderAdaptor's putPropertyIfAbsent should check the pu.getProperties() instead of the empty HashMap

by Philippe Guinot (Created) (JIRA)

HibernatePersistenceProviderAdaptor's putPropertyIfAbsent should check the pu.getProperties() instead of the empty HashMap -------------------------------------------------------------------------------------------------------------------------- Key: AS7-3146 URL: https://issues.jboss.org/browse/AS7-3146 Project: Application Server 7 Issue Type: Bug Components: JPA / Hibernate Affects Versions: 7.1.0.CR1b Reporter: Philippe Guinot Assignee: Scott Marlow In org.jboss.as.jpa.hibernate3.HibernatePersistenceProviderAdaptor and org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor putPropertyIfAbsent should check the pu.getProperties() instead of the empty HashMap. If not, AS7-2460 does not work as the override does not take in account what is present in persistence.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
2
0 / 0

[JBoss JIRA] (JBRULES-3359) Planning entity locking: A planning variable can be immutable for Planner based on a boolean method on the entity

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3359: ----------------------------------------- Summary: Planning entity locking: A planning variable can be immutable for Planner based on a boolean method on the entity Key: JBRULES-3359 URL: https://issues.jboss.org/browse/JBRULES-3359 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet For use case of "windowed planning", see manual section "repeated planning". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
7
0 / 0

[JBoss JIRA] (AS7-4540) Exception thrown in JGroups subsystem when diagnostics address/port and udp address/port are distinct

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created AS7-4540: ---------------------------------------- Summary: Exception thrown in JGroups subsystem when diagnostics address/port and udp address/port are distinct Key: AS7-4540 URL: https://issues.jboss.org/browse/AS7-4540 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.1.Final Reporter: Richard Achmatowicz Assignee: Bela Ban When using JGroups as part of AS7 in the server configuration standalone-ha.xml, upon start up, we receive the exception: {noformat} 09:52:36,831 ERROR [org.jboss.msc.service.fail] (pool-14-thread-1) MSC00001: Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:62) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] Caused by: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different at org.jgroups.protocols.UDP.createSockets(UDP.java:359) [jgroups-3.0.9.Final.jar:3.0.9.Final] at org.jgroups.protocols.UDP.start(UDP.java:224) [jgroups-3.0.9.Final.jar:3.0.9.Final] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938) [jgroups-3.0.9.Final.jar:3.0.9.Final] at org.jgroups.JChannel.startStack(JChannel.java:841) [jgroups-3.0.9.Final.jar:3.0.9.Final] at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.0.9.Final.jar:3.0.9.Final] at org.jgroups.JChannel.connect(JChannel.java:261) [jgroups-3.0.9.Final.jar:3.0.9.Final] at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:44) [jboss-as-clustering-jgroups-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:59) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] {noformat} even when the address / port combination for udp and the address / port combination for diagnostics are distinct: {noformat} <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> ... <socket-binding name="jgroups-diagnostics" port="0" multicast-address="ff0e::1" multicast-port="7500"/> <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45700"/> <socket-binding name="jgroups-tcp" port="7600"/> <socket-binding name="jgroups-tcp-fd" port="57600"/> <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45688"/> <socket-binding name="jgroups-udp-fd" port="54200"/> <socket-binding name="modcluster" port="0" multicast-address="ff0e::1" multicast-port="23364"/> ... </socket-binding-group> {noformat} The expected behaviour is that as long as the ports are distinct, we should be able to use the same mcast address for both udp and diagnostics. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

5
5
0 / 0

[JBoss JIRA] (AS7-4881) Remote EJB clients hanging after EJBClient.createSession when using DIST

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-4881: ----------------------------------- Summary: Remote EJB clients hanging after EJBClient.createSession when using DIST Key: AS7-4881 URL: https://issues.jboss.org/browse/AS7-4881 Project: Application Server 7 Issue Type: Bug Components: Clustering, EJB Affects Versions: 7.1.2.Final (EAP) Reporter: Radoslav Husar Assignee: jaikiran pai Priority: Critical Fix For: 7.1.3.Final (EAP) We are seeing that in stress tests (positive test, no failures), the clients hang when using DIST mode; both SYNC and ASYNC. The clients hang in method [1]; there is nothing suspicious on the server side. [2] The client has no knowledge about repl/dist topology, thus this should be a server-side issue. As of filing, we are investigating the issue. Job https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Performance-Cluste... Client code https://svn.devel.redhat.com/repos/jboss-qa/load-testing/sf-components/pr... App code https://github.com/rhusar/clusterbench [1] {noformat} "Runner - 1279" daemon prio=10 tid=0x00007f4388950000 nid=0x73df in Object.wait() [0x00007f423ed29000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.xnio.AbstractIoFuture.awaitInterruptibly(AbstractIoFuture.java:123) - locked <0x00000006c0285ad0> (a java.lang.Object) at org.jboss.ejb.client.remoting.IoFutureHelper$1.get(IoFutureHelper.java:57) at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:236) at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:163) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:148) at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:58) at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51) at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87) at java.lang.Thread.run(Thread.java:662) {noformat} [1] {noformat} "EJB default - 10" prio=10 tid=0x00007fefcc059000 nid=0x308b waiting on condition [0x00007fefa7a33000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000006bfe65cc8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:662) at org.jboss.threads.JBossThread.run(JBossThread.java:122) {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2012