[JBoss JIRA] (WFLY-9691) JMS Clients should retry any TX transparently (100% transparent failover)
by Kabir Khan (JIRA)
Kabir Khan created WFLY-9691:
--------------------------------
Summary: JMS Clients should retry any TX transparently (100% transparent failover)
Key: WFLY-9691
URL: https://issues.jboss.org/browse/WFLY-9691
Project: WildFly
Issue Type: Feature Request
Components: JMS
Affects Versions: 10.0.0.Alpha1
Reporter: Miroslav Novak
Assignee: Clebert Suconic
Currently standalone JMS client throws exception (HornetQException or JMSException) to client application code during failover/failback and leaves on application programmer to handle this exception and retry the last operation.
This makes client code complex and developer must spent additional effort to handle those edge cases. This is complicated to achieve especially for consumer with transacted session of client acknowledge.
Goal of this jira is to provide exception free behaviour for standalone JMS clients.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-7615) Inbound connection rebalancing does not allow failover to backup
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7615?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-7615:
----------------------------------
[~mnovak] Done
> Inbound connection rebalancing does not allow failover to backup
> ----------------------------------------------------------------
>
> Key: WFLY-7615
> URL: https://issues.jboss.org/browse/WFLY-7615
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Miroslav Novak
> Assignee: Justin Bertram
> Priority: Critical
>
> If MDB contains activation config property:
> @ActivationConfigProperty(propertyName = "rebalanceConnections", propertyValue = "true")
> so rebalancing of inbound connections is enabled then MDB is not able to failover from live to backup if backup is cleanly shutdowned (ctrl-c).
> Test scenario:
> - There are 3 EAP 7 servers. 1st has Artemis configured as live and 2nd has Artemis configured as backup server. So servers are in dedicated HA topology with replicated journal. Then there are queues InQueue and OutQueue deployed to live and backup.
> - Start live and backup and then send 2000 messages to InQueue to live server.
> - Start 3rd server which has configured Artemis RA to connect to live server. HA is enabled.
> - Deploy MDB on 3rd server. MDB consumes messages from InQueue and sends to OutQueue in XA transaction.
> - When MDB is processing messages cleanly shutdown live server.
> - MDB should failover to backup and process all the messages
> - Receive messages from OutQueue from backup server and check that all messages were received.
> Test fails bacause MDB is not able to failover to backup.
> Server 3 with MDB is logging:
> {code}
> 15:16:02,975 ERROR [org.apache.activemq.artemis.ra] (NodeDOWN Connection Rebalancer) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.apache.activemq.artemis.ra.ActiveMQResourceAdapter@51f82f98 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:777) [artemis-core-client-1.1.0.redhat-5.jar:1.1.0.redhat-5]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:315)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:678)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$2.run(ActiveMQActivation.java:627)
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
> {code}
> If rebalanceConnections=false then test passes.
> How to run the test locally:
> {code}
> git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
> cd eap-tests-hornetq/scripts/
> git checkout refactoring_modules
> groovy -DEAP_VERSION=7.0.0.ER4 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=ReplicatedDedicatedFailoverTestWithMdb#testShutdown -DfailIfNoTests=false -Deap=7x | tee log
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-5838) Use WildFly thread pools in Artemis
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5838?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-5838:
----------------------------------
[~mnovak] Done
> Use WildFly thread pools in Artemis
> -----------------------------------
>
> Key: WFLY-5838
> URL: https://issues.jboss.org/browse/WFLY-5838
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> Artemis provides a feature to inject its executor and scheduled executor services when a ArtemisServer is created.
> WildFly could leverage that to inject these services so that their thread pools are managed by WildFly.
> We would have total control on the creation and configuration of these thread pools using the org.boss.as.threads extension.
> The messaging-activemq extension would be updated so that a server resource would have new children using resource definitions from the org.boss.as.threads extension to configure their pools.
> {noformat}
> * server
> * bounded-queue-thread-pool or unbounded-queue-thread-pool -> for executor service
> * scheduled-thread-pool -> for scheduled executor service
> {noformat}
> Note that this RFE would not impact the Artemis RA that does not provide such executor injection. This will be covered by another JIRA issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2160) Enhance UI in Test Scenarios Editor
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2160:
--------------------------------
Description:
Test Scenarios editor needs to be polished:
* -Delete Buttons are too small - it would be good to enlarge them.- done with
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.
was:
Test Scenarios editor needs to be polished:
* Delete Buttons are too small - it would be good to enlarge them.
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.
> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
> Key: DROOLS-2160
> URL: https://issues.jboss.org/browse/DROOLS-2160
> Project: Drools
> Issue Type: Enhancement
> Components: Test Scenarios Editor
> Reporter: Ivo Bek
> Assignee: Jozef Marko
> Labels: UX
> Attachments: Screenshot from 2017-12-01 16-38-52.png
>
>
> Test Scenarios editor needs to be polished:
> * -Delete Buttons are too small - it would be good to enlarge them.- done with
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9690) Inbound connection rebalancing does not allow failover to backup
by Kabir Khan (JIRA)
Kabir Khan created WFLY-9690:
--------------------------------
Summary: Inbound connection rebalancing does not allow failover to backup
Key: WFLY-9690
URL: https://issues.jboss.org/browse/WFLY-9690
Project: WildFly
Issue Type: Enhancement
Components: JMS
Affects Versions: 10.1.0.Final
Reporter: Miroslav Novak
Assignee: Justin Bertram
Priority: Critical
If MDB contains activation config property:
@ActivationConfigProperty(propertyName = "rebalanceConnections", propertyValue = "true")
so rebalancing of inbound connections is enabled then MDB is not able to failover from live to backup if backup is cleanly shutdowned (ctrl-c).
Test scenario:
- There are 3 EAP 7 servers. 1st has Artemis configured as live and 2nd has Artemis configured as backup server. So servers are in dedicated HA topology with replicated journal. Then there are queues InQueue and OutQueue deployed to live and backup.
- Start live and backup and then send 2000 messages to InQueue to live server.
- Start 3rd server which has configured Artemis RA to connect to live server. HA is enabled.
- Deploy MDB on 3rd server. MDB consumes messages from InQueue and sends to OutQueue in XA transaction.
- When MDB is processing messages cleanly shutdown live server.
- MDB should failover to backup and process all the messages
- Receive messages from OutQueue from backup server and check that all messages were received.
Test fails bacause MDB is not able to failover to backup.
Server 3 with MDB is logging:
{code}
15:16:02,975 ERROR [org.apache.activemq.artemis.ra] (NodeDOWN Connection Rebalancer) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.apache.activemq.artemis.ra.ActiveMQResourceAdapter@51f82f98 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:777) [artemis-core-client-1.1.0.redhat-5.jar:1.1.0.redhat-5]
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:315)
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:678)
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$2.run(ActiveMQActivation.java:627)
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
{code}
If rebalanceConnections=false then test passes.
How to run the test locally:
{code}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout refactoring_modules
groovy -DEAP_VERSION=7.0.0.ER4 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=ReplicatedDedicatedFailoverTestWithMdb#testShutdown -DfailIfNoTests=false -Deap=7x | tee log
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9689) Use WildFly thread pools in Artemis
by Kabir Khan (JIRA)
Kabir Khan created WFLY-9689:
--------------------------------
Summary: Use WildFly thread pools in Artemis
Key: WFLY-9689
URL: https://issues.jboss.org/browse/WFLY-9689
Project: WildFly
Issue Type: Enhancement
Components: JMS
Affects Versions: 10.0.0.CR4
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Artemis provides a feature to inject its executor and scheduled executor services when a ArtemisServer is created.
WildFly could leverage that to inject these services so that their thread pools are managed by WildFly.
We would have total control on the creation and configuration of these thread pools using the org.boss.as.threads extension.
The messaging-activemq extension would be updated so that a server resource would have new children using resource definitions from the org.boss.as.threads extension to configure their pools.
{noformat}
* server
* bounded-queue-thread-pool or unbounded-queue-thread-pool -> for executor service
* scheduled-thread-pool -> for scheduled executor service
{noformat}
Note that this RFE would not impact the Artemis RA that does not provide such executor injection. This will be covered by another JIRA issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9688) Messaging - default max client threads
by Kabir Khan (JIRA)
Kabir Khan created WFLY-9688:
--------------------------------
Summary: Messaging - default max client threads
Key: WFLY-9688
URL: https://issues.jboss.org/browse/WFLY-9688
Project: WildFly
Issue Type: Enhancement
Components: JMS
Affects Versions: 11.0.0.Final
Reporter: Martin Styk
Assignee: Jeff Mesnil
By default, size of client thread pool is configured as 8 * number of CPU cores.
On 1 CPU machine, with default configuration and MDB deployed on server, resource starvation is possible
On one CPU there are by default
* 8 ActiveMQ client threads (8 * CPU count)
* 4 MDB instances (mdb-strict-max-pool = 4 * CPU count)
* 15 JCA RA sessions consuming messages from queue (default value of maxSession)
Consuming of messages by MDB gets stuck because all 8 client threads are awaiting large message completion and there is no other thread to handle other tasks.
{code:title=Client thread waiting for large message completion}
"Thread-7 (ActiveMQ-client-global-threads)" #475 daemon prio=5 os_prio=0
tid=0x000000000590f000 nid=0x7c7a in Object.wait() [0x00007fda43413000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:302)
- locked <0x00000000b0083e88> (a
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
at
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:276)
- locked <0x00000000b0083e88> (a
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
at
org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:159)
at
org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkCompletion(ClientLargeMessageImpl.java:84)
at
org.apache.activemq.artemis.jms.client.ActiveMQMessage.doBeforeReceive(ActiveMQMessage.java:786)
at
org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:110)
at
org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:295)
at
org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001)
at
org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49)
at
org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124)
at
org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
{code}
This can be fixed by adjusting default values for these parameters.
In this case, we need more client threads than JCA RA sessions (maxSession).
To avoid resource starvation, number of client threads must be greater than sum of {{maxSession}} for each MDB deployed on server.
We should check number of client threads required by deployments (MDBs), and at least print warning message that size of client thread pool may be insufficient.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9433) Apply InfiniteOrPositiveValidators to messaging attributes allow valid value -1
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-9433?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-9433:
----------------------------------
[~mnovak] Done
[~soul2zimate] [~jmesnil] Please adjust the state of the EAP7 issue accordingly
> Apply InfiniteOrPositiveValidators to messaging attributes allow valid value -1
> -------------------------------------------------------------------------------
>
> Key: WFLY-9433
> URL: https://issues.jboss.org/browse/WFLY-9433
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 11.0.0.CR1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 12.0.0.Alpha1
>
>
> There are several attributes defined from ActiveMQ Artemis configuration parameters in ActiveMQClient.java and ActiveMQDefaultConfiguration.java are allowed to take value -1.
> As they miss proper InfiniteOrPositiveValidators, they can also take any negative values which is incorrect.
> {noformat}
> ActiveMQClient.java
> public static final long DEFAULT_CLIENT_FAILURE_CHECK_PERIOD_INVM = -1;
> public static final long DEFAULT_CONNECTION_TTL_INVM = -1;
> public static final int DEFAULT_CONSUMER_MAX_RATE = -1;
> public static final int DEFAULT_CONFIRMATION_WINDOW_SIZE = -1;
> public static final int DEFAULT_PRODUCER_MAX_RATE = -1;
> public static final int DEFAULT_THREAD_POOL_MAX_SIZE = -1;
> ActiveMQDefaultConfiguration.java
> private static long DEFAULT_CONNECTION_TTL_OVERRIDE = -1;
> private static int DEFAULT_JOURNAL_POOL_FILES = -1;
> private static long DEFAULT_CONNECTION_TTL_OVERRIDE = -1;
> private static int DEFAULT_JOURNAL_PERF_BLAST_PAGES = -1;
> private static long DEFAULT_SERVER_DUMP_INTERVAL = -1;
> private static long DEFAULT_MEMORY_MEASURE_INTERVAL = -1;
> private static int DEFAULT_BRIDGE_INITIAL_CONNECT_ATTEMPTS = -1;
> private static int DEFAULT_BRIDGE_RECONNECT_ATTEMPTS = -1;
> private static int DEFAULT_BRIDGE_PRODUCER_WINDOW_SIZE = -1;
> private static int DEFAULT_CLUSTER_INITIAL_CONNECT_ATTEMPTS = -1;
> private static int DEFAULT_CLUSTER_RECONNECT_ATTEMPTS = -1;
> private static int DEFAULT_HAPOLICY_BACKUP_REQUEST_RETRIES = -1;
> private static int DEFAULT_GROUPING_HANDLER_GROUP_TIMEOUT = -1;
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2249) Generate Decision Table Graph automatically
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2249?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2249:
--------------------------------
Tester: Jozef Marko
> Generate Decision Table Graph automatically
> -------------------------------------------
>
> Key: DROOLS-2249
> URL: https://issues.jboss.org/browse/DROOLS-2249
> Project: Drools
> Issue Type: Feature Request
> Components: Guided Decision Table Editor
> Reporter: Ivo Bek
> Assignee: Michael Anstis
> Labels: codefest
>
> We think that the user doesn't need to create multiple decision table graphs in a single project. Instead whenever user creates his/her first decision table, the graph should be generated automatically and should contain all the decision tables available in the project.
> When a user opens a decision table, the editor could have a button "Display Linked Tables" which would open the graph.
> Then, we could remove the Decision Table Graph from the new Asset list because there would always be just single graph generated automatically and accessible from the asset list and/or Decision Table editor.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months