[JBoss JIRA] (WFWIP-42) Pushing of n key should cause searching of last pattern from history
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFWIP-42?page=com.atlassian.jira.plugin.s... ]
Jean-Francois Denise commented on WFWIP-42:
-------------------------------------------
[~eduda], this makes full sense, feature implemented and added to analysis doc.
> Pushing of n key should cause searching of last pattern from history
> --------------------------------------------------------------------
>
> Key: WFWIP-42
> URL: https://issues.jboss.org/browse/WFWIP-42
> Project: WildFly WIP
> Issue Type: Enhancement
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> When you open file by {{less}} or {{vim}} and as a first command you push {{n}} key, the applications start to search last pattern from the history. I would expect the same behavior in CLI.
> Note: I know that history of patterns is not persisted in CLI. However it is persisted between commands in one session. E.g. I can dump elytron subsystem and search an attribute, then dump messaging subsystem and search the same attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (WFWIP-42) Pushing of n key should cause searching of last pattern from history
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-42?page=com.atlassian.jira.plugin.s... ]
Erich Duda commented on WFWIP-42:
---------------------------------
Thanks [~jdenise]. I tried it and it works as expected. However there is one small difference with comparison to {{less}}/{{vim}} commands. They work also with capital {{N}}.
Use case: I will dump messaging subsystem, go to end of output using END and then hit N button to search last occurrence of pattern.
> Pushing of n key should cause searching of last pattern from history
> --------------------------------------------------------------------
>
> Key: WFWIP-42
> URL: https://issues.jboss.org/browse/WFWIP-42
> Project: WildFly WIP
> Issue Type: Enhancement
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> When you open file by {{less}} or {{vim}} and as a first command you push {{n}} key, the applications start to search last pattern from the history. I would expect the same behavior in CLI.
> Note: I know that history of patterns is not persisted in CLI. However it is persisted between commands in one session. E.g. I can dump elytron subsystem and search an attribute, then dump messaging subsystem and search the same attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (WFWIP-10) [Artemis 2.x Upgrade] Old (Artemis 1.5..5) client cannot create subscription on Artemis 2.x server
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-10?page=com.atlassian.jira.plugin.s... ]
Martin Styk updated WFWIP-10:
-----------------------------
Component/s: (was: JMS)
> [Artemis 2.x Upgrade] Old (Artemis 1.5..5) client cannot create subscription on Artemis 2.x server
> --------------------------------------------------------------------------------------------------
>
> Key: WFWIP-10
> URL: https://issues.jboss.org/browse/WFWIP-10
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
>
> If Artemis 1.5.5 client tries to subscribe on topic with latest Artemis 2.x (Artemis repo: https://github.com/mnovak1/activemq-artemis/ , branch: ARTEMIS-1609 , commit: e45e75af64859dc43bfe40e0a4c6b81187cc20e4) then JMSException is thrown:
> {code}
> 04:28:00,121 Thread-15 ERROR [org.jboss.qa.hornetq.apps.clients.SubscriberTransAck:172] Exception thrown during subsribing.
> javax.jms.JMSException
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:404)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:315)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.queueQuery(ActiveMQSessionContext.java:254)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.queueQuery(ClientSessionImpl.java:344)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createConsumer(ActiveMQSession.java:689)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createDurableSubscriber(ActiveMQSession.java:426)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createDurableSubscriber(ActiveMQSession.java:400)
> at org.jboss.qa.hornetq.apps.clients.SubscriberTransAck.subscribe(SubscriberTransAck.java:166)
> at org.jboss.qa.hornetq.apps.clients.TopicClientsTransAck.startClients(TopicClientsTransAck.java:77)
> at org.jboss.qa.artemis.test.compatibility.Eap7ClientCompatibilityTestCase.testNettyClient(Eap7ClientCompatibilityTestCase.java:169)
> at org.jboss.qa.artemis.test.compatibility.Eap7ClientCompatibilityTestCase.testNettyTransAckTopic(Eap7ClientCompatibilityTestCase.java:159)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> {code}
> There is NPE on server with:
> {code}
> 15:32:15,509 WARN [org.apache.activemq.artemis.core.server] (Thread-7 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@5b9dcfa)) AMQ222225: Sending unexpected exception to the client: java.lang.NullPointerException
> at org.apache.activemq.artemis.api.core.SimpleString.concat(SimpleString.java:399) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.QueueAbstractPacket.getOldPrefixedAddress(QueueAbstractPacket.java:115) [artemis-core-client-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:393) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:281) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> {code}
> Looking at code there is processed packet {{SessionQueueQueryMessage}} on server which does not have set {{address}} variable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (WFWIP-23) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-23?page=com.atlassian.jira.plugin.s... ]
Martin Styk updated WFWIP-23:
-----------------------------
Component/s: Artemis
(was: JMS)
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-23
> URL: https://issues.jboss.org/browse/WFWIP-23
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Jiri Ondrusek
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (WFWIP-21) [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-21?page=com.atlassian.jira.plugin.s... ]
Martin Styk updated WFWIP-21:
-----------------------------
Component/s: (was: JMS)
> [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
> ---------------------------------------------------------------------------------
>
> Key: WFWIP-21
> URL: https://issues.jboss.org/browse/WFWIP-21
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Test scenario:
> * Start cluster A of nodes node-1, node-3
> * Start cluster B of nodes node-2, node-4
> * Send messages to queue on node-1
> * Deploy mdbs to servers in cluster A. This mdb reads messages from local queue, sends them to remote queue on cluster B and inserts them into database
> * Deploy mdbs to servers in cluster B. This mdb reads messages from local queue and inserts them into database
> * Cause CPU overload (for 5 min) on server node-2 when mdbs on cluster1 and 2 are processing mesages
> * Restart failed server
> * Let MDBs to process remaining messages
> Pass Criteria: Number of sent message is equal number of records(lines) in database and messages in
> Actual Result:
> Sometimes happens that one record is missing in database which means that one message was not processed be MDB in cluster 2.
> This looks like broker related regression against Artemis 1.5.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis tag 2.5.0.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (WFWIP-39) Regression in JMS bridge with network failures tests
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-39?page=com.atlassian.jira.plugin.s... ]
Martin Styk updated WFWIP-39:
-----------------------------
Component/s: Artemis
(was: JMS)
> Regression in JMS bridge with network failures tests
> ----------------------------------------------------
>
> Key: WFWIP-39
> URL: https://issues.jboss.org/browse/WFWIP-39
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
> Attachments: org.jboss.qa.hornetq.test.bridges.NetworkFailuresJMSBridgesTestCase.zip
>
>
> *Scenario*
> Node A and B are started. JMS bridge with {{once and only once}} delivery and 1 reconnect attempt is deployed on node A. Producer starts sending mix of normal and large messages to InQueue on node A. Jms bridge resends messages from A's InQueue to B's OutQueue. During this time short network failure sequence (network goes down and then up) is executed twice. Receiver receives messages from OutQueue(also from node A). After that, network stays disconnected. Another receiver receives remaining messages from A's InQueue.
> {noformat:title=Jms Bridge}
> <jms-bridge name="myBridge" module="org.apache.activemq.artemis" quality-of-service="ONCE_AND_ONLY_ONCE" failure-retry-interval="1000" max-retries="1" max-batch-size="10" max-batch-time="100" add-messageID-in-header="true">
> <source connection-factory="java:/ConnectionFactory" destination="jms/queue/InQueue"/>
> <target connection-factory="jms/BridgeConnectionFactory" destination="jms/queue/OutQueue">
> <target-context>
> <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
> <property name="java.naming.provider.url" value="http-remoting://127.0.0.1:9080"/>
> </target-context>
> </target>
> </jms-bridge>
> {noformat}
> *Issue*
> * node A's InQueue and node B's OutQueue is empty
> * There are no prepared transactions on node A
> * some messages *are missing* after test (multiply of 10, which is number of messages in one transaction)
> * this scenario fails *intermittently*
> 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)
> Logs are attached.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (WFWIP-12) [Artemis upgrade] Output of CLI operations in messaging subsystem's server changed from 7.1
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-12?page=com.atlassian.jira.plugin.s... ]
Martin Styk updated WFWIP-12:
-----------------------------
Component/s: Artemis
(was: JMS)
> [Artemis upgrade] Output of CLI operations in messaging subsystem's server changed from 7.1
> -------------------------------------------------------------------------------------------
>
> Key: WFWIP-12
> URL: https://issues.jboss.org/browse/WFWIP-12
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Martin Styk
> Assignee: Ingo Weiss
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Original Estimate: 2 hours
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> Output of CLI operations in messaging subsystem's server element changed and it is is missing some attributes it used to display in EAP 7.1.
> _Affected operations_
> *list-all-consumers-as-json* and *list-consumers-as-json*
> Missing attributes
> * destinationName
> * destinationType
> * durable
> {noformat:title="7.1.0.GA"}
> Result list-all-consumers-as-json{"outcome" => "success","result" => "[{\"consumerID\":0,\"connectionID\":\"-733935378\",\"sessionID\":\"fede1b60-04e9-11e8-9641-cc3d825a3be2\",\"queueName\":\"testSubscriberClientId-hornetqCliOperations.testSubscriber-hqServerCliOperations\",\"browseOnly\":false,\"creationTime\":1517226368495,\"destinationName\":\"testTopic\",\"destinationType\":\"topic\",\"durable\":true}]"}
> {noformat}
> {noformat:title="Wildfly latest with artemis 2.x"}
> Result list-all-consumers-as-json{"outcome" => "success","result" => "[{\"consumerID\":0,\"connectionID\":\"784f1287\",\"sessionID\":\"f146b48e-04e3-11e8-bb50-cc3d825a3be2\",\"queueName\":\"jms.queue.testQueue\",\"browseOnly\":false,\"creationTime\":1517223768695,\"deliveringCount\":8}]"}
> {noformat}
> *list-connections-as-json*
> Missing attributes
> * clientID
> {noformat:title="7.1.0.GA"}
> "result" => "[{\"connectionID\":\"1343044951\",\"clientAddress\":\"/127.0.0.1:57038\",\"creationTime\":1517303830995,\"clientID\":\"testSubscriberClientId-hornetqCliOperations\"},{\"connectionID\":\"2052915500\",\"clientAddress\":\"/127.0.0.1:57040\",\"creationTime\":1517303831216},{\"connectionID\":\"668896556\",\"clientAddress\":\"/127.0.0.1:57042\",\"creationTime\":1517303831210},{\"connectionID\":\"2096792561\",\"clientAddress\":\"/127.0.0.1:57044\",\"creationTime\":1517303831223,\"clientID\":\"testPublisherClientId\"}]"
> {noformat}
> {noformat:title="Wildfly latest with artemis 2.x"}
> "result" => "[{\"connectionID\":\"a8842f44\",\"clientAddress\":\"/127.0.0.1:55938\",\"creationTime\":1517298838294,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2},{\"connectionID\":\"c515bc06\",\"clientAddress\":\"/127.0.0.1:55936\",\"creationTime\":1517298837454,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":0},{\"connectionID\":\"b9a9153f-0592-11e8-80ff-54ee7547c83e\",\"clientAddress\":\"invm:0\",\"creationTime\":1517298837312,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":0},{\"connectionID\":\"fe42578a\",\"clientAddress\":\"/127.0.0.1:55944\",\"creationTime\":1517298838495,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2},{\"connectionID\":\"cde89186\",\"clientAddress\":\"/127.0.0.1:55940\",\"creationTime\":1517298838493,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2},{\"connectionID\":\"480099e7\",\"clientAddress\":\"/127.0.0.1:55942\",\"creationTime\":1517298838495,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2}]"
> {noformat}
> This is compatibility issue, as some scripts may depend on missing attributes. Customer's tooling which used to work with 7.1 may not work now.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month