[JBoss JIRA] (WFLY-10043) [Artemis 2.x Upgrade] Last value queues do not work
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10043?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10043:
------------------------------------
[~martyn-taylor] This looks to be a regression against Artemis 1.5
[~mstyk] The test sends 10 messages and then perform 2 checks:
* that there is only 1 message in the queue (on the broker side)
* that the receiver only gets 1 message
If you still have some logs, could you please tell us which check is failing?
> [Artemis 2.x Upgrade] Last value queues do not work
> ---------------------------------------------------
>
> Key: WFLY-10043
> URL: https://issues.jboss.org/browse/WFLY-10043
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq
>
> Last value queues are not working as expected.
> # Set {{last-value-queue="true"}} for an address settings {{#}}
> # Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
> # Receiver receives 10 messages. (it is expected to receive the single message)
> This looks like broker related regression against Artemis 1.5.
> Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10043) [Artemis 2.x Upgrade] Last value queues do not work
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10043?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10043:
-------------------------------
Labels: activemq (was: )
> [Artemis 2.x Upgrade] Last value queues do not work
> ---------------------------------------------------
>
> Key: WFLY-10043
> URL: https://issues.jboss.org/browse/WFLY-10043
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq
>
> Last value queues are not working as expected.
> # Set {{last-value-queue="true"}} for an address settings {{#}}
> # Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
> # Receiver receives 10 messages. (it is expected to receive the single message)
> This looks like broker related regression against Artemis 1.5.
> Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10043) [Artemis 2.x Upgrade] Last value queues do not work
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFLY-10043?page=com.atlassian.jira.plugin... ]
Martin Styk updated WFLY-10043:
-------------------------------
Priority: Blocker (was: Major)
> [Artemis 2.x Upgrade] Last value queues do not work
> ---------------------------------------------------
>
> Key: WFLY-10043
> URL: https://issues.jboss.org/browse/WFLY-10043
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Last value queues are not working as expected.
> # Set {{last-value-queue="true"}} for an address settings {{#}}
> # Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
> # Receiver receives 10 messages. (it is expected to receive the single message)
> This looks like broker related regression against Artemis 1.5.
> Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10043) [Artemis 2.x Upgrade] Last value queues do not work
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFLY-10043?page=com.atlassian.jira.plugin... ]
Martin Styk updated WFLY-10043:
-------------------------------
Steps to Reproduce:
{noformat}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
groovy -DEAP_ZIP_URL=<CURRENT_DIST_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=LastValueQueuesTestCase#lastValueQueueTest -Deap7.org.jboss.qa.hornetq.apps.clients.version=<CLIENT_VERSION> | tee log
{noformat}
> [Artemis 2.x Upgrade] Last value queues do not work
> ---------------------------------------------------
>
> Key: WFLY-10043
> URL: https://issues.jboss.org/browse/WFLY-10043
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
>
> Last value queues are not working as expected.
> # Set {{last-value-queue="true"}} for an address settings {{#}}
> # Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
> # Receiver receives 10 messages. (it is expected to receive the single message)
> This looks like broker related regression against Artemis 1.5.
> Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10043) [Artemis 2.x Upgrade] Last value queues do not work
by Martin Styk (JIRA)
Martin Styk created WFLY-10043:
----------------------------------
Summary: [Artemis 2.x Upgrade] Last value queues do not work
Key: WFLY-10043
URL: https://issues.jboss.org/browse/WFLY-10043
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Martin Styk
Assignee: Jeff Mesnil
Last value queues are not working as expected.
# Set {{last-value-queue="true"}} for an address settings {{#}}
# Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
# Receiver receives 10 messages. (it is expected to receive the single message)
This looks like broker related regression against Artemis 1.5.
Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10003) Client is not able to create queues
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10003?page=com.atlassian.jira.plugin... ]
Miroslav Novak resolved WFLY-10003.
-----------------------------------
Resolution: Done
Setting as resolved as this is working with latest changes in Jeff's branch. See comment above.
> Client is not able to create queues
> -----------------------------------
>
> Key: WFLY-10003
> URL: https://issues.jboss.org/browse/WFLY-10003
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Labels: feature-branch-blocker
>
> Client is not able to create queues.
> Following operations fail:
> * {{javax.jms.session.createTemporaryQueue()}}
> * {{org.apache.activemq.artemis.api,core.client.createQueue()}}
> Server logs:
> {noformat}
> 12:29:55,538 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (default I/O-7) RemotingConnectionID=461fd762 handling packet PACKET(CreateQueueMessage)[type=34, channelID=11, packetObject=CreateQueueMessage, address=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, queueName=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, filterString=null, durable=false, temporary=true]
> 12:29:55,538 TRACE [org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler] (Thread-13 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@7d7bc58e)) ServerSessionPacketHandler::handlePacket,PACKET(CreateQueueMessage)[type=34, channelID=11, packetObject=CreateQueueMessage, address=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, queueName=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, filterString=null, durable=false, temporary=true]
> 12:29:55,550 DEBUG [org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler] (Thread-13 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@7d7bc58e)) Sending exception to client: ActiveMQAddressDoesNotExistException[errorType=ADDRESS_DOES_NOT_EXIST message=AMQ119203: Address Does Not Exist: jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2747) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:628) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:556) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:346) [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:1149) [rt.jar:1.8.0_161]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161]
> at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> {noformat}
> Client recieves following exception
> {noformat}
> javax.jms.JMSException: AMQ119203: Address Does Not Exist: jms.tempqueue.bb5dea5c-dadd-42ef-bd3d-e0da42264d41, code:GENERIC_EXCEPTION
> 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.createQueue(ActiveMQSessionContext.java:572)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:1551)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createTemporaryQueue(ClientSessionImpl.java:299)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createTemporaryQueue(ActiveMQSession.java:812)
> {noformat}
> This is broker related issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10042) Elytron tests fail intermittently
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-10042:
-------------------------------------
Summary: Elytron tests fail intermittently
Key: WFLY-10042
URL: https://issues.jboss.org/browse/WFLY-10042
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Stuart Douglas
Assignee: Darran Lofthouse
The JMX MBean server service does not have correct dependencies set on the security domain, and as a result unregistering the Arquillian MBean can fail on reload.
If this happen all subsequent tests will fail as the Arquillian service will not start correctly.
An example run is at: https://ci.wildfly.org/viewLog.html?buildId=89151&buildTypeId=WFPR&tab=bu...
{code}
2018-02-12 09:31:55,112 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 31) WFLYUT0022: Unregistered web context: '/chained-principal-transformer-transform-transformed' from server 'default-server'
2018-02-12 09:31:55,118 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment chained-principal-transformer-transform-transformed.war (runtime-name: chained-principal-transformer-transform-transformed.war) in 6ms
2018-02-12 09:31:55,129 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /store/work/tc-work/9ccd5e119c4a65d0/testsuite/integration/elytron/target/wildfly/standalone/data/content/7b/30341090e956f73f2066f8e357380151a337e8/content
2018-02-12 09:31:55,129 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "chained-principal-transformer-transform-transformed.war" (runtime-name: "chained-principal-transformer-transform-transformed.war")
2018-02-12 09:31:55,563 ERROR [org.jboss.as.arquillian] (MSC service thread 1-8) Cannot stop Arquillian Test Runner: java.lang.IllegalStateException
at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:60)
at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1180)
at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.isRegistered(MBeanServerAuditLogRecordFormatter.java:176)
at org.jboss.as.jmx.PluggableMBeanServerImpl.isRegistered(PluggableMBeanServerImpl.java:784)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.unregisterMBean(JMXTestRunner.java:109)
at org.jboss.as.arquillian.service.ArquillianService.stop(ArquillianService.java:96)
at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1767)
at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1740)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1527)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3302) Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3302?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-3302.
--------------------------------------
Fix Version/s: 4.0.0.Final
Assignee: David Lloyd
Resolution: Done
Thanks [~dmlloyd]. I'm going to resolve this against 4.0.0.Final then, since as you say we're not seeing the testsuite failures any more.
> Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-3302
> URL: https://issues.jboss.org/browse/WFCORE-3302
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: David Lloyd
> Fix For: 4.0.0.Final
>
>
> This bug is about problems in WF Core management tests. I believe it exposes a flaw in how remoting handles server sockets, but AFAIK there is no impact on WF Core remoting server sockets.
> Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet:
> {code}
> java.lang.RuntimeException: java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92)
> at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88)
> at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94)
> at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346)
> {code}
> These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests.
> I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method.
> The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens:
> {code}
> "XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307)
> - locked <0xc0d> (a java.lang.Object)
> at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229)
> at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149)
> - locked <0xc38> (a java.util.HashSet)
> at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl)
> - locked <0xc39> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc3a> (a sun.nio.ch.Util$2)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:519)
> {code}
> That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket.
> I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed.
> I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month