[JBoss JIRA] (WFLY-11178) WSTrustTestCase failing on IBM
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFLY-11178?page=com.atlassian.jira.plugin... ]
Jan Blizňák commented on WFLY-11178:
------------------------------------
In allocated time I wasn't able to find any difference in loaded modules or stacktraces.
However, I was able to find a workaround for this particular test - adding explicit dependency to "org.apache.xerces" for one of the deployments fixed the test for IBM JDK.
But it just doesn't seem right to do that...
The next question is - is it ok for the linked picketlink sources to set the system property? I guess we can't restrict users from doing so even in application code so jboss-modules should handle that somehow, right?
> WSTrustTestCase failing on IBM
> ------------------------------
>
> Key: WFLY-11178
> URL: https://issues.jboss.org/browse/WFLY-11178
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 14.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: log.txt
>
>
> As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found
> at javax.xml.validation.SchemaFactory.newInstance(Unknown Source)
> at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94)
> at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75)
> at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120)
> ... 102 more
> {code}
> It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (DROOLS-3152) [DMN Designer] Context Expression can not be saved
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-3152?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-3152:
----------------------------------------
in XML case 3 is not feasible.
Will contact you because not clear to me what is needed here/
> [DMN Designer] Context Expression can not be saved
> --------------------------------------------------
>
> Key: DROOLS-3152
> URL: https://issues.jboss.org/browse/DROOLS-3152
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2018-10-16 15-03-23.png, error.log
>
>
> User can not save DMN diagram if it contains a decision node with *Context* as top level expression.
> Spotted during DROOLS-3109 review, however not 100% sure it is the root cause.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ]
Ivan Straka updated WFLY-11218:
-------------------------------
Affects Version/s: 15.0.0.Alpha1
> IIOP call does not work with transaction started on client side when run on IBM JDK
> -----------------------------------------------------------------------------------
>
> Key: WFLY-11218
> URL: https://issues.jboss.org/browse/WFLY-11218
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Final, 15.0.0.Alpha1
> Environment: IBM JDK 8
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Priority: Blocker
>
> Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8.
> Scenario (using CORBA):
> # start transaction
> # lookup
> # IIOP call
> # EJB perform a basic operation and return (no failure is expected)
> IIOP call fails with following exception:
> {code:java}
> java.lang.NullPointerException: null
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429)
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394)
> at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253)
> at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139)
> at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91)
> at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408)
> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274)
> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132)
> at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
> at javax.naming.InitialContext.init(InitialContext.java:255)
> at javax.naming.InitialContext.<init>(InitialContext.java:227)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126)
> {code}
> When transaction is not started on client side, IIOP call works smoothly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ]
Ivan Straka updated WFLY-11218:
-------------------------------
Steps to Reproduce:
# obtain wildfly
# clone [crashrec testsuite|http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transac...]
# run mvn clean verify -DfailIfNoTests=false -Dversion.wildfly=15.0.0.Alpha1-SNAPSHOT -Dtest=JMSCrashRecoveryTestCase#none -Dclient.side.transaction -Djbossts.noJTA
was:
* obtain wildfly
* clone [crashrec testsuite|http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transac...]
* run mvn clean verify -DfailIfNoTests=false -Dversion.wildfly=15.0.0.Alpha1-SNAPSHOT -Dtest=JMSCrashRecoveryTestCase#none -Dclient.side.transaction -Djbossts.noJTA
> IIOP call does not work with transaction started on client side when run on IBM JDK
> -----------------------------------------------------------------------------------
>
> Key: WFLY-11218
> URL: https://issues.jboss.org/browse/WFLY-11218
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Final
> Environment: IBM JDK 8
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Priority: Blocker
>
> Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8.
> Scenario (using CORBA):
> # start transaction
> # lookup
> # IIOP call
> # EJB perform a basic operation and return (no failure is expected)
> IIOP call fails with following exception:
> {code:java}
> java.lang.NullPointerException: null
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429)
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394)
> at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253)
> at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139)
> at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91)
> at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408)
> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274)
> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132)
> at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
> at javax.naming.InitialContext.init(InitialContext.java:255)
> at javax.naming.InitialContext.<init>(InitialContext.java:227)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126)
> {code}
> When transaction is not started on client side, IIOP call works smoothly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK
by Ivan Straka (Jira)
Ivan Straka created WFLY-11218:
----------------------------------
Summary: IIOP call does not work with transaction started on client side when run on IBM JDK
Key: WFLY-11218
URL: https://issues.jboss.org/browse/WFLY-11218
Project: WildFly
Issue Type: Bug
Components: IIOP
Affects Versions: 14.0.0.Final
Environment: IBM JDK 8
Reporter: Ivan Straka
Assignee: Tomasz Adamski
Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8.
Scenario (using CORBA):
# start transaction
# lookup
# IIOP call
# EJB perform a basic operation and return (no failure is expected)
IIOP call fails with following exception:
{code:java}
java.lang.NullPointerException: null
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895)
at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167)
at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139)
at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91)
at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408)
at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274)
at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132)
at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
at javax.naming.InitialContext.init(InitialContext.java:255)
at javax.naming.InitialContext.<init>(InitialContext.java:227)
at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93)
at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103)
at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164)
at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126)
{code}
When transaction is not started on client side, IIOP call works smoothly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (DROOLS-3152) [DMN Designer] Context Expression can not be saved
by Daniel José dos Santos (Jira)
[ https://issues.jboss.org/browse/DROOLS-3152?page=com.atlassian.jira.plugi... ]
Daniel José dos Santos reassigned DROOLS-3152:
----------------------------------------------
Assignee: Daniel José dos Santos (was: Matteo Mortari)
> [DMN Designer] Context Expression can not be saved
> --------------------------------------------------
>
> Key: DROOLS-3152
> URL: https://issues.jboss.org/browse/DROOLS-3152
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2018-10-16 15-03-23.png, error.log
>
>
> User can not save DMN diagram if it contains a decision node with *Context* as top level expression.
> Spotted during DROOLS-3109 review, however not 100% sure it is the root cause.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11026) Journal compacting doesn't work with JDK 11
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/WFLY-11026?page=com.atlassian.jira.plugin... ]
Ingo Weiss commented on WFLY-11026:
-----------------------------------
[~jdanek], ah ha! That worked flawlessly! I can see NIOJournalCompactTest running with Java 11.
> Journal compacting doesn't work with JDK 11
> -------------------------------------------
>
> Key: WFLY-11026
> URL: https://issues.jboss.org/browse/WFLY-11026
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Environment: {noformat}
> java 11-ea 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {noformat}
> Reporter: Martin Styk
> Assignee: Ingo Weiss
> Priority: Critical
> Labels: Java11, jdk10, jdk11
>
> Journal compacting doesn't work with Artemis 1.5 and JDK 11
> It fails with following stack trace:
> {noformat}
> 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
> at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: duplicate or slice
> at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
> {noformat}
> This causes issues also in scenario with journal replication.
> {noformat}
> 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11026) Journal compacting doesn't work with JDK 11
by Jiri Daněk (Jira)
[ https://issues.jboss.org/browse/WFLY-11026?page=com.atlassian.jira.plugin... ]
Jiri Daněk commented on WFLY-11026:
-----------------------------------
[~iweiss] You can actually change JRE in the Build Configuration window. So it is not necessary to delete the Build step, just change the JRE. I just tried it and I got the testReplicateFromSlowLive test fail with Artemis master from Oct 17 and pass with current master. On Java 10, because I still haven;t installed 11.
> Journal compacting doesn't work with JDK 11
> -------------------------------------------
>
> Key: WFLY-11026
> URL: https://issues.jboss.org/browse/WFLY-11026
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Environment: {noformat}
> java 11-ea 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {noformat}
> Reporter: Martin Styk
> Assignee: Ingo Weiss
> Priority: Critical
> Labels: Java11, jdk10, jdk11
>
> Journal compacting doesn't work with Artemis 1.5 and JDK 11
> It fails with following stack trace:
> {noformat}
> 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
> at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: duplicate or slice
> at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
> {noformat}
> This causes issues also in scenario with journal replication.
> {noformat}
> 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months