[JBoss JIRA] (WFWIP-18) [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFWIP-18?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on WFWIP-18:
----------------------------------
[~mnovak] Upstream issue ARTEMIS-1762 has been fixed in Artemis 2.6.0 https://activemq.apache.org/artemis/release-notes-2.6.0.html.
We can retest this one with the integration branch that contains Artemis 2.6.0.
> [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
> ---------------------------------------------------------------------------------------------
>
> Key: WFWIP-18
> URL: https://issues.jboss.org/browse/WFWIP-18
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: standalone-full-ha.xml
>
>
> If Artemis is not configured to use HA then it should not create and use journal-node-manager-store-table table which is normally used by live/backup pair.
> Problem here is that especially if 2 servers are started and are using the database then administrator logically does not set journal-node-manager-store-table as HA is not used. However in the moment when both of the servers are started they use default values and both of them start to use the same table (default is NODE_MANAGER) then one of them fail with:
> {code}
> 09:20:03,246 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ221034: Waiting 60000 milliseconds to obtain live lock
> 09:21:03,517 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ224000: Failure in initialisation: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> 09:21:03,520 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 74) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: java.lang.Exception: timed out waiting for lock
> at org.wildfly.extension.messaging.activemq.jms.JMSService.lambda$doStart$0(JMSService.java:141) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivationFailureListeners(ActiveMQServerImpl.java:1908) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:82) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> Caused by: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFWIP-19) auto-[create|delete]-jms-queues are not supported in Artemis 2.4
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFWIP-19?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil resolved WFWIP-19.
------------------------------
Resolution: Done
> auto-[create|delete]-jms-queues are not supported in Artemis 2.4
> ----------------------------------------------------------------
>
> Key: WFWIP-19
> URL: https://issues.jboss.org/browse/WFWIP-19
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
>
> For more information about origin of this issue see JBEAP-13856.
> Auto-create-jms-queues and auto-delete-jms-queues enable or disable automatic creation or deletion of JMS queues when they are requested or when they are not used anymore.
> In EAP 7.1 the features are disabled by default and they are Technical previews.
> In EAP 7.2 the features cannot be disabled via mentioned management attributes and thus they are always enabled. The “cannot be” in previous sentence means that the configuration has no effect.
> *Customer impact:* Behavior of messaging broker was changed in case of automatic creation and deletion JMS destinations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFWIP-19) auto-[create|delete]-jms-queues are not supported in Artemis 2.4
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFWIP-19?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on WFWIP-19:
----------------------------------
The resolution of https://issues.jboss.org/browse/JBEAP-13876 was to deprecate these 2 attributes and set their default values to false.
I'm closing this issue as there is nothing more to do about it.
> auto-[create|delete]-jms-queues are not supported in Artemis 2.4
> ----------------------------------------------------------------
>
> Key: WFWIP-19
> URL: https://issues.jboss.org/browse/WFWIP-19
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
>
> For more information about origin of this issue see JBEAP-13856.
> Auto-create-jms-queues and auto-delete-jms-queues enable or disable automatic creation or deletion of JMS queues when they are requested or when they are not used anymore.
> In EAP 7.1 the features are disabled by default and they are Technical previews.
> In EAP 7.2 the features cannot be disabled via mentioned management attributes and thus they are always enabled. The “cannot be” in previous sentence means that the configuration has no effect.
> *Customer impact:* Behavior of messaging broker was changed in case of automatic creation and deletion JMS destinations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2262:
--------------------------------
Mid June, possibly as early as next week
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2262:
--------------------------------------
When are you planning to release 4.0.12 Final?
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10577) Undertow subsystem should not depend on clustering code.
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10577:
----------------------------------
Summary: Undertow subsystem should not depend on clustering code.
Key: WFLY-10577
URL: https://issues.jboss.org/browse/WFLY-10577
Project: WildFly
Issue Type: Bug
Components: Clustering, Web (Undertow)
Reporter: Jeff Mesnil
Assignee: Paul Ferraro
With WFLY-10352, Undertow subsystem now depends on Clustering code for Clustering's abstraction of the new MSC Service API. For example https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
As far as I can tell, the org.jboss.as.clustering.common module is bundled in servlet-feature-pack just so Undertow extension can access its API.
This is not correct. Undertow should not have to depend on clustering for this kind of abstraction.
Either these abstractions should be provided by Core or they should not be allowed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10573) ejb-xa-recovery folder is not cleaned up after testsuite
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10573?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10573:
------------------------------------
yes, the location is <wildfly-sources>/testsuite/integration/basic/ejb-xa-recovery
> ejb-xa-recovery folder is not cleaned up after testsuite
> --------------------------------------------------------
>
> Key: WFLY-10573
> URL: https://issues.jboss.org/browse/WFLY-10573
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 13.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Tom Jenkinson
>
> After the basic testsuite is run, there remains a ejb-xa-recovery folder in testsuite/integration/basic that is not properly cleaned up.
> I grepped the testsuite for ejb-xa-recovery but could not find a match.
> I suspect that this folder is created by Narayan as it deals with XA recovery.
> This folder contains a single file named 20005_00000000000000000000ffff7f0000010000f9965b2237980000003b31_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 whose content is:
> {code}
> http-remoting://127.0.0.1:8080
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10574) Support for define authentication for HotRodStore/RemoteStore
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10574?page=com.atlassian.jira.plugin... ]
Marek Posolda updated WFLY-10574:
---------------------------------
Description:
In case that I have secured JDG server through this [1] and authorization of caches like this [2], it will be nice that I am able to authenticate HotRod client to be able to access secured remote caches.
The infinispan RemoteStore has support for configure both SSL and Authentication (class org.infinispan.persistence.remote.configuration.SecurityConfiguration has 2 fields "authentication" and "ssl" ). However Wildfly subsystem doesn't seem to allow configure this.
In file jboss-as-infinispan_6_0.xsd there is "remote-cache-container", which has just "security" element, but that element has just "ssl-context" attribute. Is it possible to support authentication too?
Type "remote-store" also doesn't have a way to configure this.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2...
[2] https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2...
was:
In case that I have secured JDG server through this [1] and authorization of caches like this [2], it will be nice that I am able to authenticate HotRod client to be able to access secured remote caches.
The infinispan RemoteStore has support for configure both SSL and Authentication (class org.infinispan.persistence.remote.configuration.SecurityConfiguration has 2 fields "authentication" and "ssl" ). However Wildfly subsystem doesn't seem to allow configure this.
In file jboss-as-infinispan_6_0.xsd there is "remote-cache-container", which has just "security" element, but that element has just "ssl-context" attribute.
Type "remote-store" also doesn't have a way to configure this.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2...
[2] https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2...
> Support for define authentication for HotRodStore/RemoteStore
> -------------------------------------------------------------
>
> Key: WFLY-10574
> URL: https://issues.jboss.org/browse/WFLY-10574
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 13.0.0.Final
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
>
> In case that I have secured JDG server through this [1] and authorization of caches like this [2], it will be nice that I am able to authenticate HotRod client to be able to access secured remote caches.
> The infinispan RemoteStore has support for configure both SSL and Authentication (class org.infinispan.persistence.remote.configuration.SecurityConfiguration has 2 fields "authentication" and "ssl" ). However Wildfly subsystem doesn't seem to allow configure this.
> In file jboss-as-infinispan_6_0.xsd there is "remote-cache-container", which has just "security" element, but that element has just "ssl-context" attribute. Is it possible to support authentication too?
> Type "remote-store" also doesn't have a way to configure this.
> [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2...
> [2] https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month