[JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi... ]
Artur Kronenberg commented on DROOLS-1030:
------------------------------------------
This just happened again to me. I think this exception is related: http://pastebin.com/uStYMNg5
I also managed to confirm that:
* Breakpoint in JpaTimerJobInstance line 48 (before the getCommandService() call) does fix the issue. There seems to be a race as to when the CommandServiceTimerJobFactoryManager is available.
* Once the breakpoint is set and run through, the session "fixes itself", meaning that on a subsequent recreation the timertask is no longer run when creating the session. I seem to not understand when the timerJob is running and what for. But it appears that a session can be stored so that no timer-jobs have to be run. Is that correct?
> Nullpointer in JpaTimerJobInstance.call on startup
> ---------------------------------------------------
>
> Key: DROOLS-1030
> URL: https://issues.jboss.org/browse/DROOLS-1030
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
>
> Hi,
> I have noticed Nullpointer exceptions when I try and reload a persisted session on startup. It is a bit hard to recreate (I am actually not managing it now since I deleted all old sessions to attempt recreation) but I figured maybe someone has an idea. Essentially I am getting this NPE twice:
> java.lang.NullPointerException: null
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> When debugging I noticed the following behaviour which points to a race condition:
> If I start my server and try to recreate the session, those NPEs happen 2x.
> If I start my server and put a breakpoint BEFORE creating the CommandService for execution, I can wait for a few seconds and the service can be found.
> It appears that the scheduler's timerJobFactoryManager is not fully there at the time the sessions is being loaded? Or something else is racing with the service creation.
> Is there a way for me to make sure everything is fully instantiated before I use drools? Does a workaround exist? Is this even a bug?
> Thanks and let me know your thoughts. If I run into this again I will attempt to try and reproduce it. Let me know if more info is needed!
> UPDATE:
> I noticed that the reason I can't reproduce it at the moment is that the JpaTimerJobInstance is never called with the newly persisted session. It appears that that timer job depends on something else to happen so that it thinks it needs to start the timerJob
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1993:
--------------------------------
[~NadirX] Any updates on this?
> ENCRYPTAsymmetricTest fails on IBM jdk 1.8
> ------------------------------------------
>
> Key: JGRP-1993
> URL: https://issues.jboss.org/browse/JGRP-1993
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Environment: IBM jdk 1.8
> Reporter: Richard Janík
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8
>
>
> org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final):
> {code}
> Error Message
> expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8]
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:496)
> at org.testng.Assert.assertEquals(Assert.java:125)
> at org.testng.Assert.assertEquals(Assert.java:167)
> at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "u" on HPUX
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ]
Petr Kremensky updated WFCORE-929:
----------------------------------
Summary: CLI is terminated unexpectedly after type "u" on HPUX (was: CLI is terminated unexpectedly after type "qui" on HPUX)
> CLI is terminated unexpectedly after type "u" on HPUX
> -----------------------------------------------------
>
> Key: WFCORE-929
> URL: https://issues.jboss.org/browse/WFCORE-929
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> *Description of problem:*
> CLI is terminated unexpectedly after type "qui" on HPUX
> *How reproducible:*
> Always on HPUX
> *Steps to Reproduce:*
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # qui
> #* type "qui" in console to CLI, do not press "enter"
> *Actual results:*
> CLI is terminated
> *Expected results:*
> CLI is not terminated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "u" on HPUX
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ]
Petr Kremensky updated WFCORE-929:
----------------------------------
Priority: Major (was: Minor)
> CLI is terminated unexpectedly after type "u" on HPUX
> -----------------------------------------------------
>
> Key: WFCORE-929
> URL: https://issues.jboss.org/browse/WFCORE-929
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Alexey Loubyansky
>
> *Description of problem:*
> CLI is terminated unexpectedly after type "qui" on HPUX
> *How reproducible:*
> Always on HPUX
> *Steps to Reproduce:*
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # qui
> #* type "qui" in console to CLI, do not press "enter"
> *Actual results:*
> CLI is terminated
> *Expected results:*
> CLI is not terminated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6042) ISPN000136: Error executing command LockControlCommand, writing keys []: java.lang.NullPointerException
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6042?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-6042:
---------------------------------
Affects Version/s: 10.0.0.CR5
> ISPN000136: Error executing command LockControlCommand, writing keys []: java.lang.NullPointerException
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6042
> URL: https://issues.jboss.org/browse/WFLY-6042
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> Seen in these scenarios in ER4:
> ejb-ejbremote-jvmkill-dist-async
> http-session-jvmkill-dist-async-3owners
> When perf21 was killed, perf19 got a new cluster view and then logged NPE:
> {code}
> [JBossINF] [0m[31m13:38:53,963 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p7-t47) ISPN000136: Error executing command LockControlCommand, writing keys []: java.lang.NullPointerException
> [JBossINF] at org.infinispan.transaction.impl.AbstractCacheTransaction.getReleaseFutureForKeys(AbstractCacheTransaction.java:392)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.lambda$getTransactionWithAnyLockedKey$174(DefaultPendingLockManager.java:267)
> [JBossINF] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$ValuesView.forEach(EquivalentConcurrentHashMapV8.java:4604)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.forEachTransaction(DefaultPendingLockManager.java:285)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.getTransactionWithAnyLockedKey(DefaultPendingLockManager.java:264)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForAnyPendingLocks(DefaultPendingLockManager.java:207)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:136)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:197)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> [JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:122)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6042) ISPN000136: Error executing command LockControlCommand, writing keys []: java.lang.NullPointerException
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-6042:
------------------------------------
Summary: ISPN000136: Error executing command LockControlCommand, writing keys []: java.lang.NullPointerException
Key: WFLY-6042
URL: https://issues.jboss.org/browse/WFLY-6042
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Michal Vinkler
Assignee: Paul Ferraro
Seen in these scenarios in ER4:
ejb-ejbremote-jvmkill-dist-async
http-session-jvmkill-dist-async-3owners
When perf21 was killed, perf19 got a new cluster view and then logged NPE:
{code}
[JBossINF] [0m[31m13:38:53,963 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p7-t47) ISPN000136: Error executing command LockControlCommand, writing keys []: java.lang.NullPointerException
[JBossINF] at org.infinispan.transaction.impl.AbstractCacheTransaction.getReleaseFutureForKeys(AbstractCacheTransaction.java:392)
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.lambda$getTransactionWithAnyLockedKey$174(DefaultPendingLockManager.java:267)
[JBossINF] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$ValuesView.forEach(EquivalentConcurrentHashMapV8.java:4604)
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.forEachTransaction(DefaultPendingLockManager.java:285)
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.getTransactionWithAnyLockedKey(DefaultPendingLockManager.java:264)
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForAnyPendingLocks(DefaultPendingLockManager.java:207)
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:136)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:197)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
[JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
[JBossINF] at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
[JBossINF] at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
[JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
[JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
[JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:122)
[JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
[JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[JBossINF] at java.lang.Thread.run(Thread.java:745)
{code}
Link:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-267) CLI prints output twice if using cli client jar
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-267?page=com.atlassian.jira.plugin... ]
Petr Kremensky reassigned WFCORE-267:
-------------------------------------
Assignee: Petr Kremensky (was: James Perkins)
> CLI prints output twice if using cli client jar
> -----------------------------------------------
>
> Key: WFCORE-267
> URL: https://issues.jboss.org/browse/WFCORE-267
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.Alpha13
> Reporter: Stan Silvert
> Assignee: Petr Kremensky
> Fix For: 1.0.0.Alpha14
>
>
> If you are using the [CLI client jar|https://developer.jboss.org/wiki/UsingTheCLIRemoteClientJar], all output is printed twice. This is because JBoss logging is not set up and by default CommandContextImpl is printing log messages to standard out. The output will look something like this:
> {code}
> [standalone@localhost:9999 /] :read-children-types
> Nov 19, 2014 8:57:19 AM org.jboss.as.cli.impl.CommandContextImpl printLine
> INFO: {
> "outcome" => "success",
> "result" => [
> "core-service",
> "deployment",
> "deployment-overlay",
> "extension",
> "interface",
> "path",
> "socket-binding-group",
> "subsystem",
> "system-property"
> ]
> }
> {
> "outcome" => "success",
> "result" => [
> "core-service",
> "deployment",
> "deployment-overlay",
> "extension",
> "interface",
> "path",
> "socket-binding-group",
> "subsystem",
> "system-property"
> ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5995) Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5995?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5995:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1298651|https://bugzilla.redhat.com/show_bug.cgi?id=1298651] from ASSIGNED to POST
> Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5995
> URL: https://issues.jboss.org/browse/WFLY-5995
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.CR5
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: timers, timerservice
> Fix For: 10.0.0.Final
>
>
> If a scheduled timer should be created with the following parameters:
> ScheduleExpression[second=0 minute=0/5 hour=20-22 dayOfWeek=* dayOfMonth=* month=* year=* start=Thu Jan 14 09:45:35 GMT+1 2016]
> The first schedule should be
> Thu Jan 17 20:00:20 GMT+1 2016
> but is calculated as
> Sun Jan 17 20:45:35 GMT+1 2016
> The minutes are not correctly set according to the schedule and the given start date.
> This happen for seconds/minutes if the ScheduleExpression limit the range.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6041) <node> failed submitting DONT_BUNDLE message to thread pool during server startup
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-6041:
------------------------------------
Summary: <node> failed submitting DONT_BUNDLE message to thread pool during server startup
Key: WFLY-6041
URL: https://issues.jboss.org/browse/WFLY-6041
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Michal Vinkler
Assignee: Paul Ferraro
Priority: Minor
Seen in these scenarios in ER4:
http-session-shutdown-repl-async-tcpStack
ejb-ejbservlet-shutdown-dist-async
During server startup (the server was restarted after previous graceful shutdown), this error was logged several times:
{code}
[JBossINF] [0m[31m20:12:25,912 ERROR [org.jgroups.protocols.UDP] (multicast receiver,ee,perf19) perf19: failed submitting DONT_BUNDLE message to thread pool: java.util.concurrent.RejectedExecutionException: Task org.jgroups.protocols.TP$SingleMessageHandler@7a718788 rejected from java.util.concurrent.ThreadPoolExecutor@66f4f3ee[Running, pool size = 300, active threads = 300, queued tasks = 0, completed tasks = 1130]. Msg: RequestCorrelator: id=200, type=REQ, id=125094, rsp_expected=true, FORK: ee:web, NAKACK2: [MSG, seqno=123637], UDP: [cluster_name=ee]
{code}
It had no impact on the client though.
Link:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6041) <node> failed submitting DONT_BUNDLE message to thread pool during server startup
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6041?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-6041:
---------------------------------
Affects Version/s: 10.0.0.CR5
> <node> failed submitting DONT_BUNDLE message to thread pool during server startup
> ---------------------------------------------------------------------------------
>
> Key: WFLY-6041
> URL: https://issues.jboss.org/browse/WFLY-6041
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Minor
>
> Seen in these scenarios in ER4:
> http-session-shutdown-repl-async-tcpStack
> ejb-ejbservlet-shutdown-dist-async
> During server startup (the server was restarted after previous graceful shutdown), this error was logged several times:
> {code}
> [JBossINF] [0m[31m20:12:25,912 ERROR [org.jgroups.protocols.UDP] (multicast receiver,ee,perf19) perf19: failed submitting DONT_BUNDLE message to thread pool: java.util.concurrent.RejectedExecutionException: Task org.jgroups.protocols.TP$SingleMessageHandler@7a718788 rejected from java.util.concurrent.ThreadPoolExecutor@66f4f3ee[Running, pool size = 300, active threads = 300, queued tasks = 0, completed tasks = 1130]. Msg: RequestCorrelator: id=200, type=REQ, id=125094, rsp_expected=true, FORK: ee:web, NAKACK2: [MSG, seqno=123637], UDP: [cluster_name=ee]
> {code}
> It had no impact on the client though.
> Link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months