[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
was:
I'm creating my KieSession by setting STREAM as the event processing mode in the configuration:
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
kc.updateToVersion( ... newReleaseId... );
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
KieSession ksession = kc.newKieSession();
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM.
When doing a dynamic update using the KieContainer.updateToVersion()
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{
> KieBaseConfiguration config = KieServices.Factory.get()
> .newKieBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
>
> KieContainer kc = ks.newKieContainer( ... releaseId ... );
> KieSession ksession = kc.newKieBase(config).newKieSession();
> }}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{
> kc.updateToVersion( ... newReleaseId... );
> }}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{
> KieSession ksession = kc.newKieSession();
> }}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{ KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{ KieBaseConfiguration config = KieServices.Factory.get()
> .newKieBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
>
> KieContainer kc = ks.newKieContainer( ... releaseId ... );
> KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{
> kc.updateToVersion( ... newReleaseId... );
> }}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{
> KieSession ksession = kc.newKieSession();
> }}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
Tihomir Meščić created DROOLS-654:
-------------------------------------
Summary: Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
Key: DROOLS-654
URL: https://issues.jboss.org/browse/DROOLS-654
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.CR2, 6.1.0.Final
Environment: Ubuntu Linux
Reporter: Tihomir Meščić
Assignee: Mark Proctor
Priority: Blocker
I'm creating my KieSession by setting STREAM as the event processing mode in the configuration:
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
kc.updateToVersion( ... newReleaseId... );
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
KieSession ksession = kc.newKieSession();
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM.
When doing a dynamic update using the KieContainer.updateToVersion()
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar commented on WFLY-825:
----------------------------------
8.0.0.Final is quite old and has few known problems in undertow / xnio area that ware fixed in later releases.
Can you try with 8.2.0.Final that was released last week?
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: WFLY-825
> URL: https://issues.jboss.org/browse/WFLY-825
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: operating system - z/OS version 1.13
> JDK version info:
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
> IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR2_20120809_0948_B118929
> JIT - r11.b01_20120808_24925
> GC - R26_Java726_SR2_20120809_0948_B118929
> J9CL - 20120809_118929)
> JCL - 20120831_02 based on Oracle 7u3-b05
> Reporter: Bob Bennett
> Assignee: Jason Greene
> Labels: jboss
> Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
>
>
> When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
> Hi Bob,
>
> Have you contacted JBoss support for this issue?
>
> From my review of the javacore, every application-related thread is
> waiting on some kind of internal state monitoring code. The most
> prominent cause of waiting appears to be a CountdownLatch used in:
>
> org/jboss/as/controller/ParallelBootOperationStepHandler
> $ParallelBootTransactionControl.operationPrepared
>
> A quick search found this possibly related JBoss bug which was
> introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
> how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
>
> The CountdownLatch is one of the Concurrency classes, and is very
> simplistic in that it allows an application to direct threads to wait
> until some certain number of actions have occured. The application code
> (JBoss in this case) would need to explain how many countdowns are
> required and which piece of code decrements the counter as needed.
>
> There's not much to say from a JVM perspective other than the threads
> are all waiting for an application-level event (a call to the
> "countDown()" method 'N' times where 'N' is how many JBoss initialized
> the CountDownLatch to originally.)
>
> If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
> they think should be executing and why. A system dump of the problem
> (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
> but that won't really be of any use if we don't know what JBoss expects
> them to be.
>
> Regards,
> Java Defect Support
> Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
by Gabor Auth (JIRA)
[ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.... ]
Gabor Auth commented on WFLY-3718:
----------------------------------
Ok, I've downloaded, installed and the issue is exists, the root cause is same:
{code}
==> /home/wildfly/wildfly-8.2.0.Final/domain/servers/server-two/log/server.log <==
2014-11-25 11:31:14,351 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (SessionExpirationScheduler - 1) ISPN000136: Execution error: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.NullPointerException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager@294d7185
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:211)
at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:229)
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:192)
at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:230)
at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:96)
at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:213)
at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:92)
at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:91)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:275)
at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:80)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:132)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321)
at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402)
at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:216)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitRemoveCommand(PessimisticLockingInterceptor.java:145)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255)
at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:196)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:206)
at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:156)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:407)
at org.infinispan.CacheImpl.remove(CacheImpl.java:400)
at org.infinispan.DecoratedCache.remove(DecoratedCache.java:406)
at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:281)
at org.jboss.as.clustering.infinispan.invoker.Remover$RemoveOperation.invoke(Remover.java:49)
at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:87)
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:117)
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:55)
at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
at org.wildfly.clustering.web.infinispan.session.ExpiredSessionRemover.remove(ExpiredSessionRemover.java:47)
at org.wildfly.clustering.web.infinispan.session.ExpiredSessionRemover.remove(ExpiredSessionRemover.java:32)
at org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler$ExpirationTask.run(SessionExpirationScheduler.java:131)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_11]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_11]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_11]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_11]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.NullPointerException
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:238)
at sun.reflect.GeneratedMethodAccessor188.invoke(Unknown Source) [:1.8.0_11]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_11]
at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_11]
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:207)
... 80 more
{code}
> UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3718
> URL: https://issues.jboss.org/browse/WFLY-3718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: WildFly 8.1.0.Final
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
> Fix For: 8.2.0.Final
>
>
> 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-4122) Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main"
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-4122:
--------------------------------------
Summary: Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main"
Key: WFLY-4122
URL: https://issues.jboss.org/browse/WFLY-4122
Project: WildFly
Issue Type: Bug
Components: Web Services
Reporter: Darran Lofthouse
Assignee: Alessio Soldano
Fix For: 9.0.0.Beta1
Attachments: org.jboss.as.webservices.config.ServerConfigImplTestCase.txt, TEST-org.jboss.as.webservices.config.ServerConfigImplTestCase.xml
Currently unable to build WildFly - however this error only seems to affect a couple of users.
The build is failing at the following tests: -
{noformat}
Running org.jboss.as.webservices.config.ServerConfigImplTestCase
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.007 sec <<< FAILURE! - in org.jboss.as.webservices.config.ServerConfigImplTestCase
testSingleAttributeUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.005 sec <<< ERROR!
java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51)
at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335)
at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64)
at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestSingleAttributeUpdate(ServerConfigImplTestCase.java:144)
at org.jboss.as.webservices.config.ServerConfigImplTestCase.testSingleAttributeUpdate(ServerConfigImplTestCase.java:71)
testIsModifiable(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0 sec <<< ERROR!
java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51)
at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335)
at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64)
at org.jboss.as.webservices.config.ServerConfigImplTestCase.testIsModifiable(ServerConfigImplTestCase.java:56)
testMultipleAttributesUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.002 sec <<< ERROR!
java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51)
at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335)
at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64)
at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestMultipleAttributeUpdate(ServerConfigImplTestCase.java:172)
at org.jboss.as.webservices.config.ServerConfigImplTestCase.testMultipleAttributesUpdate(ServerConfigImplTestCase.java:135)
Results :
Tests in error:
ServerConfigImplTestCase.testSingleAttributeUpdate:71->internalTestSingleAttributeUpdate:144 » Runtime
ServerConfigImplTestCase.testIsModifiable:56 » Runtime org.jboss.modules.Modul...
ServerConfigImplTestCase.testMultipleAttributesUpdate:135->internalTestMultipleAttributeUpdate:172 » Runtime
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-4122) Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main"
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4122?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-4122:
-----------------------------------
Attachment: org.jboss.as.webservices.config.ServerConfigImplTestCase.txt
TEST-org.jboss.as.webservices.config.ServerConfigImplTestCase.xml
> Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main"
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4122
> URL: https://issues.jboss.org/browse/WFLY-4122
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Darran Lofthouse
> Assignee: Alessio Soldano
> Fix For: 9.0.0.Beta1
>
> Attachments: org.jboss.as.webservices.config.ServerConfigImplTestCase.txt, TEST-org.jboss.as.webservices.config.ServerConfigImplTestCase.xml
>
>
> Currently unable to build WildFly - however this error only seems to affect a couple of users.
> The build is failing at the following tests: -
> {noformat}
> Running org.jboss.as.webservices.config.ServerConfigImplTestCase
> Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.007 sec <<< FAILURE! - in org.jboss.as.webservices.config.ServerConfigImplTestCase
> testSingleAttributeUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.005 sec <<< ERROR!
> java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
> at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51)
> at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335)
> at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64)
> at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestSingleAttributeUpdate(ServerConfigImplTestCase.java:144)
> at org.jboss.as.webservices.config.ServerConfigImplTestCase.testSingleAttributeUpdate(ServerConfigImplTestCase.java:71)
> testIsModifiable(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0 sec <<< ERROR!
> java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
> at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51)
> at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335)
> at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64)
> at org.jboss.as.webservices.config.ServerConfigImplTestCase.testIsModifiable(ServerConfigImplTestCase.java:56)
> testMultipleAttributesUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.002 sec <<< ERROR!
> java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
> at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51)
> at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335)
> at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64)
> at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestMultipleAttributeUpdate(ServerConfigImplTestCase.java:172)
> at org.jboss.as.webservices.config.ServerConfigImplTestCase.testMultipleAttributesUpdate(ServerConfigImplTestCase.java:135)
> Results :
> Tests in error:
> ServerConfigImplTestCase.testSingleAttributeUpdate:71->internalTestSingleAttributeUpdate:144 » Runtime
> ServerConfigImplTestCase.testIsModifiable:56 » Runtime org.jboss.modules.Modul...
> ServerConfigImplTestCase.testMultipleAttributesUpdate:135->internalTestMultipleAttributeUpdate:172 » Runtime
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
by Stefan Stefan (JIRA)
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s... ]
Stefan Stefan commented on WFLY-825:
------------------------------------
Are there any news on this topic?
I've a similar problem with Wildfly 8.0.0.Final on IBM Power i with JDK 7 and JAX-RS Webservices that block on following Stacktrace:
{noformat}
3XMTHREADINFO "default task-1" J9VMThread:0x000000018D4C7E00, j9thread_t:0x0000000187F1C890, java/lang/Thread:0x0700000070D206D0, state:B, prio=5
3XMJAVALTHREAD (java/lang/Thread getId:0xA5, isDaemon:false)
3XMTHREADINFO1 (native thread ID:0x3DF015, native priority:0x5, native policy:UNKNOWN)
3XMTHREADBLOCK Blocked on: java/util/Collections$UnmodifiableSet@0x07000000016445B0 Owned by: "default I/O-1" (J9VMThread:0x0000000186EB7F00, java/lang/Thread:0x070000000166BC98)
3XMHEAPALLOC Heap bytes allocated since last GC cycle=1426832 (0x15C590)
3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:133)
4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.interestOps(SelectionKeyImpl.java:95)
4XESTACKTRACE at org/xnio/nio/WorkerThread.setOps(WorkerThread.java:738)
4XESTACKTRACE at org/xnio/nio/NioHandle.resume(NioHandle.java:42)
4XESTACKTRACE at org/xnio/nio/NioSocketConduit.resumeReads(NioSocketConduit.java:324)
4XESTACKTRACE at org/xnio/conduits/ConduitStreamSourceChannel.resumeReads(ConduitStreamSourceChannel.java:135)
4XESTACKTRACE at io/undertow/server/protocol/http/HttpReadListener.exchangeComplete(HttpReadListener.java:219)
4XESTACKTRACE at io/undertow/server/protocol/http/HttpServerConnection.exchangeComplete(HttpServerConnection.java:218)
4XESTACKTRACE at io/undertow/server/HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1090)
4XESTACKTRACE at io/undertow/server/HttpServerExchange.terminateResponse(HttpServerExchange.java:1310)
4XESTACKTRACE at io/undertow/server/Connectors.terminateResponse(Connectors.java:69)
4XESTACKTRACE at io/undertow/server/protocol/http/ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
4XESTACKTRACE at io/undertow/conduits/AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:249)
4XESTACKTRACE at io/undertow/conduits/AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:183)
4XESTACKTRACE at org/xnio/conduits/ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
4XESTACKTRACE at io/undertow/channels/DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
4XESTACKTRACE at org/xnio/channels/Channels.flushBlocking(Channels.java:63)
4XESTACKTRACE at io/undertow/servlet/spec/ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:623)
4XESTACKTRACE at io/undertow/servlet/spec/HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
4XESTACKTRACE at io/undertow/servlet/spec/HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.access$000(ServletInitialHandler.java:73)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
4XESTACKTRACE at io/undertow/server/Connectors.executeRootHandler(Connectors.java:168)
4XESTACKTRACE at io/undertow/server/HttpServerExchange$1.run(HttpServerExchange.java:687)
4XESTACKTRACE at java/util/concurrent/ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
4XESTACKTRACE at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
4XESTACKTRACE at java/lang/Thread.run(Thread.java:780)
{noformat}
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: WFLY-825
> URL: https://issues.jboss.org/browse/WFLY-825
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: operating system - z/OS version 1.13
> JDK version info:
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
> IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR2_20120809_0948_B118929
> JIT - r11.b01_20120808_24925
> GC - R26_Java726_SR2_20120809_0948_B118929
> J9CL - 20120809_118929)
> JCL - 20120831_02 based on Oracle 7u3-b05
> Reporter: Bob Bennett
> Assignee: Jason Greene
> Labels: jboss
> Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
>
>
> When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
> Hi Bob,
>
> Have you contacted JBoss support for this issue?
>
> From my review of the javacore, every application-related thread is
> waiting on some kind of internal state monitoring code. The most
> prominent cause of waiting appears to be a CountdownLatch used in:
>
> org/jboss/as/controller/ParallelBootOperationStepHandler
> $ParallelBootTransactionControl.operationPrepared
>
> A quick search found this possibly related JBoss bug which was
> introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
> how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
>
> The CountdownLatch is one of the Concurrency classes, and is very
> simplistic in that it allows an application to direct threads to wait
> until some certain number of actions have occured. The application code
> (JBoss in this case) would need to explain how many countdowns are
> required and which piece of code decrements the counter as needed.
>
> There's not much to say from a JVM perspective other than the threads
> are all waiting for an application-level event (a call to the
> "countDown()" method 'N' times where 'N' is how many JBoss initialized
> the CountDownLatch to originally.)
>
> If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
> they think should be executing and why. A system dump of the problem
> (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
> but that won't really be of any use if we don't know what JBoss expects
> them to be.
>
> Regards,
> Java Defect Support
> Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1878:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1167666|https://bugzilla.redhat.com/show_bug.cgi?id=1167666] from NEW to ASSIGNED
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months