[JBoss JIRA] (DROOLS-2825) Drools @Expires is not working with x seconds 7.4.1 Final Drools version
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2825?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2825:
--------------------------------
Sprint: 2018 Week 33-35
> Drools @Expires is not working with x seconds 7.4.1 Final Drools version
> ------------------------------------------------------------------------
>
> Key: DROOLS-2825
> URL: https://issues.jboss.org/browse/DROOLS-2825
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.4.1.Final
> Reporter: Srinivas ev
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.4.1.Final
>
> Attachments: EvictionTest.zip, heap.PNG
>
>
> Attached reproducer. Please check once,
> I inserted 5 Fact POJO's. It should have deleted after 200s based on declaration in the rule file.
> declare Fact
> @role( event )
> @expires(200s)
> end
> Heap dump shows the 5 entries even after I took the heap dump after 10 minutes. Please let me know regarding this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1637) Change ReferralMode.toString to return value
by Philippe Marschall (JIRA)
Philippe Marschall created ELY-1637:
---------------------------------------
Summary: Change ReferralMode.toString to return value
Key: ELY-1637
URL: https://issues.jboss.org/browse/ELY-1637
Project: WildFly Elytron
Issue Type: Enhancement
Reporter: Philippe Marschall
Assignee: Darran Lofthouse
The documentation of the referral-mode attribute in WildFly says the allowed values should be "ignore", "follow", "throw". However they are currently serialized as "IGNORE", "FOLLOW", "THROW". This is a WildFly issue and not an Elytron issue.
However as part of the discussion on how to best fix WFCORE-3971 the easiest solution seems to be to change {{ReferralMode#toString()}}, that way the parser does not have to change.
Once WildFly upgrades to a version of Elytron with this change a couple of tests will fail as the serialized model will intentionally change.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-28) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Michal Toth (JIRA)
[ https://issues.jboss.org/browse/WFWIP-28?page=com.atlassian.jira.plugin.s... ]
Michal Toth commented on WFWIP-28:
----------------------------------
Nope, maybe [~opiske] have such data gathered via perf tests.
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFWIP-28
> URL: https://issues.jboss.org/browse/WFWIP-28
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: sosreport-rvaisdebug.asd-20180807101658.tar.xz
>
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-28) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-28?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak resolved WFWIP-28.
---------------------------------
Resolution: Done
Marking as resolved based on above.
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFWIP-28
> URL: https://issues.jboss.org/browse/WFWIP-28
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: sosreport-rvaisdebug.asd-20180807101658.tar.xz
>
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-28) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-28?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-28:
-------------------------------------
[~fnigro] After reducing Xmx to 1GB for both of the servers, SOAK test finally passed.
??HEAP size (-xmx) + OFF-HEAP/native allocations (they could be == -xmx, but it isn't counted by the JVM as heap allocation) + JVM footprint (~100MB would be enough).??
I agree with this formula. afaik Oracle JDK allocates OFF-HEAP memory == -Xmx (heap memory). Based on this we're still in limits but it's suspicious that it was not hit by Artemis 1.5.
[~mtoth]
>From customer perspective consuming more resources after upgrade of EAP 7.1(Artemis 1,5)->EAP 7.2(Artemis 2.x) is not a good thing. Do you have a test where you check native memory allocation for Artemis 2.x and how often it's cleaned by GC cycles?
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFWIP-28
> URL: https://issues.jboss.org/browse/WFWIP-28
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: sosreport-rvaisdebug.asd-20180807101658.tar.xz
>
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10795) Non-Elytron SSL configuration won't establish secure channel between worker and balancer
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-10795?page=com.atlassian.jira.plugin... ]
Jan Kašík edited comment on WFLY-10795 at 8/13/18 3:36 AM:
-----------------------------------------------------------
[~rhusar] Tanks for he quick PR! I did some prestesting which didn't go well. During reload which follows adding security realm and its configuration (authentication and server identity), following exception shows up:
{code}
08:42:17,822 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 58) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]): java.lang.IllegalStateException: java.io.IOException: Keystore was tampered with, or password was incorrect
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:113)
at org.wildfly.extension.mod_cluster.ProxyConfigurationServiceConfigurator.configure(ProxyConfigurationServiceConfigurator.java:315)
at org.wildfly.extension.mod_cluster.ModClusterSubsystemServiceHandler.installServices(ModClusterSubsystemServiceHandler.java:79)
at org.jboss.as.clustering.controller.AddStepHandler.performRuntime(AddStepHandler.java:179)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:338)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:159)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:780)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
at java.security.KeyStore.load(KeyStore.java:1445)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getStore(JSSESocketFactory.java:230)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeystore(JSSESocketFactory.java:179)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:251)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:98)
... 15 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:778)
... 23 more
{code}
Again, everything works with same configuration in 7.1.
EDIT: Just came to my mind, that this might not be related...
was (Author: jkasik):
[~rhusar] Tanks for he quick PR! I did some prestesting which didn't go well. During reload which follows adding security realm and its configuration (authentication and server identity), following exception shows up:
{code}
08:42:17,822 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 58) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]): java.lang.IllegalStateException: java.io.IOException: Keystore was tampered with, or password was incorrect
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:113)
at org.wildfly.extension.mod_cluster.ProxyConfigurationServiceConfigurator.configure(ProxyConfigurationServiceConfigurator.java:315)
at org.wildfly.extension.mod_cluster.ModClusterSubsystemServiceHandler.installServices(ModClusterSubsystemServiceHandler.java:79)
at org.jboss.as.clustering.controller.AddStepHandler.performRuntime(AddStepHandler.java:179)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:338)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:159)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:780)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
at java.security.KeyStore.load(KeyStore.java:1445)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getStore(JSSESocketFactory.java:230)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeystore(JSSESocketFactory.java:179)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:251)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:98)
... 15 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:778)
... 23 more
{code}
Again, everything works with same configuration in 7.1.
> Non-Elytron SSL configuration won't establish secure channel between worker and balancer
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-10795
> URL: https://issues.jboss.org/browse/WFLY-10795
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: No Release
> Environment: Latest snapshot from ci.wildfly.org
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
> Attachments: confs.zip
>
>
> When running scenario, where connection between worker and balancer is secured with SSL, worker fails to register on balancer.
> Worker obviously tries to send INFO commands, though it sends it as a 'plain text' to a secured channel.
> I enabled SSL debugging, and such unsecured-secured communication causes this error:
> {code}
> 09:42:20,456 INFO [stdout] (default I/O-4) Using SSLEngineImpl.
> 09:42:20,458 INFO [stdout] (default I/O-4) Allow unsafe renegotiation: false
> 09:42:20,458 INFO [stdout] (default I/O-4) Allow legacy hello messages: true
> 09:42:20,458 INFO [stdout] (default I/O-4) Is initial handshake: true
> 09:42:20,459 INFO [stdout] (default I/O-4) Is secure renegotiation: false
> 09:42:20,459 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,479 INFO [stdout] (default I/O-4) default I/O-4, fatal error: 80: problem unwrapping net record
> 09:42:20,480 INFO [stdout] (default I/O-4) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, SEND TLSv1.2 ALERT: fatal, description = internal_error
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, WRITE: TLSv1.2 Alert, length = 2
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeInbound()
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeOutbound()
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, closeOutboundInternal()
> {code}
> What bothers me, that there are no other errors (bad certificate, CLI error...) in log regarding this. Apart from:
> {code}
> 09:45:42,653 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t16) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 6 from wildfly-14.0.0.Beta2-SNAPSHOT-2
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: org.infinispan.util.logging.TraceException
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> {code}
> Configuration using non-Elytron configuration was possible before, hence this is a regression.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-103) [Artemis upgrade] NPE Unable to create management notification address
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-103?page=com.atlassian.jira.plugin.... ]
Erich Duda updated WFWIP-103:
-----------------------------
Steps to Reproduce:
The test passes even if the issue is present. You have to check server logs whether the issue is present or not.
{code}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout eap7.2.x-artemis2.x-ha-jdbc
groovy -DEAP_ZIP_URL=... PrepareServers7.groovy
export WORKSPACE=$PWD
export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
cd ../jboss-hornetq-testsuite/
mvn clean test -Dtest=DedicatedFailoverTestCase#testMultipleFailoverWithQueueShutdown -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1533784013-SNAPSHOT -DfailIfNoTests=false -Deap=7x | tee log
{code}
was:
The test passes even if the issue is present. You have to check server logs whether the issue is present or not.
{code}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
groovy -DEAP_ZIP_URL=... PrepareServers7.groovy
export WORKSPACE=$PWD
export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
cd ../jboss-hornetq-testsuite/
mvn clean test -Dtest=DedicatedFailoverTestCase#testMultipleFailoverWithQueueShutdown -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1533784013-SNAPSHOT -DfailIfNoTests=false -Deap=7x | tee log
{code}
> [Artemis upgrade] NPE Unable to create management notification address
> ----------------------------------------------------------------------
>
> Key: WFWIP-103
> URL: https://issues.jboss.org/browse/WFWIP-103
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Martyn Taylor
> Priority: Blocker
>
> *Scenario*
> * There are two Wildfly servers configured in messaging dedicated shared store HA topology
> * Live server is several times killed and restarted
> * Test checks that clients do failover/failback
> When the backup server gets activated it logs several {{NullPointerExceptions}}.
> {code}
> 09:21:30,985 WARN [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=4bac7aa0-9ec9-11e8-86b6-cc3d825f79a4) AMQ222270: Unable to create management notification address: activemq.notifications: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl$1.activated(ManagementServiceImpl.java:553) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivateCallbacks(ActiveMQServerImpl.java:2220) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2455) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:90) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:3236) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> {code}
> The NPE has not functional impact in our scenario but it can have in different scenarios.
> Blocker priority was chosen because this is regression against WF 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-103) [Artemis upgrade] NPE Unable to create management notification address
by Erich Duda (JIRA)
Erich Duda created WFWIP-103:
--------------------------------
Summary: [Artemis upgrade] NPE Unable to create management notification address
Key: WFWIP-103
URL: https://issues.jboss.org/browse/WFWIP-103
Project: WildFly WIP
Issue Type: Bug
Components: Artemis
Reporter: Erich Duda
Assignee: Martyn Taylor
Priority: Blocker
*Scenario*
* There are two Wildfly servers configured in messaging dedicated shared store HA topology
* Live server is several times killed and restarted
* Test checks that clients do failover/failback
When the backup server gets activated it logs several {{NullPointerExceptions}}.
{code}
09:21:30,985 WARN [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=4bac7aa0-9ec9-11e8-86b6-cc3d825f79a4) AMQ222270: Unable to create management notification address: activemq.notifications: java.lang.NullPointerException
at org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl$1.activated(ManagementServiceImpl.java:553) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivateCallbacks(ActiveMQServerImpl.java:2220) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2455) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:90) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:3236) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
{code}
The NPE has not functional impact in our scenario but it can have in different scenarios.
Blocker priority was chosen because this is regression against WF 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months