[jira] [Created] (ARTEMIS-1786) DatabaseStorageConfiguration cannot be configured via system properties
Erich Duda created ARTEMIS-1786:
---
Summary: DatabaseStorageConfiguration cannot be configured via
system properties
Key: ARTEMIS-1786
URL: https://issues.apache.org/jira/browse/ARTEMIS-1786
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.5.0
Reporter: Erich Duda
{{ConfigurationImpl}} class has method \[1\] which parses system properties.
This enables to define the parameters using the system properties. However
{{DatabaseStorageConfiguration}} class doesn't have such feature and thus these
parameters cannot be defined by system properties.
To be consistent, parameters defined in DatabaseStorageConfiguration should be
configurable via system properties as well.
\[1\]
https://github.com/apache/activemq-artemis/blob/eec10994720abca9b9b19d09604924083a35d3ea/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/impl/ConfigurationImpl.java#L332
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1275) AMQ142032: Error reading journal file arises in scenarios when server is killed during journal compacting
[
https://issues.apache.org/jira/browse/ARTEMIS-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda closed ARTEMIS-1275.
---
Resolution: Duplicate
[~jbertram] This issue was already solved. It seems that for the PR the new
Artemis issue was created - ARTEMIS-1288. I am closing this as duplicate.
> AMQ142032: Error reading journal file arises in scenarios when server is
> killed during journal compacting
> -
>
> Key: ARTEMIS-1275
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1275
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
>Priority: Major
>
> In test scenarios where Artemis is killed during journal compacting it may
> happen that backup fails to load the journal.
> You can see the same exception even if you copy the corrupted journal in
> attachment into the fresh EAP installation and run the server with the
> standalone-full-ha profile.
> The stack trace of the exception \[1\] shows that the error arises when
> Backup reads JournalCompactor control file. In this case the Live only
> created the file but it didn't write any record to it. The Backup doesn't
> expect that the file could have 0 length.
> \[1\]
> {code}
> 15:32:43,529 WARN [org.apache.activemq.artemis.journal] (AMQ119000:
> Activation for server
> ActiveMQServerImpl::serverUUID=4b1f5a18-2c49-11e7-9fdb-001b217d6d93)
> AMQ142032: Error reading journal file: java.lang.Il
> legalArgumentException
> at java.nio.Buffer.position(Buffer.java:244) [rt.jar:1.8.0_121]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:418)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalCompactor.readControlFile(JournalCompactor.java:79)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.checkControlFile(JournalImpl.java:2720)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1666)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1326)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1310)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(AbstractJournalStorageManager.java:837)
> [artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redh
> at-1]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2213)
> [artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2067)
> [artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:90)
> [artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2491)
> [artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> 15:32:43,530 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000:
> Activation for server
> ActiveMQServerImpl::serverUUID=4b1f5a18-2c49-11e7-9fdb-001b217d6d93)
> AMQ224000: Failure in initialisation: java.lang
> .Exception
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:702)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalCompactor.readControlFile(JournalCompactor.java:79)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.checkControlFile(JournalImpl.java:2720)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1666)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1326)
> [artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
> at
> org.apache.activemq.artemis.core.journal.impl.J
[jira] [Resolved] (ARTEMIS-1506) Synchronization issue during failover in ClientSessionImpl
[
https://issues.apache.org/jira/browse/ARTEMIS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1506.
-
Resolution: Fixed
Fix Version/s: 2.5.0
> Synchronization issue during failover in ClientSessionImpl
> --
>
> Key: ARTEMIS-1506
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1506
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.3.0
>Reporter: Erich Duda
> Fix For: 2.5.0
>
>
> This issue was hit in test {{MultiThreadRandomReattachTest}}. There are
> several client's threads doing some work, while connection fail is simulated.
> The test expects that all threads finish without exceptions.
> This issue causes that some client's threads sometime fail with an exception
> {{AMQ119014: Timed out after waiting 30,000 ms for response when sending
> packet XXX}}.
> I found out that the mentioned exception is caused by temporary deadlock
> during doing failover on client's side. These two threads block each other.
> {code}
> "Thread-7" Id=29 TIMED_WAITING on
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@1d03220
> at sun.misc.Unsafe.park(Native Method)
> - waiting on
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@1d03220
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
> at
> org.apache.activemq.artemis.utils.ConcurrentUtil.await(ConcurrentUtil.java:37)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:256)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:283)
> - locked java.lang.Object@938196
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:229)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendProducerCreditsMessage(ActiveMQSessionContext.java:421)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.sendProducerCreditsMessage(ClientSessionImpl.java:1342)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.requestCredits(ClientProducerCreditsImpl.java:209)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.checkCredits(ClientProducerCreditsImpl.java:204)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.init(ClientProducerCreditsImpl.java:71)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerCreditManagerImpl.getCredits(ClientProducerCreditManagerImpl.java:79)
> - locked
> org.apache.activemq.artemis.core.client.impl.ClientProducerCreditManagerImpl@f7a5dc
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.getCredits(ClientSessionImpl.java:1347)
> - locked
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl@10867c8
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.(ClientProducerImpl.java:102)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateProducer(ClientSessionImpl.java:1817)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createProducer(ClientSessionImpl.java:740)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createProducer(ClientSessionImpl.java:730)
> at
> org.apache.activemq.artemis.tests.integration.cluster.reattach.MultiThreadRandomReattachTestBase.doTestB(MultiThreadRandomReattachTestBase.java:398)
> at
> org.apache.activemq.artemis.tests.integration.cluster.reattach.MultiThreadRandomReattachTestBase$2.run(MultiThreadRandomReattachTestBase.java:84)
> at
> org.apache.activemq.artemis.tests.integration.cluster.reattach.MultiThreadReattachSupportTestBase$1Runner.run(MultiThreadReattachSupportTestBase.java:104)
> {code}
> {code}
> "Timer-0" Id=9 BLOCKED on
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl@10867c8 owned
> by "Thread-7" Id=29
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1206)
> - blocked on
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl@10867c8
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:771)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl
[jira] [Resolved] (ARTEMIS-1507) ActiveMQConnectionTimedOutException is thrown even though no timeout expired
[
https://issues.apache.org/jira/browse/ARTEMIS-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1507.
-
Resolution: Fixed
Fix Version/s: 2.5.0
> ActiveMQConnectionTimedOutException is thrown even though no timeout expired
>
>
> Key: ARTEMIS-1507
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1507
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.3.0
>Reporter: Erich Duda
> Fix For: 2.5.0
>
>
> This issue was hit in test {{MultiThreadRandomReattachTest}}. There are
> several client's threads doing some work, while connection fail is simulated.
> The test expects that all threads finish without exceptions.
> This issue causes that some client's threads sometime fail with an exception
> {{AMQ119014: Timed out after waiting 30,000 ms for response when sending
> packet XXX}}.
> As you can see in the following test output, the
> {{ActiveMQConnectionTimedOutException}} is thrown even though the test ran
> only few milliseconds, so the 30 seconds timeout cannot expire.
> {code}
> [main] 09:16:35,054 INFO [org.apache.activemq.artemis.core.server] #*#*#
> Starting test: testJ()...
> #test testJ
> [main] 09:16:35,056 INFO [org.apache.activemq.artemis.tests.integration]
> Beginning iteration 0
> [main] 09:16:35,056 INFO [org.apache.activemq.artemis.core.server]
> AMQ221000: live Message Broker is starting with configuration Broker
> Configuration
> (clustered=false,journalDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/journal0-L,bindingsDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/bindings0-L,largeMessagesDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/large-msg0-L,pagingDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/page0-L)
> [main] 09:16:35,056 INFO [org.apache.activemq.artemis.core.server]
> AMQ221043: Protocol module found: [artemis-server]. Adding protocol support
> for: CORE
> [main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server]
> AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol
> support for: AMQP
> [main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server]
> AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol
> support for: STOMP
> [main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server]
> AMQ221043: Protocol module found: [artemis-openwire-protocol]. Adding
> protocol support for: OPENWIRE
> [main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server]
> AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol
> support for: HORNETQ
> [main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server]
> AMQ221043: Protocol module found: [artemis-mqtt-protocol]. Adding protocol
> support for: MQTT
> [main] 09:16:35,064 INFO [org.apache.activemq.artemis.core.server]
> AMQ221007: Server is now live
> [main] 09:16:35,064 INFO [org.apache.activemq.artemis.core.server]
> AMQ221001: Apache ActiveMQ Artemis Message Broker version 2.4.0-SNAPSHOT
> [localhost, nodeID=376dc7b0-c099-11e7-a996-fa163ef1f361]
> [Timer-10] 09:16:35,623 INFO [org.apache.activemq.artemis.tests.integration]
> ** Failing connection
> [Timer-10] 09:16:35,623 WARN [org.apache.activemq.artemis.core.client]
> AMQ212037: Connection failure has been detected: blah [code=NOT_CONNECTED]
> [Timer-10] 09:16:35,628 INFO [org.apache.activemq.artemis.tests.integration]
> ** Fail complete
> [main] 09:16:35,640 INFO [org.apache.activemq.artemis.core.server]
> AMQ221002: Apache ActiveMQ Artemis Message Broker version 2.4.0-SNAPSHOT
> [376dc7b0-c099-11e7-a996-fa163ef1f361] stopped, uptime 0.584 seconds
> [main] 09:16:35,704 INFO [org.apache.activemq.artemis.tests.integration]
> Beginning iteration 1
> [main] 09:16:35,706 INFO [org.apache.activemq.artemis.core.server]
> AMQ221000: live Message Broker is starting with configuration Broker
> Configuration
> (clustered=false,journalDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/journal0-L,bindingsDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/bindings0-L,largeMessagesDirectory=/home/hudson/hud
[jira] [Updated] (ARTEMIS-1507) ActiveMQConnectionTimedOutException is thrown even though no timeout expired
[
https://issues.apache.org/jira/browse/ARTEMIS-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-1507:
Description:
This issue was hit in test {{MultiThreadRandomReattachTest}}. There are several
client's threads doing some work, while connection fail is simulated. The test
expects that all threads finish without exceptions.
This issue causes that some client's threads sometime fail with an exception
{{AMQ119014: Timed out after waiting 30,000 ms for response when sending packet
XXX}}.
As you can see in the following test output, the
{{ActiveMQConnectionTimedOutException}} is thrown even though the test ran only
few milliseconds, so the 30 seconds timeout cannot expire.
{code}
[main] 09:16:35,054 INFO [org.apache.activemq.artemis.core.server] #*#*#
Starting test: testJ()...
#test testJ
[main] 09:16:35,056 INFO [org.apache.activemq.artemis.tests.integration]
Beginning iteration 0
[main] 09:16:35,056 INFO [org.apache.activemq.artemis.core.server] AMQ221000:
live Message Broker is starting with configuration Broker Configuration
(clustered=false,journalDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/journal0-L,bindingsDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/bindings0-L,largeMessagesDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/large-msg0-L,pagingDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/page0-L)
[main] 09:16:35,056 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-server]. Adding protocol support for: CORE
[main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-amqp-protocol]. Adding protocol support for:
AMQP
[main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-stomp-protocol]. Adding protocol support for:
STOMP
[main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-openwire-protocol]. Adding protocol support
for: OPENWIRE
[main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for:
HORNETQ
[main] 09:16:35,057 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for:
MQTT
[main] 09:16:35,064 INFO [org.apache.activemq.artemis.core.server] AMQ221007:
Server is now live
[main] 09:16:35,064 INFO [org.apache.activemq.artemis.core.server] AMQ221001:
Apache ActiveMQ Artemis Message Broker version 2.4.0-SNAPSHOT [localhost,
nodeID=376dc7b0-c099-11e7-a996-fa163ef1f361]
[Timer-10] 09:16:35,623 INFO [org.apache.activemq.artemis.tests.integration]
** Failing connection
[Timer-10] 09:16:35,623 WARN [org.apache.activemq.artemis.core.client]
AMQ212037: Connection failure has been detected: blah [code=NOT_CONNECTED]
[Timer-10] 09:16:35,628 INFO [org.apache.activemq.artemis.tests.integration]
** Fail complete
[main] 09:16:35,640 INFO [org.apache.activemq.artemis.core.server] AMQ221002:
Apache ActiveMQ Artemis Message Broker version 2.4.0-SNAPSHOT
[376dc7b0-c099-11e7-a996-fa163ef1f361] stopped, uptime 0.584 seconds
[main] 09:16:35,704 INFO [org.apache.activemq.artemis.tests.integration]
Beginning iteration 1
[main] 09:16:35,706 INFO [org.apache.activemq.artemis.core.server] AMQ221000:
live Message Broker is starting with configuration Broker Configuration
(clustered=false,journalDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/journal0-L,bindingsDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/bindings0-L,largeMessagesDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/large-msg0-L,pagingDirectory=/home/hudson/hudson_workspace/workspace/artemis-project-testsuite-rhel-eduda/b87e4e55/tests/integration-tests/./target/tmp/junit6436722967996899345/page0-L)
[main] 09:16:35,706 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-server]. Adding protocol support for: CORE
[main] 09:16:35,707 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-amqp-protocol]. Adding prot
[jira] [Created] (ARTEMIS-1507) ActiveMQConnectionTimedOutException is thrown even though no timeout expired
Erich Duda created ARTEMIS-1507:
---
Summary: ActiveMQConnectionTimedOutException is thrown even though
no timeout expired
Key: ARTEMIS-1507
URL: https://issues.apache.org/jira/browse/ARTEMIS-1507
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.3.0
Reporter: Erich Duda
This issue was hit in test {{MultiThreadRandomReattachTest}}. There are several
client's threads doing some work, while connection fail is simulated. The test
expects that all threads finish without exceptions.
This issue causes that some client's threads sometime fail with an exception
{{AMQ119014: Timed out after waiting 30,000 ms for response when sending packet
XXX}}.
As you can see in the following test output, the
{{ActiveMQConnectionTimedOutException}} is thrown even though the test ran only
few milliseconds, so the 30 seconds timeout cannot expire.
There is an issue in {{ChannelImpl::sendBlocking}} method.
{code:java}
while (!closed && (response == null || (response.getType() !=
PacketImpl.EXCEPTION && response.getType() != expectedPacket)) && toWait > 0) {
try {
sendCondition.await(toWait, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
throw new ActiveMQInterruptedException(e);
}
if (response != null && response.getType() != PacketImpl.EXCEPTION &&
response.getType() != expectedPacket) {
ActiveMQClientLogger.LOGGER.packetOutOfOrder(response, new
Exception("trace"));
}
if (closed) {
break;
}
final long now = System.currentTimeMillis();
toWait -= now - start;
start = now;
}
if (response == null) {
throw
ActiveMQClientMessageBundle.BUNDLE.timedOutSendingPacket(connection.getBlockingCallTimeout(),
packet.getType());
}
{code}
bq. When waiting upon a Condition, a "spurious wakeup" is permitted to occur,
in general, as a concession to the underlying platform semantics. This has
little practical impact on most application programs as a Condition should
always be waited upon in a loop, testing the state predicate that is being
waited for. An implementation is free to remove the possibility of spurious
wakeups but it is recommended that applications programmers always assume that
they can occur and so always wait in a loop. \[1\]
\[1\]
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html
As it is stated in the JDK API documentation, the {{sendCondition.await}} can
"spuriously wakes up" so in the body of while cycle it should be checked the
state of conditions to which the thread waits.
If the thread wakes up and the channel is closed, the thread jumps out from the
while cycle, but after the cycle there is no check if the timeout expired or
not. The first check is whether response is null or not. In this case the
response is null so the timed out exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1506) Synchronization issue during failover in ClientSessionImpl
Erich Duda created ARTEMIS-1506:
---
Summary: Synchronization issue during failover in ClientSessionImpl
Key: ARTEMIS-1506
URL: https://issues.apache.org/jira/browse/ARTEMIS-1506
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.3.0
Reporter: Erich Duda
This issue was hit in test {{MultiThreadRandomReattachTest}}. There are several
client's threads doing some work, while connection fail is simulated. The test
expects that all threads finish without exceptions.
This issue causes that some client's threads sometime fail with an exception
{{AMQ119014: Timed out after waiting 30,000 ms for response when sending packet
XXX}}.
I found out that the mentioned exception is caused by temporary deadlock during
doing failover on client's side. These two threads block each other.
{code}
"Thread-7" Id=29 TIMED_WAITING on
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@1d03220
at sun.misc.Unsafe.park(Native Method)
- waiting on
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@1d03220
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
at
org.apache.activemq.artemis.utils.ConcurrentUtil.await(ConcurrentUtil.java:37)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:256)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:283)
- locked java.lang.Object@938196
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:229)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendProducerCreditsMessage(ActiveMQSessionContext.java:421)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.sendProducerCreditsMessage(ClientSessionImpl.java:1342)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.requestCredits(ClientProducerCreditsImpl.java:209)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.checkCredits(ClientProducerCreditsImpl.java:204)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.init(ClientProducerCreditsImpl.java:71)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerCreditManagerImpl.getCredits(ClientProducerCreditManagerImpl.java:79)
- locked
org.apache.activemq.artemis.core.client.impl.ClientProducerCreditManagerImpl@f7a5dc
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.getCredits(ClientSessionImpl.java:1347)
- locked
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl@10867c8
at
org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.(ClientProducerImpl.java:102)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateProducer(ClientSessionImpl.java:1817)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createProducer(ClientSessionImpl.java:740)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createProducer(ClientSessionImpl.java:730)
at
org.apache.activemq.artemis.tests.integration.cluster.reattach.MultiThreadRandomReattachTestBase.doTestB(MultiThreadRandomReattachTestBase.java:398)
at
org.apache.activemq.artemis.tests.integration.cluster.reattach.MultiThreadRandomReattachTestBase$2.run(MultiThreadRandomReattachTestBase.java:84)
at
org.apache.activemq.artemis.tests.integration.cluster.reattach.MultiThreadReattachSupportTestBase$1Runner.run(MultiThreadReattachSupportTestBase.java:104)
{code}
{code}
"Timer-0" Id=9 BLOCKED on
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl@10867c8 owned by
"Thread-7" Id=29
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1206)
- blocked on
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl@10867c8
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:771)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$600(ClientSessionFactoryImpl.java:72)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:11
[jira] [Resolved] (ARTEMIS-1485) ActiveMQTestBase.threadDump should print information about locks and deadlocks
[
https://issues.apache.org/jira/browse/ARTEMIS-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1485.
-
Resolution: Fixed
Fix Version/s: 2.4.0
> ActiveMQTestBase.threadDump should print information about locks and deadlocks
> --
>
> Key: ARTEMIS-1485
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1485
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Erich Duda
> Fix For: 2.4.0
>
>
> {{ActiveMQTestBase}} contains method for printing thread dump of current JVM.
> This method is used in the test suite for checking state of threads when
> something goes wrong in a test. Current implementation does not print
> information about locks and deadlocks. It would be nice to have this
> information in the thread dump.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1485) ActiveMQTestBase.threadDump should print information about locks and deadlocks
Erich Duda created ARTEMIS-1485:
---
Summary: ActiveMQTestBase.threadDump should print information
about locks and deadlocks
Key: ARTEMIS-1485
URL: https://issues.apache.org/jira/browse/ARTEMIS-1485
Project: ActiveMQ Artemis
Issue Type: Improvement
Affects Versions: 2.3.0
Reporter: Erich Duda
{{ActiveMQTestBase}} contains method for printing thread dump of current JVM.
This method is used in the test suite for checking state of threads when
something goes wrong in a test. Current implementation does not print
information about locks and deadlocks. It would be nice to have this
information in the thread dump.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1484) Live's topology update may be ignored
Erich Duda created ARTEMIS-1484:
---
Summary: Live's topology update may be ignored
Key: ARTEMIS-1484
URL: https://issues.apache.org/jira/browse/ARTEMIS-1484
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.3.0
Reporter: Erich Duda
In tests based on {{MultiServerTestBase}} it sometimes happens that after all
servers are started, the check waitForTopology fails with the following error.
{code}
Timed out waiting for cluster topology of live=5,backup=5 (received live=4,
backup=5) topology = topology on
Topology@5884a914[owner=ClusterConnectionImpl@405215542[nodeUUID=bbbae377-ba40-11e7-aff3-fa163e312a80,
connector=TransportConfiguration(name=bbbabc66-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=0, address=cluster-queues,
server=ActiveMQServerImpl::BridgeFailoverTest/Live(0)]]:
bbd79349-ba40-11e7-aff3-fa163e312a80 => TopologyMember[id =
bbd79349-ba40-11e7-aff3-fa163e312a80,
connector=Pair[a=TransportConfiguration(name=bbd79348-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=1,
b=TransportConfiguration(name=bbd79353-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=6], backupGroupName=null, scaleDownGroupName=null]
bbd7935b-ba40-11e7-aff3-fa163e312a80 => TopologyMember[id =
bbd7935b-ba40-11e7-aff3-fa163e312a80,
connector=Pair[a=TransportConfiguration(name=bbd7935a-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=2,
b=TransportConfiguration(name=bbd7ba75-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=7], backupGroupName=null, scaleDownGroupName=null]
bbbae377-ba40-11e7-aff3-fa163e312a80 => TopologyMember[id =
bbbae377-ba40-11e7-aff3-fa163e312a80,
connector=Pair[a=TransportConfiguration(name=bbbabc66-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=0,
b=TransportConfiguration(name=bbd76c31-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=5], backupGroupName=null, scaleDownGroupName=null]
bbd7ba8f-ba40-11e7-aff3-fa163e312a80 => TopologyMember[id =
bbd7ba8f-ba40-11e7-aff3-fa163e312a80, connector=Pair[a=null,
b=TransportConfiguration(name=bbd7ba99-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=9], backupGroupName=null, scaleDownGroupName=null]
bbd7ba7d-ba40-11e7-aff3-fa163e312a80 => TopologyMember[id =
bbd7ba7d-ba40-11e7-aff3-fa163e312a80,
connector=Pair[a=TransportConfiguration(name=bbd7ba7c-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=3,
b=TransportConfiguration(name=bbd7ba87-ba40-11e7-aff3-fa163e312a80,
factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
?serverId=8], backupGroupName=null, scaleDownGroupName=null]
nodes=9 members=5)
{code}
I dug into this and found out that in some certain cases Live's topology update
message has older event ID than Backup's update message and it is also received
later. In these cases the Live's message is ignored, because it doesn't meet
the condition as it is shown below in the code snippet.
I think if the current node has no connector to Live, it shouldn't ignore
topology update from Live even if it is older than the current record.
{code:java}
public boolean updateMember(final long uniqueEventID, final String nodeId,
final TopologyMemberImpl memberInput) {
if (uniqueEventID > currentMember.getUniqueEventID()) {
...
}
/*
* always add the backup, better to try to reconnect to something that's not
there then to
* not know about it at all
*/
if (currentMember.getBackup() == null && memberInput.getBackup() != null) {
currentMember.setBackup(memberInput.getBackup());
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1368) Artemis gets to state when it doesn't respond to producer
Erich Duda created ARTEMIS-1368:
---
Summary: Artemis gets to state when it doesn't respond to producer
Key: ARTEMIS-1368
URL: https://issues.apache.org/jira/browse/ARTEMIS-1368
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.2.0, 1.5.5
Reporter: Erich Duda
*Scenario*
* There are two servers configured in colocated replicated HA
* There are two producers. Each one sends messages on different server to
InQueue.
* There is MDB on server 2 which resends messages from InQueue to OutQueue
* During the resending of messages, server 2 is restarted.
* After all messages are resent, receiver is connected to server 1 and it
receives all messages.
*Expectation:* All messages sent by producers to InQueue are received by
receiver from OutQueue.
*Reality:* After the restart of server 2, the server 1 gets into the state when
it stops to respond to the producer. Producer sends a bulk of messages which
are marked as duplicates by server, but the exception packet is not sent to
producer. See below for more detailed description what is happening on the
server.
*Customer impact:* Artemis may get into the state when it is not able to work
properly. This can lead to unavailability of service.
This is *regression* against *7.0.z*.
The issue wasn't reported earlier, because the test failed due to JBEAP-7968
before 7.1.0.ER3.
*Detail description of what happened on server*
I looked at the server traces to see what happened when server received session
commit packet from producer. Based on the traces, the server behaved correctly
and it even scheduled to send response packet with the duplication exception.
{code}
06:17:28,206 TRACE
[org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler]
(Thread-6
(ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@37386953))
ServerSessio
nPacketHandler::scheduling response::PACKET(ActiveMQExceptionMessage)[type=20,
channelID=0, packetObject=ActiveMQExceptionMessage, exception=
ActiveMQDuplicateIdException[errorType=DUPLICATE_ID_REJECTED message=
Duplicate message detected - message will not be routed. Message
information:LargeServerMessage[messageID=7034,durable=true,userID=f3b4e359-7834-11e7-bd40-001b217d6dc3,priority=4,
timestamp=Thu Aug 03 06:17:28 E
DT 2017,expiration=0, durable=true,
address=jms.queue.InQueue,properties=TypedProperties[__AMQ_CID=829bf1a6-7834-11e7-bd40-001b217d6dc3,count=1699,counter=1700,_AMQ_DUPL_ID=1bfb61bf-2eca-4f33-9723-5998dcd84ed515
01755380929,_AMQ_LARGE_SIZE=409615,color=RED]]@971671687]]
{code}
The problem is that after this event, I cannot find message which would say
that the packet was sent. As you can see in code snippet below, the "scheduling
response" says that it was registered IOCallback, which will send the packet
once it is triggered.
{code:java}
private void sendResponse(final Packet confirmPacket,
final Packet response,
final boolean flush,
final boolean closeChannel) {
if (logger.isTraceEnabled()) {
logger.trace("ServerSessionPacketHandler::scheduling response::" +
response);
}
storageManager.afterCompleteOperations(new IOCallback() {
@Override
public void onError(final int errorCode, final String errorMessage) {
ActiveMQServerLogger.LOGGER.errorProcessingIOCallback(errorCode,
errorMessage);
ActiveMQExceptionMessage exceptionMessage = new
ActiveMQExceptionMessage(ActiveMQExceptionType.createException(errorCode,
errorMessage));
doConfirmAndResponse(confirmPacket, exceptionMessage, flush,
closeChannel);
if (logger.isTraceEnabled()) {
logger.trace("ServerSessionPacketHandler::exception response
sent::" + exceptionMessage);
}
}
@Override
public void done() {
if (logger.isTraceEnabled()) {
logger.trace("ServerSessionPacketHandler::regular response
sent::" + response);
}
doConfirmAndResponse(confirmPacket, response, flush, closeChannel);
}
});
}
{code}
It is odd that the callback wasn't never triggered. This assumption confirms
the warning printed at stopping of the server. In the OperationContext, there
were still some callbacks which weren't triggered.
{code}
06:22:41,377 WARN [org.apache.activemq.artemis.core.server] (ServerService
Thread Pool -- 124) AMQ222105: Could not finish context execution in 10
seconds: java.lang.Exception: warning
at
org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.waitContextCompletion(ServerSessionImpl.java:1141)
[artemis-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.
[jira] [Resolved] (ARTEMIS-1265) JaCoCo profile for getting code coverage report
[ https://issues.apache.org/jira/browse/ARTEMIS-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erich Duda resolved ARTEMIS-1265. - Resolution: Fixed Fix Version/s: 2.2.0 1.5.6 > JaCoCo profile for getting code coverage report > --- > > Key: ARTEMIS-1265 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1265 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.5.5, 2.1.0 >Reporter: Erich Duda > Fix For: 1.5.6, 2.2.0 > > > JaCoCo \[1\] is a free code coverage library for Java. Code coverage is > useful metric for revealing untested areas of code. > \[1\] www.jacoco.org/jacoco/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ARTEMIS-1223) OutOfDirectMemoryError raised from TimedBuffer
[
https://issues.apache.org/jira/browse/ARTEMIS-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089380#comment-16089380
]
Erich Duda commented on ARTEMIS-1223:
-
[~pwjenkins] 2.2.0 release date is discussing in the e-mail thread \[1\].
\[1\]
http://activemq.2283324.n4.nabble.com/HEADS-UP-1-5-6-and-2-2-0-release-in-1-or-2-Weeks-td4728007.html
> OutOfDirectMemoryError raised from TimedBuffer
> --
>
> Key: ARTEMIS-1223
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1223
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
> Environment: IBM JDK
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp20-20161019_02(SR3 FP20))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20161013_322271 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20161013_1635_B322271
> JIT - tr.r14.java.green_20161011_125790
> GC - R28_Java8_SR3_20161013_1635_B322271_CMPRSS
> J9CL - 20161013_322271)
> JCL - 20161018_01 based on Oracle jdk8u111-b14
>Reporter: Erich Duda
>Priority: Minor
> Fix For: 1.5.6, 2.2.0
>
>
> I see a lot of OutOfDirectMemoryError \[1\] in Artemis test suite when it
> runs on IBM JDK. I don't see it with Oracle or OpenJDK.
> For reproducing the issue run {{LargeMessageCompressTest}} on IBM JDK.
> \[1\]
> {code}
> io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 501760
> byte(s) of direct memory (used: 66876815, max: 67108864)
> at
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
> at
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
> at
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
> at
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
> at io.netty.buffer.Unpooled.directBuffer(Unpooled.java:145)
> at
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.(TimedBuffer.java:103)
> at
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.(AbstractSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.io.aio.AIOSequentialFileFactory.(AIOSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.init(JournalStorageManager.java:136)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:217)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:103)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2014)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2151)
> at
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:517)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:465)
> at
> org.apache.activemq.artemis.tests.integration.client.LargeMessageCompressTest.testLargeMessageCompression3(LargeMessageCompressTest.java:171)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ARTEMIS-1274) MultipleProducersTest.wrongQueue fails
[
https://issues.apache.org/jira/browse/ARTEMIS-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1274.
-
Resolution: Fixed
Fix Version/s: 2.2.0
1.5.6
> MultipleProducersTest.wrongQueue fails
> --
>
> Key: ARTEMIS-1274
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1274
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
> Fix For: 1.5.6, 2.2.0
>
>
> {code}
> java.lang.AssertionError: queueOne message count expected:<5> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at
> org.apache.activemq.artemis.tests.integration.client.MultipleProducersTest.wrongQueue(MultipleProducersTest.java:149)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1275) AMQ142032: Error reading journal file arises in scenarios when server is killed during journal compacting
Erich Duda created ARTEMIS-1275:
---
Summary: AMQ142032: Error reading journal file arises in scenarios
when server is killed during journal compacting
Key: ARTEMIS-1275
URL: https://issues.apache.org/jira/browse/ARTEMIS-1275
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.1.0, 1.5.5
Reporter: Erich Duda
In test scenarios where Artemis is killed during journal compacting it may
happen that backup fails to load the journal.
You can see the same exception even if you copy the corrupted journal in
attachment into the fresh EAP installation and run the server with the
standalone-full-ha profile.
The stack trace of the exception \[1\] shows that the error arises when Backup
reads JournalCompactor control file. In this case the Live only created the
file but it didn't write any record to it. The Backup doesn't expect that the
file could have 0 length.
\[1\]
{code}
15:32:43,529 WARN [org.apache.activemq.artemis.journal] (AMQ119000: Activation
for server ActiveMQServerImpl::serverUUID=4b1f5a18-2c49-11e7-9fdb-001b217d6d93)
AMQ142032: Error reading journal file: java.lang.Il
legalArgumentException
at java.nio.Buffer.position(Buffer.java:244) [rt.jar:1.8.0_121]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:418)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalCompactor.readControlFile(JournalCompactor.java:79)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.checkControlFile(JournalImpl.java:2720)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1666)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1326)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1310)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(AbstractJournalStorageManager.java:837)
[artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redh
at-1]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2213)
[artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2067)
[artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:90)
[artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2491)
[artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
15:32:43,530 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000:
Activation for server
ActiveMQServerImpl::serverUUID=4b1f5a18-2c49-11e7-9fdb-001b217d6d93) AMQ224000:
Failure in initialisation: java.lang
.Exception
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:702)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalCompactor.readControlFile(JournalCompactor.java:79)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.checkControlFile(JournalImpl.java:2720)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1666)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1326)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1310)
[artemis-journal-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(AbstractJournalStorageManager.java:837)
[artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redh
at-1]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2213)
[artemis-server-1.5.4.003-redhat-1.jar:1.5.4.003-redhat-1]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl
[jira] [Created] (ARTEMIS-1274) MultipleProducersTest.wrongQueue fails
Erich Duda created ARTEMIS-1274:
---
Summary: MultipleProducersTest.wrongQueue fails
Key: ARTEMIS-1274
URL: https://issues.apache.org/jira/browse/ARTEMIS-1274
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.1.0, 1.5.5
Reporter: Erich Duda
{code}
java.lang.AssertionError: queueOne message count expected:<5> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at
org.apache.activemq.artemis.tests.integration.client.MultipleProducersTest.wrongQueue(MultipleProducersTest.java:149)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1265) JaCoCo profile for getting code coverage report
Erich Duda created ARTEMIS-1265: --- Summary: JaCoCo profile for getting code coverage report Key: ARTEMIS-1265 URL: https://issues.apache.org/jira/browse/ARTEMIS-1265 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.1.0, 1.5.5 Reporter: Erich Duda JaCoCo \[1\] is a free code coverage library for Java. Code coverage is useful metric for revealing untested areas of code. \[1\] www.jacoco.org/jacoco/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ARTEMIS-1256) PagingOMETest.testPageCleanup fails
[
https://issues.apache.org/jira/browse/ARTEMIS-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1256.
-
Resolution: Fixed
Fix Version/s: 2.2.0
1.5.6
> PagingOMETest.testPageCleanup fails
> ---
>
> Key: ARTEMIS-1256
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1256
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
> Fix For: 1.5.6, 2.2.0
>
>
> {code}
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.activemq.artemis.tests.extras.byteman.PagingOMETest.testPageCleanup(PagingOMETest.java:148)
> {code}
> Queue.getMessageCount does not guarantee you get accurate number of messages
> on the queue. To get precise number, the test must wait until all
> asynchronous tasks on queue are finished.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ARTEMIS-1223) OutOfDirectMemoryError raised from TimedBuffer
[
https://issues.apache.org/jira/browse/ARTEMIS-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1223.
-
Resolution: Fixed
Fix Version/s: 2.2.0
1.5.6
> OutOfDirectMemoryError raised from TimedBuffer
> --
>
> Key: ARTEMIS-1223
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1223
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
> Environment: IBM JDK
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp20-20161019_02(SR3 FP20))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20161013_322271 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20161013_1635_B322271
> JIT - tr.r14.java.green_20161011_125790
> GC - R28_Java8_SR3_20161013_1635_B322271_CMPRSS
> J9CL - 20161013_322271)
> JCL - 20161018_01 based on Oracle jdk8u111-b14
>Reporter: Erich Duda
>Priority: Minor
> Fix For: 1.5.6, 2.2.0
>
>
> I see a lot of OutOfDirectMemoryError \[1\] in Artemis test suite when it
> runs on IBM JDK. I don't see it with Oracle or OpenJDK.
> For reproducing the issue run {{LargeMessageCompressTest}} on IBM JDK.
> \[1\]
> {code}
> io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 501760
> byte(s) of direct memory (used: 66876815, max: 67108864)
> at
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
> at
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
> at
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
> at
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
> at io.netty.buffer.Unpooled.directBuffer(Unpooled.java:145)
> at
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.(TimedBuffer.java:103)
> at
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.(AbstractSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.io.aio.AIOSequentialFileFactory.(AIOSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.init(JournalStorageManager.java:136)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:217)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:103)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2014)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2151)
> at
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:517)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:465)
> at
> org.apache.activemq.artemis.tests.integration.client.LargeMessageCompressTest.testLargeMessageCompression3(LargeMessageCompressTest.java:171)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1256) PagingOMETest.testPageCleanup fails
Erich Duda created ARTEMIS-1256:
---
Summary: PagingOMETest.testPageCleanup fails
Key: ARTEMIS-1256
URL: https://issues.apache.org/jira/browse/ARTEMIS-1256
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.1.0, 1.5.5
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<2> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.extras.byteman.PagingOMETest.testPageCleanup(PagingOMETest.java:148)
{code}
Queue.getMessageCount does not guarantee you get accurate number of messages on
the queue. To get precise number, the test must wait until all asynchronous
tasks on queue are finished.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ARTEMIS-1250) ClusteredMessageCounterTest.testNonDurableMessageAddedWithPaging fails
[
https://issues.apache.org/jira/browse/ARTEMIS-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1250.
-
Resolution: Fixed
Fix Version/s: 2.2.0
1.5.6
> ClusteredMessageCounterTest.testNonDurableMessageAddedWithPaging fails
> --
>
> Key: ARTEMIS-1250
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1250
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
> Fix For: 1.5.6, 2.2.0
>
>
> {code}
> java.lang.AssertionError: expected:<100> but was:<99>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusteredMessageCounterTest.testMessageAddedWithPaging(ClusteredMessageCounterTest.java:143)
> at
> org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusteredMessageCounterTest.testNonDurableMessageAddedWithPaging(ClusteredMessageCounterTest.java:104)
> {code}
> Sometimes happens that the test started to send messages before a consumer is
> registered at RemoteQueueBindingImpl on server 0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1250) ClusteredMessageCounterTest.testNonDurableMessageAddedWithPaging fails
Erich Duda created ARTEMIS-1250:
---
Summary:
ClusteredMessageCounterTest.testNonDurableMessageAddedWithPaging fails
Key: ARTEMIS-1250
URL: https://issues.apache.org/jira/browse/ARTEMIS-1250
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.1.0, 1.5.5
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<100> but was:<99>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusteredMessageCounterTest.testMessageAddedWithPaging(ClusteredMessageCounterTest.java:143)
at
org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusteredMessageCounterTest.testNonDurableMessageAddedWithPaging(ClusteredMessageCounterTest.java:104)
{code}
Sometimes happens that the test started to send messages before a consumer is
registered at RemoteQueueBindingImpl on server 0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ARTEMIS-1223) OutOfDirectMemoryError raised from TimedBuffer
[
https://issues.apache.org/jira/browse/ARTEMIS-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-1223:
Priority: Minor (was: Major)
> OutOfDirectMemoryError raised from TimedBuffer
> --
>
> Key: ARTEMIS-1223
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1223
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
> Environment: IBM JDK
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp20-20161019_02(SR3 FP20))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20161013_322271 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20161013_1635_B322271
> JIT - tr.r14.java.green_20161011_125790
> GC - R28_Java8_SR3_20161013_1635_B322271_CMPRSS
> J9CL - 20161013_322271)
> JCL - 20161018_01 based on Oracle jdk8u111-b14
>Reporter: Erich Duda
>Priority: Minor
>
> I see a lot of OutOfDirectMemoryError \[1\] in Artemis test suite when it
> runs on IBM JDK. I don't see it with Oracle or OpenJDK.
> For reproducing the issue run {{LargeMessageCompressTest}} on IBM JDK.
> \[1\]
> {code}
> io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 501760
> byte(s) of direct memory (used: 66876815, max: 67108864)
> at
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
> at
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
> at
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
> at
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
> at io.netty.buffer.Unpooled.directBuffer(Unpooled.java:145)
> at
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.(TimedBuffer.java:103)
> at
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.(AbstractSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.io.aio.AIOSequentialFileFactory.(AIOSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.init(JournalStorageManager.java:136)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:217)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:103)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2014)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2151)
> at
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:517)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:465)
> at
> org.apache.activemq.artemis.tests.integration.client.LargeMessageCompressTest.testLargeMessageCompression3(LargeMessageCompressTest.java:171)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARTEMIS-1223) OutOfDirectMemoryError raised from TimedBuffer
[
https://issues.apache.org/jira/browse/ARTEMIS-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053646#comment-16053646
]
Erich Duda commented on ARTEMIS-1223:
-
[~nigro@gmail.com] thanks for your response. Since it is only test issue, I
am lowering a priority of the Jira.
> OutOfDirectMemoryError raised from TimedBuffer
> --
>
> Key: ARTEMIS-1223
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1223
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
> Environment: IBM JDK
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp20-20161019_02(SR3 FP20))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20161013_322271 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20161013_1635_B322271
> JIT - tr.r14.java.green_20161011_125790
> GC - R28_Java8_SR3_20161013_1635_B322271_CMPRSS
> J9CL - 20161013_322271)
> JCL - 20161018_01 based on Oracle jdk8u111-b14
>Reporter: Erich Duda
>
> I see a lot of OutOfDirectMemoryError \[1\] in Artemis test suite when it
> runs on IBM JDK. I don't see it with Oracle or OpenJDK.
> For reproducing the issue run {{LargeMessageCompressTest}} on IBM JDK.
> \[1\]
> {code}
> io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 501760
> byte(s) of direct memory (used: 66876815, max: 67108864)
> at
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
> at
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
> at
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
> at
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
> at io.netty.buffer.Unpooled.directBuffer(Unpooled.java:145)
> at
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.(TimedBuffer.java:103)
> at
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.(AbstractSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.io.aio.AIOSequentialFileFactory.(AIOSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.init(JournalStorageManager.java:136)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:217)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:103)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2014)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2151)
> at
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:517)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:465)
> at
> org.apache.activemq.artemis.tests.integration.client.LargeMessageCompressTest.testLargeMessageCompression3(LargeMessageCompressTest.java:171)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ARTEMIS-1208) Do not use reconnect-atempts=-1 in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1208.
-
Resolution: Fixed
Fix Version/s: 2.2.0
1.5.6
> Do not use reconnect-atempts=-1 in tests
>
>
> Key: ARTEMIS-1208
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1208
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
> Fix For: 1.5.6, 2.2.0
>
> Attachments: threaddump.txt
>
>
> If a connection to a broker is configured with parameter reconnect-atempts=-1
> and something goes wrong with the broker, the test may hang indefinitely. It
> happens in cases where the session is created in main test thread.
> Bellow you can see example of stack traces when this situation happens. Main
> thread is waiting for {{failoverLock}} which is held by Thread doing
> reconnection with reconnect-attempts=-1. See attachment for full thread dump.
> {code}
> "main" Id=1 WAITING on
> java.util.concurrent.locks.ReentrantLock$NonfairSync@6e460863 owned by
> "Thread-4 (ActiveMQ-client-global-threads)" Id=5564 (in native)
> at sun.misc.Unsafe.park(Native Method)
> - waiting on
> java.util.concurrent.locks.ReentrantLock$NonfairSync@6e460863
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:847)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:881)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1210)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:220)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:296)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.lockFailover(ClientSessionFactoryImpl.java:230)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.lockSessionCreation(ActiveMQClientProtocolManager.java:163)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:272)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:237)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1284)
> - locked java.lang.Object@18ee7eb5
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:670)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:323)
> at
> org.apache.activemq.artemis.tests.integration.cluster.failover.FailoverTest.createSession(FailoverTest.java:94)
> at
> org.apache.activemq.artemis.tests.integration.cluster.failover.FailoverTest.simpleFailover(FailoverTest.java:693)
> at
> org.apache.activemq.artemis.tests.integration.cluster.failover.FailoverTest.testFailBack(FailoverTest.java:534)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(Bloc
[jira] [Commented] (ARTEMIS-1223) OutOfDirectMemoryError raised from TimedBuffer
[
https://issues.apache.org/jira/browse/ARTEMIS-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046305#comment-16046305
]
Erich Duda commented on ARTEMIS-1223:
-
[~nigro@gmail.com] could you take a look please?
> OutOfDirectMemoryError raised from TimedBuffer
> --
>
> Key: ARTEMIS-1223
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1223
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
> Environment: IBM JDK
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp20-20161019_02(SR3 FP20))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20161013_322271 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20161013_1635_B322271
> JIT - tr.r14.java.green_20161011_125790
> GC - R28_Java8_SR3_20161013_1635_B322271_CMPRSS
> J9CL - 20161013_322271)
> JCL - 20161018_01 based on Oracle jdk8u111-b14
>Reporter: Erich Duda
>
> I see a lot of OutOfDirectMemoryError \[1\] in Artemis test suite when it
> runs on IBM JDK. I don't see it with Oracle or OpenJDK.
> For reproducing the issue run {{LargeMessageCompressTest}} on IBM JDK.
> \[1\]
> {code}
> io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 501760
> byte(s) of direct memory (used: 66876815, max: 67108864)
> at
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
> at
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
> at
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
> at
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
> at
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
> at
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
> at io.netty.buffer.Unpooled.directBuffer(Unpooled.java:145)
> at
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.(TimedBuffer.java:103)
> at
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.(AbstractSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.io.aio.AIOSequentialFileFactory.(AIOSequentialFileFactory.java:78)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.init(JournalStorageManager.java:136)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:217)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:103)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2014)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2151)
> at
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:517)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:465)
> at
> org.apache.activemq.artemis.tests.integration.client.LargeMessageCompressTest.testLargeMessageCompression3(LargeMessageCompressTest.java:171)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ARTEMIS-1223) OutOfDirectMemoryError raised from TimedBuffer
Erich Duda created ARTEMIS-1223:
---
Summary: OutOfDirectMemoryError raised from TimedBuffer
Key: ARTEMIS-1223
URL: https://issues.apache.org/jira/browse/ARTEMIS-1223
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.1.0, 1.5.5
Environment: IBM JDK
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp20-20161019_02(SR3 FP20))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
20161013_322271 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20161013_1635_B322271
JIT - tr.r14.java.green_20161011_125790
GC - R28_Java8_SR3_20161013_1635_B322271_CMPRSS
J9CL - 20161013_322271)
JCL - 20161018_01 based on Oracle jdk8u111-b14
Reporter: Erich Duda
I see a lot of OutOfDirectMemoryError \[1\] in Artemis test suite when it runs
on IBM JDK. I don't see it with Oracle or OpenJDK.
For reproducing the issue run {{LargeMessageCompressTest}} on IBM JDK.
\[1\]
{code}
io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 501760
byte(s) of direct memory (used: 66876815, max: 67108864)
at
io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
at
io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
at
io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
at
io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
at
io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
at
io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
at
io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
at
io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
at
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
at io.netty.buffer.Unpooled.directBuffer(Unpooled.java:145)
at
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.(TimedBuffer.java:103)
at
org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.(AbstractSequentialFileFactory.java:78)
at
org.apache.activemq.artemis.core.io.aio.AIOSequentialFileFactory.(AIOSequentialFileFactory.java:78)
at
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.init(JournalStorageManager.java:136)
at
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:217)
at
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:103)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2014)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2151)
at
org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:517)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:465)
at
org.apache.activemq.artemis.tests.integration.client.LargeMessageCompressTest.testLargeMessageCompression3(LargeMessageCompressTest.java:171)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ARTEMIS-1208) Do not use reconnect-atempts=-1 in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-1208:
Description:
If a connection to a broker is configured with parameter reconnect-atempts=-1
and something goes wrong with the broker, the test may hang indefinitely. It
happens in cases where the session is created in main test thread.
Bellow you can see example of stack traces when this situation happens. Main
thread is waiting for {{failoverLock}} which is held by Thread doing
reconnection with reconnect-attempts=-1. See attachment for full thread dump.
{code}
"main" Id=1 WAITING on
java.util.concurrent.locks.ReentrantLock$NonfairSync@6e460863 owned by
"Thread-4 (ActiveMQ-client-global-threads)" Id=5564 (in native)
at sun.misc.Unsafe.park(Native Method)
- waiting on
java.util.concurrent.locks.ReentrantLock$NonfairSync@6e460863
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:847)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:881)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1210)
at
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:220)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:296)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.lockFailover(ClientSessionFactoryImpl.java:230)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.lockSessionCreation(ActiveMQClientProtocolManager.java:163)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:272)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:237)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1284)
- locked java.lang.Object@18ee7eb5
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:670)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:323)
at
org.apache.activemq.artemis.tests.integration.cluster.failover.FailoverTest.createSession(FailoverTest.java:94)
at
org.apache.activemq.artemis.tests.integration.cluster.failover.FailoverTest.simpleFailover(FailoverTest.java:693)
at
org.apache.activemq.artemis.tests.integration.cluster.failover.FailoverTest.testFailBack(FailoverTest.java:534)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run
[jira] [Updated] (ARTEMIS-1208) Do not use reconnect-atempts=-1 in tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erich Duda updated ARTEMIS-1208: Attachment: threaddump.txt > Do not use reconnect-atempts=-1 in tests > > > Key: ARTEMIS-1208 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1208 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.5, 2.1.0 >Reporter: Erich Duda > Attachments: threaddump.txt > > > If a connection to a broker is configured with parameter reconnect-atempts=-1 > and something goes wrong with the broker, the test may hang indefinitely. It > happens in cases where the session is created in main test thread. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARTEMIS-1208) Do not use reconnect-atempts=-1 in tests
Erich Duda created ARTEMIS-1208: --- Summary: Do not use reconnect-atempts=-1 in tests Key: ARTEMIS-1208 URL: https://issues.apache.org/jira/browse/ARTEMIS-1208 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.1.0, 1.5.5 Reporter: Erich Duda If a connection to a broker is configured with parameter reconnect-atempts=-1 and something goes wrong with the broker, the test may hang indefinitely. It happens in cases where the session is created in main test thread. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ARTEMIS-1199) JDBCSequentialFile prints log to System.out
[
https://issues.apache.org/jira/browse/ARTEMIS-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1199.
-
Resolution: Fixed
Fix Version/s: 1.5.6
> JDBCSequentialFile prints log to System.out
> ---
>
> Key: ARTEMIS-1199
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1199
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5
>Reporter: Erich Duda
> Fix For: 1.5.6
>
>
> JDBCSequentialFile class contains {{System.out.println}} call which prints
> logging information into the system output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (ARTEMIS-1199) JDBCSequentialFile prints log to System.out
Erich Duda created ARTEMIS-1199:
---
Summary: JDBCSequentialFile prints log to System.out
Key: ARTEMIS-1199
URL: https://issues.apache.org/jira/browse/ARTEMIS-1199
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.5.5
Reporter: Erich Duda
JDBCSequentialFile class contains {{System.out.println}} call which prints
logging information into the system output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ARTEMIS-1190) Long/int type mismatch in JDBCSequentialFile.setWritePosition
[
https://issues.apache.org/jira/browse/ARTEMIS-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-1190.
-
Resolution: Fixed
Fix Version/s: 2.2.0
1.5.6
> Long/int type mismatch in JDBCSequentialFile.setWritePosition
> -
>
> Key: ARTEMIS-1190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1190
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
> Fix For: 1.5.6, 2.2.0
>
>
> In the {{JDBCSequentialFile.setWritePosition}} there is mismatch between
> types. The parameter of the method has type {{int}} but the private field has
> type {{long}}.
> {code:java}
> private long writePosition = 0;
> void setWritePosition(int writePosition) {
>this.writePosition = writePosition;
> }
> {code}
> Because of this in {{JDBCSequentialFileFactoryDriver.loadFile}} the long is
> unnecessarily retype to int.
> {code:java}
> public void loadFile(JDBCSequentialFile file) throws SQLException {
> synchronized (connection) {
>connection.setAutoCommit(false);
>readLargeObject.setLong(1, file.getId());
>try (ResultSet rs = readLargeObject.executeQuery()) {
> if (rs.next()) {
> Blob blob = rs.getBlob(1);
> if (blob != null) {
> file.setWritePosition((int) blob.length());
> } else {
> logger.warn("ERROR NO BLOB FOR FILE" + "File: " +
> file.getFileName() + " " + file.getId());
> }
> }
> connection.commit();
>} catch (SQLException e) {
> connection.rollback();
> throw e;
>}
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ARTEMIS-1190) Long/int type mismatch in JDBCSequentialFile.setWritePosition
[
https://issues.apache.org/jira/browse/ARTEMIS-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-1190:
Affects Version/s: 1.5.5
> Long/int type mismatch in JDBCSequentialFile.setWritePosition
> -
>
> Key: ARTEMIS-1190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1190
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
>
> In the {{JDBCSequentialFile.setWritePosition}} there is mismatch between
> types. The parameter of the method has type {{int}} but the private field has
> type {{long}}.
> {code:java}
> private long writePosition = 0;
> void setWritePosition(int writePosition) {
>this.writePosition = writePosition;
> }
> {code}
> Because of this in {{JDBCSequentialFileFactoryDriver.loadFile}} the long is
> unnecessarily retype to int.
> {code:java}
> public void loadFile(JDBCSequentialFile file) throws SQLException {
> synchronized (connection) {
>connection.setAutoCommit(false);
>readLargeObject.setLong(1, file.getId());
>try (ResultSet rs = readLargeObject.executeQuery()) {
> if (rs.next()) {
> Blob blob = rs.getBlob(1);
> if (blob != null) {
> file.setWritePosition((int) blob.length());
> } else {
> logger.warn("ERROR NO BLOB FOR FILE" + "File: " +
> file.getFileName() + " " + file.getId());
> }
> }
> connection.commit();
>} catch (SQLException e) {
> connection.rollback();
> throw e;
>}
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (ARTEMIS-1190) Long/int type mismatch in JDBCSequentialFile.setWritePosition
Erich Duda created ARTEMIS-1190:
---
Summary: Long/int type mismatch in
JDBCSequentialFile.setWritePosition
Key: ARTEMIS-1190
URL: https://issues.apache.org/jira/browse/ARTEMIS-1190
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.1.0
Reporter: Erich Duda
In the {{JDBCSequentialFile.setWritePosition}} there is mismatch between types.
The parameter of the method has type {{int}} but the private field has type
{{long}}.
{code:java}
private long writePosition = 0;
void setWritePosition(int writePosition) {
this.writePosition = writePosition;
}
{code}
Because of this in {{JDBCSequentialFileFactoryDriver.loadFile}} the long is
unnecessarily retype to int.
{code:java}
public void loadFile(JDBCSequentialFile file) throws SQLException {
synchronized (connection) {
connection.setAutoCommit(false);
readLargeObject.setLong(1, file.getId());
try (ResultSet rs = readLargeObject.executeQuery()) {
if (rs.next()) {
Blob blob = rs.getBlob(1);
if (blob != null) {
file.setWritePosition((int) blob.length());
} else {
logger.warn("ERROR NO BLOB FOR FILE" + "File: " +
file.getFileName() + " " + file.getId());
}
}
connection.commit();
} catch (SQLException e) {
connection.rollback();
throw e;
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-861) Artemis 1.5 compilation fails with IBM JDK
[
https://issues.apache.org/jira/browse/ARTEMIS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962478#comment-15962478
]
Erich Duda commented on ARTEMIS-861:
[~jbertram] I've tried to remove it manually and it has worked.
[~iweiss] +1 for profile
> Artemis 1.5 compilation fails with IBM JDK
> --
>
> Key: ARTEMIS-861
> URL: https://issues.apache.org/jira/browse/ARTEMIS-861
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: IBM JDK
> The issue was hit with following version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20151019_272764 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR2_20151019_2144_B272764
> JIT - tr.r14.java_20151006_102517.04
> GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS
> J9CL - 20151019_272764)
> JCL - 20151022_01 based on Oracle jdk8u65-b17
>Reporter: Erich Duda
>Priority: Critical
>
> The compilation fails in module ActiveMQ Artemis Commons with following
> exception.
> {code}
> [INFO] Compiling 11 source files to
> /home/eduda/Projects/activemq-artemis/artemis-commons/target/test-classes
> An exception has occurred in the compiler (1.9.0-internal). Please file a bug
> at the Java Bug Database (http://bugreport.java.com/bugreport/) after
> checking the database for duplicates. Include your program and the following
> diagnostic in your report. Thank you.
> java.lang.NullPointerException
> at
> com.sun.tools.javac.code.Types.isSignaturePolymorphic(Types.java:1066)
> at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2028)
> at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2253)
> at
> com.sun.tools.javac.jvm.ClassReader.readClassBuffer(ClassReader.java:2325)
> at
> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2338)
> at com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:341)
> at com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:279)
> at com.sun.tools.javac.code.ClassFinder.access$000(ClassFinder.java:72)
> at com.sun.tools.javac.code.ClassFinder$1.complete(ClassFinder.java:159)
> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:579)
> at
> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1074)
> at com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1125)
> at
> com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1051)
> at com.sun.tools.javac.code.Type$ClassType.allparams(Type.java:1073)
> at
> com.sun.tools.javac.code.Type$ClassType.isParameterized(Type.java:1086)
> at com.sun.tools.javac.code.Types.capture(Types.java:3995)
> at
> com.sun.tools.javac.comp.Resolve$MethodResultInfo.check(Resolve.java:1007)
> at com.sun.tools.javac.comp.Resolve$4.checkArg(Resolve.java:826)
> at
> com.sun.tools.javac.comp.Resolve$AbstractMethodCheck.argumentsAcceptable(Resolve.java:731)
> at
> com.sun.tools.javac.comp.Resolve$4.argumentsAcceptable(Resolve.java:835)
> at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:576)
> at com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1440)
> at com.sun.tools.javac.comp.Resolve.findMethodInScope(Resolve.java:1621)
> at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1690)
> at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1664)
> at com.sun.tools.javac.comp.Resolve$9.doLookup(Resolve.java:2364)
> at
> com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:2972)
> at com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3223)
> at
> com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(Resolve.java:2361)
> at
> com.sun.tools.javac.comp.Resolve.resolveInternalMethod(Resolve.java:2429)
> at
> com.sun.tools.javac.comp.LambdaToMethod.makeIndyCall(LambdaToMethod.java:1036)
> at
> com.sun.tools.javac.comp.LambdaToMethod.makeMetafactoryIndyCall(LambdaToMethod.java:1019)
> at
> com.sun.tools.javac.comp.LambdaToMethod.visitReference(LambdaToMethod.java:406)
> at
> com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:2149)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at
> com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:197)
> at
> com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:190)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70)
> at
> com.sun.tools.javac.tree.TreeTranslator.visitApply(TreeTranslator.java:280)
> at
> co
[jira] [Closed] (ARTEMIS-968) Synchronization issue in ActiveMQThreadPoolExecutor
[
https://issues.apache.org/jira/browse/ARTEMIS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda closed ARTEMIS-968.
--
Resolution: Duplicate
> Synchronization issue in ActiveMQThreadPoolExecutor
> ---
>
> Key: ARTEMIS-968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-968
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.2, 2.0.0
>Reporter: Erich Duda
>
> During investigation of test failures in Artemis test suite I've noticed that
> {{ActiveMQThreadPoolExecutor}} sometimes doesn't allocate new Worker for a
> task even if {{maxPoolSize = 16}} and there are only 3 tasks to execute.
> Instead the task is queued and it waits until some worker finishes its job.
> I think the problem is in offer method.
> {code}
> @Override
> public boolean offer(Runnable runnable) {
> int poolSize = executor.getPoolSize();
> // If the are less threads than the configured maximum, then the tasks is
> // only queued if there are some idle threads that can run that tasks.
> // We have to add the queue size, since some tasks might just have been
> queued
> // but not yet taken by an idle thread.
> if (poolSize < executor.getMaximumPoolSize() && (size() +
> executor.getActive()) >= poolSize)
> return false;
> return super.offer(runnable);
> }
> {code}
> There are 3 variables which are compared with themselves -
> {{executor.getPoolSize()}}, {{size()}}, {{executor.getActive()}} - without
> any synchronization. It may happen that the if condition is {{false}} just
> because some variable hasn't been updated yet.
> I've created reproducer \[1\] for this issue. You can run it from branch
> \[2\] using following commands.
> {code}
> git clone https://github.com/dudaerich/activemq-artemis
> cd activemq-artemis
> git checkout ActiveMQThreadPoolExecutorTest
> mvn test -Dtest=ActiveMQThreadPoolExecutorTest -Ptests -DfailIfNoTests=false
> -Drat.ignoreErrors=true 2>&1 | tee log
> {code}
> \[1\]
> https://github.com/dudaerich/activemq-artemis/blob/a0eb0ea9caaf22a9d031d480625a638a2e0f300d/tests/unit-tests/src/test/java/org/apache/activemq/artemis/tests/unit/util/ActiveMQThreadPoolExecutorTest.java
> \[2\]
> https://github.com/dudaerich/activemq-artemis/commits/ActiveMQThreadPoolExecutorTest
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-995) Cleanup test suite
[ https://issues.apache.org/jira/browse/ARTEMIS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883010#comment-15883010 ] Erich Duda commented on ARTEMIS-995: [~clebertsuconic] I think we should keep this open at least until release. There are still some unstable tests. I am not sure if I find some time for another fixes but I hope that yes. > Cleanup test suite > -- > > Key: ARTEMIS-995 > URL: https://issues.apache.org/jira/browse/ARTEMIS-995 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.0.0 >Reporter: Erich Duda > Fix For: 2.0.0 > > > Artemis test suite contains several unstable tests which fail from time to > time. Aim of this task is to identify causes of failures and make the test > suite more stable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARTEMIS-995) Cleanup test suite
[ https://issues.apache.org/jira/browse/ARTEMIS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erich Duda updated ARTEMIS-995: --- Description: Artemis test suite contains several unstable tests which fail from time to time. Aim of this task is to identify causes of failures and make the test suite more stable. (was: Artemis test suite contains several unstable tests which fails from time to time. Aim of this task is to identify causes of failures and make the test suite more stable.) > Cleanup test suite > -- > > Key: ARTEMIS-995 > URL: https://issues.apache.org/jira/browse/ARTEMIS-995 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.0.0 >Reporter: Erich Duda > > Artemis test suite contains several unstable tests which fail from time to > time. Aim of this task is to identify causes of failures and make the test > suite more stable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARTEMIS-995) Cleanup test suite
Erich Duda created ARTEMIS-995: -- Summary: Cleanup test suite Key: ARTEMIS-995 URL: https://issues.apache.org/jira/browse/ARTEMIS-995 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.0.0 Reporter: Erich Duda Artemis test suite contains several unstable tests which fails from time to time. Aim of this task is to identify causes of failures and make the test suite more stable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-968) Synchronization issue in ActiveMQThreadPoolExecutor
[
https://issues.apache.org/jira/browse/ARTEMIS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15869399#comment-15869399
]
Erich Duda commented on ARTEMIS-968:
I searched how to implement ThreadPoolExecutor which would behave like
ActiveMQThreadPoolExecutor on the Internet but I haven't found anything
relevant.
I think it's not possible to do it by extending JDK implementation of
ThreadPoolExecutor, because you don't have access to internal structures and
locks.
I am thinking about modifying of OpenJDK implementation. What do you think? Is
it good idea? Thanks!
> Synchronization issue in ActiveMQThreadPoolExecutor
> ---
>
> Key: ARTEMIS-968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-968
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.2, 2.0.0
>Reporter: Erich Duda
>
> During investigation of test failures in Artemis test suite I've noticed that
> {{ActiveMQThreadPoolExecutor}} sometimes doesn't allocate new Worker for a
> task even if {{maxPoolSize = 16}} and there are only 3 tasks to execute.
> Instead the task is queued and it waits until some worker finishes its job.
> I think the problem is in offer method.
> {code}
> @Override
> public boolean offer(Runnable runnable) {
> int poolSize = executor.getPoolSize();
> // If the are less threads than the configured maximum, then the tasks is
> // only queued if there are some idle threads that can run that tasks.
> // We have to add the queue size, since some tasks might just have been
> queued
> // but not yet taken by an idle thread.
> if (poolSize < executor.getMaximumPoolSize() && (size() +
> executor.getActive()) >= poolSize)
> return false;
> return super.offer(runnable);
> }
> {code}
> There are 3 variables which are compared with themselves -
> {{executor.getPoolSize()}}, {{size()}}, {{executor.getActive()}} - without
> any synchronization. It may happen that the if condition is {{false}} just
> because some variable hasn't been updated yet.
> I've created reproducer \[1\] for this issue. You can run it from branch
> \[2\] using following commands.
> {code}
> git clone https://github.com/dudaerich/activemq-artemis
> cd activemq-artemis
> git checkout ActiveMQThreadPoolExecutorTest
> mvn test -Dtest=ActiveMQThreadPoolExecutorTest -Ptests -DfailIfNoTests=false
> -Drat.ignoreErrors=true 2>&1 | tee log
> {code}
> \[1\]
> https://github.com/dudaerich/activemq-artemis/blob/a0eb0ea9caaf22a9d031d480625a638a2e0f300d/tests/unit-tests/src/test/java/org/apache/activemq/artemis/tests/unit/util/ActiveMQThreadPoolExecutorTest.java
> \[2\]
> https://github.com/dudaerich/activemq-artemis/commits/ActiveMQThreadPoolExecutorTest
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ARTEMIS-968) Synchronization issue in ActiveMQThreadPoolExecutor
[
https://issues.apache.org/jira/browse/ARTEMIS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-968:
---
Description:
During investigation of test failures in Artemis test suite I've noticed that
{{ActiveMQThreadPoolExecutor}} sometimes doesn't allocate new Worker for a task
even if {{maxPoolSize = 16}} and there are only 3 tasks to execute. Instead the
task is queued and it waits until some worker finishes its job.
I think the problem is in offer method.
{code}
@Override
public boolean offer(Runnable runnable) {
int poolSize = executor.getPoolSize();
// If the are less threads than the configured maximum, then the tasks is
// only queued if there are some idle threads that can run that tasks.
// We have to add the queue size, since some tasks might just have been queued
// but not yet taken by an idle thread.
if (poolSize < executor.getMaximumPoolSize() && (size() +
executor.getActive()) >= poolSize)
return false;
return super.offer(runnable);
}
{code}
There are 3 variables which are compared with themselves -
{{executor.getPoolSize()}}, {{size()}}, {{executor.getActive()}} - without any
synchronization. It may happen that the if condition is {{false}} just because
some variable hasn't been updated yet.
I've created reproducer \[1\] for this issue. You can run it from branch \[2\]
using following commands.
{code}
git clone https://github.com/dudaerich/activemq-artemis
cd activemq-artemis
git checkout ActiveMQThreadPoolExecutorTest
mvn test -Dtest=ActiveMQThreadPoolExecutorTest -Ptests -DfailIfNoTests=false
-Drat.ignoreErrors=true 2>&1 | tee log
{code}
\[1\]
https://github.com/dudaerich/activemq-artemis/blob/a0eb0ea9caaf22a9d031d480625a638a2e0f300d/tests/unit-tests/src/test/java/org/apache/activemq/artemis/tests/unit/util/ActiveMQThreadPoolExecutorTest.java
\[2\]
https://github.com/dudaerich/activemq-artemis/commits/ActiveMQThreadPoolExecutorTest
was:
During investigation of test failures in Artemis test suite I've noticed that
ActiveMQThreadPoolExecutorTest sometimes doesn't allocate new Worker for a task
even if {{maxPoolSize = 16}} and there are only 3 tasks to execute. Instead the
task is queued and it waits until some worker finishes its job.
I think the problem is in offer method.
{code}
@Override
public boolean offer(Runnable runnable) {
int poolSize = executor.getPoolSize();
// If the are less threads than the configured maximum, then the tasks is
// only queued if there are some idle threads that can run that tasks.
// We have to add the queue size, since some tasks might just have been queued
// but not yet taken by an idle thread.
if (poolSize < executor.getMaximumPoolSize() && (size() +
executor.getActive()) >= poolSize)
return false;
return super.offer(runnable);
}
{code}
There are 3 variables which are compared with themselves -
{{executor.getPoolSize()}}, {{size()}}, {{executor.getActive()}} - without any
synchronization. It may happen that the if condition is {{false}} just because
some variable hasn't been updated yet.
I've created reproducer \[1\] for this issue. You can run it from branch \[2\]
using following commands.
{code}
git clone https://github.com/dudaerich/activemq-artemis
cd activemq-artemis
git checkout ActiveMQThreadPoolExecutorTest
mvn test -Dtest=ActiveMQThreadPoolExecutorTest -Ptests -DfailIfNoTests=false
-Drat.ignoreErrors=true 2>&1 | tee log
{code}
\[1\]
https://github.com/dudaerich/activemq-artemis/blob/a0eb0ea9caaf22a9d031d480625a638a2e0f300d/tests/unit-tests/src/test/java/org/apache/activemq/artemis/tests/unit/util/ActiveMQThreadPoolExecutorTest.java
\[2\]
https://github.com/dudaerich/activemq-artemis/commits/ActiveMQThreadPoolExecutorTest
> Synchronization issue in ActiveMQThreadPoolExecutor
> ---
>
> Key: ARTEMIS-968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-968
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.2, 2.0.0
>Reporter: Erich Duda
>
> During investigation of test failures in Artemis test suite I've noticed that
> {{ActiveMQThreadPoolExecutor}} sometimes doesn't allocate new Worker for a
> task even if {{maxPoolSize = 16}} and there are only 3 tasks to execute.
> Instead the task is queued and it waits until some worker finishes its job.
> I think the problem is in offer method.
> {code}
> @Override
> public boolean offer(Runnable runnable) {
> int poolSize = executor.getPoolSize();
> // If the are less threads than the configured maximum, then the tasks is
> // only queued if there are some idle threads that can run that tasks.
> // We have to add the queue size, since some tasks might just have been
> queued
> // but not yet taken by an idle thread.
> if (poolSize < executor.getMaximumPoolSize(
[jira] [Created] (ARTEMIS-968) Synchronization issue in ActiveMQThreadPoolExecutor
Erich Duda created ARTEMIS-968:
--
Summary: Synchronization issue in ActiveMQThreadPoolExecutor
Key: ARTEMIS-968
URL: https://issues.apache.org/jira/browse/ARTEMIS-968
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.5.2, 2.0.0
Reporter: Erich Duda
During investigation of test failures in Artemis test suite I've noticed that
ActiveMQThreadPoolExecutorTest sometimes doesn't allocate new Worker for a task
even if {{maxPoolSize = 16}} and there are only 3 tasks to execute. Instead the
task is queued and it waits until some worker finishes its job.
I think the problem is in offer method.
{code}
@Override
public boolean offer(Runnable runnable) {
int poolSize = executor.getPoolSize();
// If the are less threads than the configured maximum, then the tasks is
// only queued if there are some idle threads that can run that tasks.
// We have to add the queue size, since some tasks might just have been queued
// but not yet taken by an idle thread.
if (poolSize < executor.getMaximumPoolSize() && (size() +
executor.getActive()) >= poolSize)
return false;
return super.offer(runnable);
}
{code}
There are 3 variables which are compared with themselves -
{{executor.getPoolSize()}}, {{size()}}, {{executor.getActive()}} - without any
synchronization. It may happen that the if condition is {{false}} just because
some variable hasn't been updated yet.
I've created reproducer \[1\] for this issue. You can run it from branch \[2\]
using following commands.
{code}
git clone https://github.com/dudaerich/activemq-artemis
cd activemq-artemis
git checkout ActiveMQThreadPoolExecutorTest
mvn test -Dtest=ActiveMQThreadPoolExecutorTest -Ptests -DfailIfNoTests=false
-Drat.ignoreErrors=true 2>&1 | tee log
{code}
\[1\]
https://github.com/dudaerich/activemq-artemis/blob/a0eb0ea9caaf22a9d031d480625a638a2e0f300d/tests/unit-tests/src/test/java/org/apache/activemq/artemis/tests/unit/util/ActiveMQThreadPoolExecutorTest.java
\[2\]
https://github.com/dudaerich/activemq-artemis/commits/ActiveMQThreadPoolExecutorTest
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-914) Max saved replicated journal size on Live node should not be -1
[
https://issues.apache.org/jira/browse/ARTEMIS-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815436#comment-15815436
]
Erich Duda commented on ARTEMIS-914:
Sorry I forgot to mention that. I think the value is hard-coded in \[1\] and
\[2\].
\[1\]
https://github.com/apache/activemq-artemis/blob/1.5.1/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/ha/ReplicatedPolicy.java#L51
\[2\]
https://github.com/apache/activemq-artemis/blob/1.5.1/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/ha/ReplicatedPolicy.java#L125
> Max saved replicated journal size on Live node should not be -1
> ---
>
> Key: ARTEMIS-914
> URL: https://issues.apache.org/jira/browse/ARTEMIS-914
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.1
>Reporter: Erich Duda
>
> The max-saved-replicated-journal-size on Live node is {{-1}} what can lead to
> fill the disk by old replicas. The value is hard coded in Artemis code and
> cannot be changed. I think the default value should be some small number,
> e.g. 2.
> I hit this issue with Wildfly. There are plans to update Artemis in Wildfly
> to 1.5.2 version. It would be great if the fix was included in 1.5.2 release.
> Thanks :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-914) Max saved replicated journal size on Live node should not be -1
Erich Duda created ARTEMIS-914:
--
Summary: Max saved replicated journal size on Live node should not
be -1
Key: ARTEMIS-914
URL: https://issues.apache.org/jira/browse/ARTEMIS-914
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.5.1
Reporter: Erich Duda
The max-saved-replicated-journal-size on Live node is {{-1}} what can lead to
fill the disk by old replicas. The value is hard coded in Artemis code and
cannot be changed. I think the default value should be some small number, e.g.
2.
I hit this issue with Wildfly. There are plans to update Artemis in Wildfly to
1.5.2 version. It would be great if the fix was included in 1.5.2 release.
Thanks :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-850) Do not swallow the SQLException when creating the table
[ https://issues.apache.org/jira/browse/ARTEMIS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15725319#comment-15725319 ] Erich Duda commented on ARTEMIS-850: The error message could also dump the incorrect SQL command. Wdyt? > Do not swallow the SQLException when creating the table > --- > > Key: ARTEMIS-850 > URL: https://issues.apache.org/jira/browse/ARTEMIS-850 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.5.0 >Reporter: Jeff Mesnil > > The AbstractJDBCDriver[1] swallows the SQLException if the table can not be > created and does not report the error to the user (who has no idea what went > wrong). > Instead it should propagate the exception (after the connection is rolled > back) > [1] > https://github.com/apache/activemq-artemis/blob/master/artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/drivers/AbstractJDBCDriver.java#L124 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-861) Artemis 1.5 compilation fails with IBM JDK
[
https://issues.apache.org/jira/browse/ARTEMIS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-861:
---
Description:
The compilation fails in module ActiveMQ Artemis Commons with following
exception.
{code}
[INFO] Compiling 11 source files to
/home/eduda/Projects/activemq-artemis/artemis-commons/target/test-classes
An exception has occurred in the compiler (1.9.0-internal). Please file a bug
at the Java Bug Database (http://bugreport.java.com/bugreport/) after checking
the database for duplicates. Include your program and the following diagnostic
in your report. Thank you.
java.lang.NullPointerException
at
com.sun.tools.javac.code.Types.isSignaturePolymorphic(Types.java:1066)
at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2028)
at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2253)
at
com.sun.tools.javac.jvm.ClassReader.readClassBuffer(ClassReader.java:2325)
at
com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2338)
at com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:341)
at com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:279)
at com.sun.tools.javac.code.ClassFinder.access$000(ClassFinder.java:72)
at com.sun.tools.javac.code.ClassFinder$1.complete(ClassFinder.java:159)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:579)
at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1074)
at com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1125)
at
com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1051)
at com.sun.tools.javac.code.Type$ClassType.allparams(Type.java:1073)
at
com.sun.tools.javac.code.Type$ClassType.isParameterized(Type.java:1086)
at com.sun.tools.javac.code.Types.capture(Types.java:3995)
at
com.sun.tools.javac.comp.Resolve$MethodResultInfo.check(Resolve.java:1007)
at com.sun.tools.javac.comp.Resolve$4.checkArg(Resolve.java:826)
at
com.sun.tools.javac.comp.Resolve$AbstractMethodCheck.argumentsAcceptable(Resolve.java:731)
at
com.sun.tools.javac.comp.Resolve$4.argumentsAcceptable(Resolve.java:835)
at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:576)
at com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1440)
at com.sun.tools.javac.comp.Resolve.findMethodInScope(Resolve.java:1621)
at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1690)
at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1664)
at com.sun.tools.javac.comp.Resolve$9.doLookup(Resolve.java:2364)
at
com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:2972)
at com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3223)
at
com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(Resolve.java:2361)
at
com.sun.tools.javac.comp.Resolve.resolveInternalMethod(Resolve.java:2429)
at
com.sun.tools.javac.comp.LambdaToMethod.makeIndyCall(LambdaToMethod.java:1036)
at
com.sun.tools.javac.comp.LambdaToMethod.makeMetafactoryIndyCall(LambdaToMethod.java:1019)
at
com.sun.tools.javac.comp.LambdaToMethod.visitReference(LambdaToMethod.java:406)
at
com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:2149)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:197)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:190)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70)
at
com.sun.tools.javac.tree.TreeTranslator.visitApply(TreeTranslator.java:280)
at
com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1598)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:197)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:190)
at
com.sun.tools.javac.tree.TreeTranslator.visitVarDef(TreeTranslator.java:158)
at
com.sun.tools.javac.comp.LambdaToMethod.visitVarDef(LambdaToMethod.java:460)
at
com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:920)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:197)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:190)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70)
at
com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167)
at com.sun.tools
[jira] [Created] (ARTEMIS-861) Artemis 1.5 compilation fails with IBM JDK
Erich Duda created ARTEMIS-861:
--
Summary: Artemis 1.5 compilation fails with IBM JDK
Key: ARTEMIS-861
URL: https://issues.apache.org/jira/browse/ARTEMIS-861
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.5.0
Environment: IBM JDK
The issue was hit with following version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
20151019_272764 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR2_20151019_2144_B272764
JIT - tr.r14.java_20151006_102517.04
GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS
J9CL - 20151019_272764)
JCL - 20151022_01 based on Oracle jdk8u65-b17
Reporter: Erich Duda
Priority: Critical
The compilation fails in module ActiveMQ Artemis Commons with following
exception.
{code}
[INFO] Compiling 11 source files to
/home/eduda/Projects/activemq-artemis/artemis-commons/target/test-classes
An exception has occurred in the compiler (1.9.0-internal). Please file a bug
at the Java Bug Database (http://bugreport.java.com/bugreport/) after checking
the database for duplicates. Include your program and the following diagnostic
in your report. Thank you.
java.lang.NullPointerException
at
com.sun.tools.javac.code.Types.isSignaturePolymorphic(Types.java:1066)
at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2028)
at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2253)
at
com.sun.tools.javac.jvm.ClassReader.readClassBuffer(ClassReader.java:2325)
at
com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2338)
at com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:341)
at com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:279)
at com.sun.tools.javac.code.ClassFinder.access$000(ClassFinder.java:72)
at com.sun.tools.javac.code.ClassFinder$1.complete(ClassFinder.java:159)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:579)
at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1074)
at com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1125)
at
com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1051)
at com.sun.tools.javac.code.Type$ClassType.allparams(Type.java:1073)
at
com.sun.tools.javac.code.Type$ClassType.isParameterized(Type.java:1086)
at com.sun.tools.javac.code.Types.capture(Types.java:3995)
at
com.sun.tools.javac.comp.Resolve$MethodResultInfo.check(Resolve.java:1007)
at com.sun.tools.javac.comp.Resolve$4.checkArg(Resolve.java:826)
at
com.sun.tools.javac.comp.Resolve$AbstractMethodCheck.argumentsAcceptable(Resolve.java:731)
at
com.sun.tools.javac.comp.Resolve$4.argumentsAcceptable(Resolve.java:835)
at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:576)
at com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1440)
at com.sun.tools.javac.comp.Resolve.findMethodInScope(Resolve.java:1621)
at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1690)
at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1664)
at com.sun.tools.javac.comp.Resolve$9.doLookup(Resolve.java:2364)
at
com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:2972)
at com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3223)
at
com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(Resolve.java:2361)
at
com.sun.tools.javac.comp.Resolve.resolveInternalMethod(Resolve.java:2429)
at
com.sun.tools.javac.comp.LambdaToMethod.makeIndyCall(LambdaToMethod.java:1036)
at
com.sun.tools.javac.comp.LambdaToMethod.makeMetafactoryIndyCall(LambdaToMethod.java:1019)
at
com.sun.tools.javac.comp.LambdaToMethod.visitReference(LambdaToMethod.java:406)
at
com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:2149)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:197)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:190)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70)
at
com.sun.tools.javac.tree.TreeTranslator.visitApply(TreeTranslator.java:280)
at
com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1598)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:197)
at
com.sun.tools.javac.comp.LambdaToMethod.translate(LambdaToMethod.java:190)
at
com.sun.tools.javac.tree.TreeTranslator.visitV
[jira] [Created] (ARTEMIS-801) Several tests fail if the project is located on path with special characters
Erich Duda created ARTEMIS-801:
--
Summary: Several tests fail if the project is located on path with
special characters
Key: ARTEMIS-801
URL: https://issues.apache.org/jira/browse/ARTEMIS-801
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.4.0
Reporter: Erich Duda
If the path to file contains special characters such as '&', the file is not
found.
{code}
java.nio.file.NoSuchFileException:
/mnt/hudson_workspace/workspace/artemis-project-testsuite-matrix-upstream/NATIVES/false/jdk/openjdk1.8_local/label/RHEL6%26%26x86_64/artemis-cli/target/test-classes/broker-reload.xml
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
at java.nio.file.Files.newByteChannel(Files.java:361)
at java.nio.file.Files.newByteChannel(Files.java:407)
at java.nio.file.Files.readAllBytes(Files.java:3152)
at
org.apache.activemq.cli.test.FileBrokerTest.replacePatternInFile(FileBrokerTest.java:145)
at
org.apache.activemq.cli.test.FileBrokerTest.testConfigFileReload(FileBrokerTest.java:137)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ARTEMIS-645) [Artemis Testsuite] ClusteredGroupingTest#testGroupingSendTo3queuesNoConsumerOnLocalQueue fails
[
https://issues.apache.org/jira/browse/ARTEMIS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda closed ARTEMIS-645.
--
Resolution: Fixed
> [Artemis Testsuite]
> ClusteredGroupingTest#testGroupingSendTo3queuesNoConsumerOnLocalQueue fails
> ---
>
> Key: ARTEMIS-645
> URL: https://issues.apache.org/jira/browse/ARTEMIS-645
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: consumer 0 did not receive message 0
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusterTestBase.verifyReceiveAllInRangeNotBefore(ClusterTestBase.java:929)
> at
> org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusterTestBase.verifyReceiveAllInRange(ClusterTestBase.java:808)
> at
> org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusteredGroupingTest.testGroupingSendTo3queuesNoConsumerOnLocalQueue(ClusteredGroupingTest.java:1221)
> {code}
> {code}
> 05:27:26,920 INFO [org.apache.activemq.artemis.tests.integration] ***
> dumping consumers:
> 05:27:26,920 INFO [org.apache.activemq.artemis.tests.integration] Dumping
> consumer 0
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 0 null message
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] Dumping
> consumer 2
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 0
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 1
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 2
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 3
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 4
> 05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 5
> 05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 6
> 05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 7
> 05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 8
> 05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 received message 9
> 05:27:27,923 INFO [org.apache.activemq.artemis.tests.integration] check
> receive Consumer 2 null message
> {code}
> The batch of messages can be received also by the second consumer. It depends
> on cluster decision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-683) artemis-dto module cannot be built with JDK 9
Erich Duda created ARTEMIS-683:
--
Summary: artemis-dto module cannot be built with JDK 9
Key: ARTEMIS-683
URL: https://issues.apache.org/jira/browse/ARTEMIS-683
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.4.0
Reporter: Erich Duda
*Reproducer*
{code}
MAVEN_OPTS="-addmods java.activation" mvn clean install -pl artemis-dto
{code}
*Build Error*
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project
artemis-dto: An Ant BuildException has occured: Error starting ap
[ERROR] around Ant part .. @ 7:200 in
/home/eduda/Projects/activemq-artemis/artemis-dto/target/antrun/build-main.xml:
java.lang.annotation.IncompleteAnnotationException:
javax.xml.bind.annotation.XmlSchema missing element namespace
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project
artemis-dto: An Ant BuildException has occured: Error starting ap
around Ant part .. @ 7:200 in
/home/eduda/Projects/activemq-artemis/artemis-dto/target/antrun/build-main.xml
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant
BuildException has occured: Error starting ap
around Ant part .. @ 7:200 in
/home/eduda/Projects/activemq-artemis/artemis-dto/target/antrun/build-main.xml
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:355)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by:
/home/eduda/Projects/activemq-artemis/artemis-dto/target/antrun/build-main.xml:7:
Error starting ap
at
com.sun.tools.jxc.ApBasedTask$InternalApAdapter.execute(ApBasedTask.java:131)
at com.sun.tools.jxc.ApBasedTask.compile(ApBasedTask.java:170)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:912)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
[jira] [Created] (ARTEMIS-645) [Artemis Testsuite] ClusteredGroupingTest#testGroupingSendTo3queuesNoConsumerOnLocalQueue fails
Erich Duda created ARTEMIS-645:
--
Summary: [Artemis Testsuite]
ClusteredGroupingTest#testGroupingSendTo3queuesNoConsumerOnLocalQueue fails
Key: ARTEMIS-645
URL: https://issues.apache.org/jira/browse/ARTEMIS-645
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: consumer 0 did not receive message 0
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusterTestBase.verifyReceiveAllInRangeNotBefore(ClusterTestBase.java:929)
at
org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusterTestBase.verifyReceiveAllInRange(ClusterTestBase.java:808)
at
org.apache.activemq.artemis.tests.integration.cluster.distribution.ClusteredGroupingTest.testGroupingSendTo3queuesNoConsumerOnLocalQueue(ClusteredGroupingTest.java:1221)
{code}
{code}
05:27:26,920 INFO [org.apache.activemq.artemis.tests.integration] *** dumping
consumers:
05:27:26,920 INFO [org.apache.activemq.artemis.tests.integration] Dumping
consumer 0
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 0 null message
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] Dumping
consumer 2
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 0
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 1
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 2
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 3
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 4
05:27:27,421 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 5
05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 6
05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 7
05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 8
05:27:27,422 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 received message 9
05:27:27,923 INFO [org.apache.activemq.artemis.tests.integration] check
receive Consumer 2 null message
{code}
The batch of messages can be received also by the second consumer. It depends
on cluster decision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-643) [Artemis Testsuite] wrong paths in restricted-security-client.policy
[
https://issues.apache.org/jira/browse/ARTEMIS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-643.
Resolution: Fixed
Fix Version/s: 1.4.0
> [Artemis Testsuite] wrong paths in restricted-security-client.policy
>
>
> Key: ARTEMIS-643
> URL: https://issues.apache.org/jira/browse/ARTEMIS-643
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Erich Duda
> Fix For: 1.4.0
>
>
> {code}
> permission java.io.FilePermission
> "${user.dir}/artemis-core-client/target/classes/-", "read";
> permission java.io.FilePermission
> "${user.dir}/artemis-core-client/target/artemis-core-client-${project.version}.jar",
> "read";
> {code}
> {{user.dir}} points to current working directory from which the maven command
> was invoked. If the command is not invoked from project root directory, the
> generated paths are wrong what causes failures of some tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-643) [Artemis Testsuite] wrong paths in restricted-security-client.policy
Erich Duda created ARTEMIS-643:
--
Summary: [Artemis Testsuite] wrong paths in
restricted-security-client.policy
Key: ARTEMIS-643
URL: https://issues.apache.org/jira/browse/ARTEMIS-643
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Erich Duda
{code}
permission java.io.FilePermission
"${user.dir}/artemis-core-client/target/classes/-", "read";
permission java.io.FilePermission
"${user.dir}/artemis-core-client/target/artemis-core-client-${project.version}.jar",
"read";
{code}
{{user.dir}} points to current working directory from which the maven command
was invoked. If the command is not invoked from project root directory, the
generated paths are wrong what causes failures of some tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-634) [Artemis Testsuite] JMSQueueControlUsingJMSTest#testDeleteWithPaging fails
Erich Duda created ARTEMIS-634:
--
Summary: [Artemis Testsuite]
JMSQueueControlUsingJMSTest#testDeleteWithPaging fails
Key: ARTEMIS-634
URL: https://issues.apache.org/jira/browse/ARTEMIS-634
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<100> but was:<57>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.integration.jms.server.management.JMSQueueControlTest.testDeleteWithPaging(JMSQueueControlTest.java:1082)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
We have to wait some time until Artemis delivers all messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-632) [Artemis Testsuite] JMSServerControlUsingJMSTest#testRemoteClientIDConnection fails
Erich Duda created ARTEMIS-632:
--
Summary: [Artemis Testsuite]
JMSServerControlUsingJMSTest#testRemoteClientIDConnection fails
Key: ARTEMIS-632
URL: https://issues.apache.org/jira/browse/ARTEMIS-632
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControlTest.testRemoteClientIDConnection(JMSServerControlTest.java:952)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
The failure occurs when connection objects are destroyed by garbage collector
before time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-342) [Artemis Testsuite] NettySecurityClientTest.testProducerConsumerClientWithSecurityManager fails
[
https://issues.apache.org/jira/browse/ARTEMIS-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-342:
---
Fix Version/s: (was: 1.2.0)
> [Artemis Testsuite]
> NettySecurityClientTest.testProducerConsumerClientWithSecurityManager fails
> ---
>
> Key: ARTEMIS-342
> URL: https://issues.apache.org/jira/browse/ARTEMIS-342
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Erich Duda
>
> This test consistently fails on all JDKs.
> {code}
> client VM did not exit cleanly expected:<0> but was:<1>
> java.lang.AssertionError: client VM did not exit cleanly expected:<0> but
> was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.doTestProducerConsumerClient(NettySecurityClientTest.java:96)
> at
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.testProducerConsumerClientWithSecurityManager(NettySecurityClientTest.java:45)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-342) [Artemis Testsuite] NettySecurityClientTest.testProducerConsumerClientWithSecurityManager fails
[
https://issues.apache.org/jira/browse/ARTEMIS-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda reopened ARTEMIS-342:
The test fails again. Security client requires additional permissions.
> [Artemis Testsuite]
> NettySecurityClientTest.testProducerConsumerClientWithSecurityManager fails
> ---
>
> Key: ARTEMIS-342
> URL: https://issues.apache.org/jira/browse/ARTEMIS-342
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Erich Duda
>
> This test consistently fails on all JDKs.
> {code}
> client VM did not exit cleanly expected:<0> but was:<1>
> java.lang.AssertionError: client VM did not exit cleanly expected:<0> but
> was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.doTestProducerConsumerClient(NettySecurityClientTest.java:96)
> at
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.testProducerConsumerClientWithSecurityManager(NettySecurityClientTest.java:45)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-621) [Artemis Testsuite] Several tests do not use getUDPDiscoveryAddress and getUDPDiscoveryPort for configuration of group address/port
[
https://issues.apache.org/jira/browse/ARTEMIS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda reopened ARTEMIS-621:
Pull request caused regression in
{{ConnectionFactorySerializationTest.testConnectionFactoryUDP}}. Fortunately it
is only test issue.
> [Artemis Testsuite] Several tests do not use getUDPDiscoveryAddress and
> getUDPDiscoveryPort for configuration of group address/port
> ---
>
> Key: ARTEMIS-621
> URL: https://issues.apache.org/jira/browse/ARTEMIS-621
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Erich Duda
> Fix For: 1.4.0
>
>
> All tests should use {{getUDPDiscoveryAddress}} and {{getUDPDiscoveryPort}}
> for group address/port. Otherwise it is not able to configure which multicast
> address/port will be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-621) [Artemis Testsuite] Several tests do not use getUDPDiscoveryAddress and getUDPDiscoveryPort for configuration of group address/port
Erich Duda created ARTEMIS-621:
--
Summary: [Artemis Testsuite] Several tests do not use
getUDPDiscoveryAddress and getUDPDiscoveryPort for configuration of group
address/port
Key: ARTEMIS-621
URL: https://issues.apache.org/jira/browse/ARTEMIS-621
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Erich Duda
All tests should use {{getUDPDiscoveryAddress}} and {{getUDPDiscoveryPort}} for
group address/port. Otherwise it is not able to configure which multicast
address/port will be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-606) [Artemis Testsuite] JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails
Erich Duda created ARTEMIS-606:
--
Summary: [Artemis Testsuite]
JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails
Key: ARTEMIS-606
URL: https://issues.apache.org/jira/browse/ARTEMIS-606
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: did not received the expected JMSException
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.doCloseConnectionsForUser(JMSServerControl2Test.java:1136)
at
org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.testCloseConnectionsForUserForInVM(JMSServerControl2Test.java:143)
{code}
{code}
11:49:34,359 INFO [org.apache.activemq.artemis.core.server] #*#*# Starting
test: testCloseConnectionsForUserForInVM()...
#test testCloseConnectionsForUserForInVM
11:49:34,394 INFO [org.apache.activemq.artemis.core.server] AMQ221000: live
Message Broker is starting with configuration Broker Configuration
(clustered=false,journalDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/journal,bindingsDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/bindings,largeMessagesDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/large-msg,pagingDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/page)
11:49:34,395 INFO [org.apache.activemq.artemis.core.server] AMQ221012: Using
AIO Journal
11:49:34,397 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-server]. Adding protocol support for: CORE
11:49:34,399 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-amqp-protocol]. Adding protocol support for:
AMQP
11:49:34,400 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-stomp-protocol]. Adding protocol support for:
STOMP
11:49:34,401 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-openwire-protocol]. Adding protocol support
for: OPENWIRE
11:49:34,403 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for:
HORNETQ
11:49:34,404 INFO [org.apache.activemq.artemis.core.server] AMQ221043:
Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for:
MQTT
11:49:34,506 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server
is now live
11:49:34,506 INFO [org.apache.activemq.artemis.core.server] AMQ221001: Apache
ActiveMQ Artemis Message Broker version 1.1.0.jboss-SNAPSHOT
[nodeID=e915a1c8-3d47-11e6-a0a1-3172e2bd12af]
11:49:34,606 INFO [org.apache.activemq.artemis.core.server] AMQ221003: trying
to deploy queue jms.queue.97c12b14-0a31-4cb8-a1ad-5ba0217abb5f
11:49:34,650 INFO [org.apache.activemq.artemis.core.server] AMQ221003: trying
to deploy queue jms.queue.66bdf106-b409-4e3c-b70b-d9918ea812c3
11:49:34,830 WARN [org.apache.activemq.artemis.core.client] AMQ212037:
Connection failure has been detected: AMQ119108: connections for user fakeUser
closed by management [code=INTERNAL_ERROR]
11:49:34,830 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client
connection failed, clearing up resources for session
e94bcd00-3d47-11e6-a0a1-3172e2bd12af
11:49:34,831 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared
up resources for session e94bcd00-3d47-11e6-a0a1-3172e2bd12af
11:49:34,846 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client
connection failed, clearing up resources for session
e94f9d91-3d47-11e6-a0a1-3172e2bd12af
11:49:34,848 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared
up resources for session e94f9d91-3d47-11e6-a0a1-3172e2bd12af
11:49:34,853 WARN [org.apache.activemq.artemis.jms.client] AMQ122000: I''m
closing a JMS connection you left open. Please make sure you close all JMS
connections explicitly before letting them go out of scope! see stacktrace to
find out where it was created: java.lang.Exception
at
org.apache.activemq.artemis.jms.client.ActiveMQConnection.(ActiveMQConnection.java:155)
[:]
at
org.apache.activemq.artemis.jms.cli
[jira] [Resolved] (ARTEMIS-527) [Artemis Testsuite] TopicControlTest fails
[
https://issues.apache.org/jira/browse/ARTEMIS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-527.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite] TopicControlTest fails
> --
>
> Key: ARTEMIS-527
> URL: https://issues.apache.org/jira/browse/ARTEMIS-527
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: expected:<6> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.activemq.artemis.tests.integration.jms.server.management.TopicControlTest.testRemoveAllMessages(TopicControlTest.java:409)
> {code}
> After that messages are sent to the server, they are not immediately visible
> in {{topicControl.getMessageCount()}}. We should give the server a chance to
> properly deliver all messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-538) [Artemis Testsuite] JMSFailoverListenerTest#testManualFailover fails
[
https://issues.apache.org/jira/browse/ARTEMIS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-538.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite] JMSFailoverListenerTest#testManualFailover fails
>
>
> Key: ARTEMIS-538
> URL: https://issues.apache.org/jira/browse/ARTEMIS-538
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: expected: but
> was:
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at
> org.apache.activemq.artemis.tests.integration.jms.cluster.JMSFailoverListenerTest.testManualFailover(JMSFailoverListenerTest.java:228)
> {code}
> I found out that problem is in \[1\]. When events occur consecutive, ordering
> of their executions is not guaranteed.
> \[1\]
> {code:title=ActiveMQConnection.java}
> private static class FailoverEventListenerImpl implements
> FailoverEventListener {
> private final WeakReference connectionRef;
> FailoverEventListenerImpl(final ActiveMQConnection connection) {
> connectionRef = new WeakReference(connection);
> }
> @Override
> public void failoverEvent(final FailoverEventType eventType) {
> ActiveMQConnection conn = connectionRef.get();
> if (conn != null) {
> try {
>final FailoverEventListener failoverListener =
> conn.getFailoverListener();
>if (failoverListener != null) {
> new Thread(new Runnable() {
> public void run() {
> failoverListener.failoverEvent(eventType);
> }
> }).start();
>}
> }
> catch (JMSException e) {
>if (!conn.closed) {
>
> ActiveMQJMSClientLogger.LOGGER.errorCallingFailoverListener(e);
>}
> }
> }
> }
>}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-538) [Artemis Testsuite] JMSFailoverListenerTest#testManualFailover fails
Erich Duda created ARTEMIS-538:
--
Summary: [Artemis Testsuite]
JMSFailoverListenerTest#testManualFailover fails
Key: ARTEMIS-538
URL: https://issues.apache.org/jira/browse/ARTEMIS-538
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.activemq.artemis.tests.integration.jms.cluster.JMSFailoverListenerTest.testManualFailover(JMSFailoverListenerTest.java:228)
{code}
I found out that problem is in \[1\]. When events occur consecutive, ordering
of their executions is not guaranteed.
\[1\]
{code:title=ActiveMQConnection.java}
private static class FailoverEventListenerImpl implements FailoverEventListener
{
private final WeakReference connectionRef;
FailoverEventListenerImpl(final ActiveMQConnection connection) {
connectionRef = new WeakReference(connection);
}
@Override
public void failoverEvent(final FailoverEventType eventType) {
ActiveMQConnection conn = connectionRef.get();
if (conn != null) {
try {
final FailoverEventListener failoverListener =
conn.getFailoverListener();
if (failoverListener != null) {
new Thread(new Runnable() {
public void run() {
failoverListener.failoverEvent(eventType);
}
}).start();
}
}
catch (JMSException e) {
if (!conn.closed) {
ActiveMQJMSClientLogger.LOGGER.errorCallingFailoverListener(e);
}
}
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-527) [Artemis Testsuite] TopicControlTest fails
Erich Duda created ARTEMIS-527:
--
Summary: [Artemis Testsuite] TopicControlTest fails
Key: ARTEMIS-527
URL: https://issues.apache.org/jira/browse/ARTEMIS-527
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<6> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.integration.jms.server.management.TopicControlTest.testRemoveAllMessages(TopicControlTest.java:409)
{code}
After that messages are sent to the server, they are not immediately visible in
{{topicControl.getMessageCount()}}. We should give the server a chance to
properly deliver all messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-518) Improvement of default thread factory
[
https://issues.apache.org/jira/browse/ARTEMIS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-518.
Resolution: Fixed
Fix Version/s: 1.3.0
> Improvement of default thread factory
> -
>
> Key: ARTEMIS-518
> URL: https://issues.apache.org/jira/browse/ARTEMIS-518
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> I investigate test failures in the Artemis test suite and I see many
> "Thread leaked" issues. From stack traces It is evident that leaking
> threads arise from some thread pool and they are waiting for a job.
> Problem is that I am not able to find which thread pool owns the
> threads. When the default thread factory is used for creation of a
> thread, the name and the stack trace of thread looks following.
> {code}
> Thread Thread[pool-4-thread-45,5,main] is still alive with the following
> stackTrace:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
> I suggest to do not use the Java default thread factory but we should
> create own default thread factory which will set up name of thread's
> group in such way that we could find to which thread pool the thread
> belongs. The thread dump could look like this:
> {code}
> Thread Thread[Thread-0
> (org.apache.activemq.artemis.tests.unit.core.paging.impl.PagingStoreImplTest-32863545),5,org.apache.activemq.artemis.tests.unit.core.paging.impl.PagingStoreImplTest-32863545]
>
> is still alive with the following stackTrace:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-518) Improvement of default thread factory
Erich Duda created ARTEMIS-518:
--
Summary: Improvement of default thread factory
Key: ARTEMIS-518
URL: https://issues.apache.org/jira/browse/ARTEMIS-518
Project: ActiveMQ Artemis
Issue Type: Improvement
Affects Versions: 1.2.0
Reporter: Erich Duda
I investigate test failures in the Artemis test suite and I see many
"Thread leaked" issues. From stack traces It is evident that leaking
threads arise from some thread pool and they are waiting for a job.
Problem is that I am not able to find which thread pool owns the
threads. When the default thread factory is used for creation of a
thread, the name and the stack trace of thread looks following.
{code}
Thread Thread[pool-4-thread-45,5,main] is still alive with the following
stackTrace:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
{code}
I suggest to do not use the Java default thread factory but we should
create own default thread factory which will set up name of thread's
group in such way that we could find to which thread pool the thread
belongs. The thread dump could look like this:
{code}
Thread Thread[Thread-0
(org.apache.activemq.artemis.tests.unit.core.paging.impl.PagingStoreImplTest-32863545),5,org.apache.activemq.artemis.tests.unit.core.paging.impl.PagingStoreImplTest-32863545]
is still alive with the following stackTrace:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-475) [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails
Erich Duda created ARTEMIS-475:
--
Summary: [Artemis Testsuite]
SessionCloseTest#testCanNotUseXAWithClosedSession fails
Key: ARTEMIS-475
URL: https://issues.apache.org/jira/browse/ARTEMIS-475
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<4> but was:<-7>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.util.ActiveMQTestBase.expectXAException(ActiveMQTestBase.java:953)
at
org.apache.activemq.artemis.tests.integration.client.SessionCloseTest.testCanNotUseXAWithClosedSession(SessionCloseTest.java:135)
{code}
The test fails because of
https://github.com/apache/activemq-artemis/commit/ddf8d8f96e33f5f80e1c7a1590de9579aa8ead50
We need to update expected XA return code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-442) [Artemis Testsuite] ConcurrentDeliveryCancelTest#testConcurrentCancels calls System.exit
[
https://issues.apache.org/jira/browse/ARTEMIS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-442.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite] ConcurrentDeliveryCancelTest#testConcurrentCancels calls
> System.exit
>
>
> Key: ARTEMIS-442
> URL: https://issues.apache.org/jira/browse/ARTEMIS-442
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {{System.exit(-1)}} is called in the test what causes build failure when run
> the test suite with maven.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-442) [Artemis Testsuite] ConcurrentDeliveryCancelTest#testConcurrentCancels calls System.exit
[
https://issues.apache.org/jira/browse/ARTEMIS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda updated ARTEMIS-442:
---
Affects Version/s: (was: 1.1.0)
1.2.0
> [Artemis Testsuite] ConcurrentDeliveryCancelTest#testConcurrentCancels calls
> System.exit
>
>
> Key: ARTEMIS-442
> URL: https://issues.apache.org/jira/browse/ARTEMIS-442
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {{System.exit(-1)}} is called in the test what causes build failure when run
> the test suite with maven.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-442) [Artemis Testsuite] ConcurrentDeliveryCancelTest#testConcurrentCancels calls System.exit
Erich Duda created ARTEMIS-442:
--
Summary: [Artemis Testsuite]
ConcurrentDeliveryCancelTest#testConcurrentCancels calls System.exit
Key: ARTEMIS-442
URL: https://issues.apache.org/jira/browse/ARTEMIS-442
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{{System.exit(-1)}} is called in the test what causes build failure when run
the test suite with maven.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-430) [Artemis Testsuite] ClosingConnectionTest#testKill​Connection fails
[
https://issues.apache.org/jira/browse/ARTEMIS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-430.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite] ClosingConnectionTest#testKill​Connection fails
> ---
>
> Key: ARTEMIS-430
> URL: https://issues.apache.org/jira/browse/ARTEMIS-430
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: Sending message here should result in failure.
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.activemq.artemis.tests.extras.byteman.ClosingConnectionTest.testKillConnection(ClosingConnectionTest.java:142)
> {code}
> This test fails only on 32 bit machines. We have to send more messages to
> trigger byteman rule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-429) [Artemis Testsuite] TopicControlUsingJMSTest#testGetXXXMessagesCount fails
[
https://issues.apache.org/jira/browse/ARTEMIS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-429.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite] TopicControlUsingJMSTest#testGetXXXMessagesCount fails
> --
>
> Key: ARTEMIS-429
> URL: https://issues.apache.org/jira/browse/ARTEMIS-429
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: expected:<6> but was:<5>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at
> org.apache.activemq.artemis.tests.integration.jms.server.management.TopicControlUsingJMSTest.testGetXXXMessagesCount(TopicControlUsingJMSTest.java:127)
> {code}
> We should give time to {{Queue.deliverAsync}} to deliver messages before we
> start to check {{messageCount}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-428) [Artemis Testsuite] ReconnectTest#testInterruptReconnectInVMInterruptMainThread fails
[
https://issues.apache.org/jira/browse/ARTEMIS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-428.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite]
> ReconnectTest#testInterruptReconnectInVMInterruptMainThread fails
> -
>
> Key: ARTEMIS-428
> URL: https://issues.apache.org/jira/browse/ARTEMIS-428
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.activemq.artemis.tests.integration.remoting.ReconnectTest.internalTestInterruptReconnect(ReconnectTest.java:305)
> at
> org.apache.activemq.artemis.tests.integration.remoting.ReconnectTest.testInterruptReconnectInVMInterruptMainThread(ReconnectTest.java:225)
> {code}
> There is a synchronization issue. {{latchCommit.countDown()}} in
> {{beforeReconnect}} method is called before the thread is added to
> {{threadToBeInterrupted}} list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-430) [Artemis Testsuite] ClosingConnectionTest#testKill​Connection fails
Erich Duda created ARTEMIS-430:
--
Summary: [Artemis Testsuite]
ClosingConnectionTest#testKill​Connection fails
Key: ARTEMIS-430
URL: https://issues.apache.org/jira/browse/ARTEMIS-430
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: Sending message here should result in failure.
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.activemq.artemis.tests.extras.byteman.ClosingConnectionTest.testKillConnection(ClosingConnectionTest.java:142)
{code}
This test fails only on 32 bit machines. We have to send more messages to
trigger byteman rule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-429) [Artemis Testsuite] TopicControlUsingJMSTest#testGetXXXMessagesCount fails
Erich Duda created ARTEMIS-429:
--
Summary: [Artemis Testsuite]
TopicControlUsingJMSTest#testGetXXXMessagesCount fails
Key: ARTEMIS-429
URL: https://issues.apache.org/jira/browse/ARTEMIS-429
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<6> but was:<5>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.activemq.artemis.tests.integration.jms.server.management.TopicControlUsingJMSTest.testGetXXXMessagesCount(TopicControlUsingJMSTest.java:127)
{code}
We should give time to {{Queue.deliverAsync}} to deliver messages before we
start to check {{messageCount}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-428) [Artemis Testsuite] ReconnectTest#testInterruptReconnectInVMInterruptMainThread fails
Erich Duda created ARTEMIS-428:
--
Summary: [Artemis Testsuite]
ReconnectTest#testInterruptReconnectInVMInterruptMainThread fails
Key: ARTEMIS-428
URL: https://issues.apache.org/jira/browse/ARTEMIS-428
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.integration.remoting.ReconnectTest.internalTestInterruptReconnect(ReconnectTest.java:305)
at
org.apache.activemq.artemis.tests.integration.remoting.ReconnectTest.testInterruptReconnectInVMInterruptMainThread(ReconnectTest.java:225)
{code}
There is a synchronization issue. {{latchCommit.countDown()}} in
{{beforeReconnect}} method is called before the thread is added to
{{threadToBeInterrupted}} list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-415) [Artemis Testsuite] NettyPagingSendTest#testPagingDoesNotDuplicateBatchMessages
[
https://issues.apache.org/jira/browse/ARTEMIS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-415.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite]
> NettyPagingSendTest#testPagingDoesNotDuplicateBatchMessages
> ---
>
> Key: ARTEMIS-415
> URL: https://issues.apache.org/jira/browse/ARTEMIS-415
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: expected:<20> but was:<13>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.activemq.artemis.tests.integration.paging.PagingSendTest.testPagingDoesNotDuplicateBatchMessages(PagingSendTest.java:242)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> 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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:275)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:149)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> This failure happens when {{Queue.deliverAsync}} is too slow and the iterator
> is created before that aforementioned method add references to internal
> structures.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-415) [Artemis Testsuite] NettyPagingSendTest#testPagingDoesNotDuplicateBatchMessages
Erich Duda created ARTEMIS-415:
--
Summary: [Artemis Testsuite]
NettyPagingSendTest#testPagingDoesNotDuplicateBatchMessages
Key: ARTEMIS-415
URL: https://issues.apache.org/jira/browse/ARTEMIS-415
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: expected:<20> but was:<13>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.integration.paging.PagingSendTest.testPagingDoesNotDuplicateBatchMessages(PagingSendTest.java:242)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:275)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:149)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
This failure happens when {{Queue.deliverAsync}} is too slow and the iterator
is created before that aforementioned method add references to internal
structures.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-414) [Artemis Testsuite] TemporaryQueueClusterTest#testClusteredQueue fails
[
https://issues.apache.org/jira/browse/ARTEMIS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-414.
Resolution: Fixed
> [Artemis Testsuite] TemporaryQueueClusterTest#testClusteredQueue fails
> --
>
> Key: ARTEMIS-414
> URL: https://issues.apache.org/jira/browse/ARTEMIS-414
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.junit.Assert.assertNotNull(Assert.java:631)
> at
> org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest.testClusteredQueue(TemporaryQueueClusterTest.java:75)
> {code}
> By default redistribution-delay is set to -1 which means that messages will
> never be redistributed. Solution is to set redistribution-delay to 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-414) [Artemis Testsuite] TemporaryQueueClusterTest#testClusteredQueue fails
Erich Duda created ARTEMIS-414:
--
Summary: [Artemis Testsuite]
TemporaryQueueClusterTest#testClusteredQueue fails
Key: ARTEMIS-414
URL: https://issues.apache.org/jira/browse/ARTEMIS-414
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
Fix For: 1.3.0
{code}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at org.junit.Assert.assertNotNull(Assert.java:631)
at
org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest.testClusteredQueue(TemporaryQueueClusterTest.java:75)
{code}
By default redistribution-delay is set to -1 which means that messages will
never be redistributed. Solution is to set redistribution-delay to 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-403) [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional fails
[
https://issues.apache.org/jira/browse/ARTEMIS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-403.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional
> fails
> ---
>
> Key: ARTEMIS-403
> URL: https://issues.apache.org/jira/browse/ARTEMIS-403
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> Test didn't complete successful, thread still running
> java.lang.AssertionError: Test didn't complete successful, thread still
> running
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.runTest(AsynchronousFailoverTest.java:188)
> at
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.testTransactional(AsynchronousFailoverTest.java:77)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> 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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-403) [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional fails
Erich Duda created ARTEMIS-403:
--
Summary: [Artemis Testsuite]
AlmostLargeAsynchronousFailoverTest#testTransactional fails
Key: ARTEMIS-403
URL: https://issues.apache.org/jira/browse/ARTEMIS-403
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
Test didn't complete successful, thread still running
java.lang.AssertionError: Test didn't complete successful, thread still running
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.runTest(AsynchronousFailoverTest.java:188)
at
org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.testTransactional(AsynchronousFailoverTest.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-396) [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails
[
https://issues.apache.org/jira/browse/ARTEMIS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-396.
Resolution: Fixed
Fix Version/s: 1.3.0
> [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails
> --
>
> Key: ARTEMIS-396
> URL: https://issues.apache.org/jira/browse/ARTEMIS-396
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.3.0
>
>
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.junit.Assert.assertNotNull(Assert.java:631)
> at
> org.apache.activemq.artemis.tests.integration.client.ReceiveTest.testReceiveImmediate(ReceiveTest.java:152)
> {code}
> Sending nondurable messages is not blocking by default. We have to ensure
> that all messages were received by server before we start consume them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-396) [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails
Erich Duda created ARTEMIS-396:
--
Summary: [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails
Key: ARTEMIS-396
URL: https://issues.apache.org/jira/browse/ARTEMIS-396
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at org.junit.Assert.assertNotNull(Assert.java:631)
at
org.apache.activemq.artemis.tests.integration.client.ReceiveTest.testReceiveImmediate(ReceiveTest.java:152)
{code}
Sending nondurable messages is not blocking by default. We have to ensure that
all messages were received by server before we start consume them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-287) [Artemis Testsuite] PagingTest#testDeleteQueueRestart fails on slower machines
[
https://issues.apache.org/jira/browse/ARTEMIS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-287.
Resolution: Fixed
Fix Version/s: 1.2.0
> [Artemis Testsuite] PagingTest#testDeleteQueueRestart fails on slower machines
> --
>
> Key: ARTEMIS-287
> URL: https://issues.apache.org/jira/browse/ARTEMIS-287
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> long timeout = System.currentTimeMillis() + 5000;
> // I want the buffer full to make sure there are pending messages on the
> server's side
> while (System.currentTimeMillis() < timeout && cons.getBufferSize() < 1000 &&
> cons2.getBufferSize() < 1000) {
> System.out.println("cons1 buffer = " + cons.getBufferSize() + ", cons2
> buffer = " + cons2.getBufferSize());
> Thread.sleep(100);
> }
> {code}
> On slower machines the 5 seconds timeout is too short.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-287) [Artemis Testsuite] PagingTest#testDeleteQueueRestart fails on slower machines
[
https://issues.apache.org/jira/browse/ARTEMIS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda reopened ARTEMIS-287:
The test still fails.
> [Artemis Testsuite] PagingTest#testDeleteQueueRestart fails on slower machines
> --
>
> Key: ARTEMIS-287
> URL: https://issues.apache.org/jira/browse/ARTEMIS-287
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Erich Duda
>
> {code}
> long timeout = System.currentTimeMillis() + 5000;
> // I want the buffer full to make sure there are pending messages on the
> server's side
> while (System.currentTimeMillis() < timeout && cons.getBufferSize() < 1000 &&
> cons2.getBufferSize() < 1000) {
> System.out.println("cons1 buffer = " + cons.getBufferSize() + ", cons2
> buffer = " + cons2.getBufferSize());
> Thread.sleep(100);
> }
> {code}
> On slower machines the 5 seconds timeout is too short.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-364) [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
[
https://issues.apache.org/jira/browse/ARTEMIS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-364.
Resolution: Fixed
> [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
> -
>
> Key: ARTEMIS-364
> URL: https://issues.apache.org/jira/browse/ARTEMIS-364
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.activemq.artemis.tests.integration.client.PagingTest.testPagingDifferentSizes(PagingTest.java:3576)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-365) [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails
[
https://issues.apache.org/jira/browse/ARTEMIS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-365.
Resolution: Fixed
> [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails
> -
>
> Key: ARTEMIS-365
> URL: https://issues.apache.org/jira/browse/ARTEMIS-365
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.activemq.artemis.tests.integration.management.AddressControlTest.testGetNumberOfPages(AddressControlTest.java:222)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-364) [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
[
https://issues.apache.org/jira/browse/ARTEMIS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda reopened ARTEMIS-364:
The test fails on 32-bit machines.
> [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
> -
>
> Key: ARTEMIS-364
> URL: https://issues.apache.org/jira/browse/ARTEMIS-364
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.activemq.artemis.tests.integration.client.PagingTest.testPagingDifferentSizes(PagingTest.java:3576)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-365) [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails
[
https://issues.apache.org/jira/browse/ARTEMIS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda reopened ARTEMIS-365:
The test still fails on 32 bit machines.
> [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails
> -
>
> Key: ARTEMIS-365
> URL: https://issues.apache.org/jira/browse/ARTEMIS-365
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.activemq.artemis.tests.integration.management.AddressControlTest.testGetNumberOfPages(AddressControlTest.java:222)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-381) [Artemis Testsuite] LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly fails
[
https://issues.apache.org/jira/browse/ARTEMIS-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-381.
Resolution: Fixed
Fix Version/s: 1.2.0
> [Artemis Testsuite]
> LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly fails
> -
>
> Key: ARTEMIS-381
> URL: https://issues.apache.org/jira/browse/ARTEMIS-381
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.junit.Assert.assertNotNull(Assert.java:631)
> at
> org.apache.activemq.artemis.tests.integration.jms.cluster.LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly(LargeMessageOverBridgeTest.java:210)
> {code}
> Problem is in redistribution-delay property which is defaul set on -1. It
> means that messages shouldn't be redistributed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-381) [Artemis Testsuite] LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly fails
Erich Duda created ARTEMIS-381:
--
Summary: [Artemis Testsuite]
LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly fails
Key: ARTEMIS-381
URL: https://issues.apache.org/jira/browse/ARTEMIS-381
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at org.junit.Assert.assertNotNull(Assert.java:631)
at
org.apache.activemq.artemis.tests.integration.jms.cluster.LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly(LargeMessageOverBridgeTest.java:210)
{code}
Problem is in redistribution-delay property which is defaul set on -1. It means
that messages shouldn't be redistributed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-377) [Artemis Testsuite] NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails
[
https://issues.apache.org/jira/browse/ARTEMIS-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-377.
Resolution: Fixed
Fix Version/s: 1.2.0
> [Artemis Testsuite]
> NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails
> ---
>
> Key: ARTEMIS-377
> URL: https://issues.apache.org/jira/browse/ARTEMIS-377
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> client VM did not exit cleanly expected:<0> but was:<1>
> java.lang.AssertionError: client VM did not exit cleanly expected:<0> but
> was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.doTestProducerConsumerClient(NettySecurityClientTest.java:96)
> at
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.testProducerConsumerClientWithSecurityManager(NettySecurityClientTest.java:45)
> {code}
> The test has two problems:
> 1. Method {{URL.getPath()}} encode special characters with {{%}} sign. We
> should use {{URLDecoder.decode()}} to decode these characters.
> 2. When we run the test with IBM JDK, the additional permission is needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-379) [Artemis Testsuite] BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails
[
https://issues.apache.org/jira/browse/ARTEMIS-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-379.
Resolution: Fixed
Fix Version/s: 1.2.0
> [Artemis Testsuite]
> BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails
>
>
> Key: ARTEMIS-379
> URL: https://issues.apache.org/jira/browse/ARTEMIS-379
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> backup started? (true). Finished synchronizing
> (org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
> SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
> java.lang.AssertionError: backup started? (true). Finished synchronizing
> (org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
> SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.activemq.artemis.tests.util.ActiveMQTestBase.waitForRemoteBackup(ActiveMQTestBase.java:1330)
> at
> org.apache.activemq.artemis.tests.integration.cluster.failover.BackupSyncJournalTest.testReserveFileIdValuesOnBackup(BackupSyncJournalTest.java:109)
> 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:497)
> 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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-379) [Artemis Testsuite] BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails
Erich Duda created ARTEMIS-379:
--
Summary: [Artemis Testsuite]
BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails
Key: ARTEMIS-379
URL: https://issues.apache.org/jira/browse/ARTEMIS-379
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
backup started? (true). Finished synchronizing
(org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
java.lang.AssertionError: backup started? (true). Finished synchronizing
(org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.activemq.artemis.tests.util.ActiveMQTestBase.waitForRemoteBackup(ActiveMQTestBase.java:1330)
at
org.apache.activemq.artemis.tests.integration.cluster.failover.BackupSyncJournalTest.testReserveFileIdValuesOnBackup(BackupSyncJournalTest.java:109)
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:497)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-377) [Artemis Testsuite] NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails
Erich Duda created ARTEMIS-377:
--
Summary: [Artemis Testsuite]
NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails
Key: ARTEMIS-377
URL: https://issues.apache.org/jira/browse/ARTEMIS-377
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
client VM did not exit cleanly expected:<0> but was:<1>
java.lang.AssertionError: client VM did not exit cleanly expected:<0> but
was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at
org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.doTestProducerConsumerClient(NettySecurityClientTest.java:96)
at
org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.testProducerConsumerClientWithSecurityManager(NettySecurityClientTest.java:45)
{code}
The test has two problems:
1. Method {{URL.getPath()}} encode special characters with {{%}} sign. We
should use {{URLDecoder.decode()}} to decode these characters.
2. When we run the test with IBM JDK, the additional permission is needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-369) [Artemis Testsuite] BridgeFailoverTest#testFailoverOnBridgeNoRetryOnSameNode fails
Erich Duda created ARTEMIS-369:
--
Summary: [Artemis Testsuite]
BridgeFailoverTest#testFailoverOnBridgeNoRetryOnSameNode fails
Key: ARTEMIS-369
URL: https://issues.apache.org/jira/browse/ARTEMIS-369
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
AMQ119007: Cannot connect to server(s). Tried with all available servers.
org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException: AMQ119007:
Cannot connect to server(s). Tried with all available servers.
at
org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:777)
at
org.apache.activemq.artemis.tests.integration.cluster.bridge.BridgeFailoverTest.internalTestFailoverOnBridge(BridgeFailoverTest.java:191)
at
org.apache.activemq.artemis.tests.integration.cluster.bridge.BridgeFailoverTest.testFailoverOnBridgeNoRetryOnSameNode(BridgeFailoverTest.java:96)
{code}
There is wrong wait condition. In the test we check if backup server started
after failover, but we should check whether backup server activated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-368) [Artemis Testsuite] TemporaryQueueTest#testBlockingWithTemporaryQueue fails
Erich Duda created ARTEMIS-368:
--
Summary: [Artemis Testsuite]
TemporaryQueueTest#testBlockingWithTemporaryQueue fails
Key: ARTEMIS-368
URL: https://issues.apache.org/jira/browse/ARTEMIS-368
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda
{code}
expected:<737> but was:<736>
java.lang.AssertionError: expected:<737> but was:<736>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.activemq.artemis.tests.integration.client.TemporaryQueueTest.testBlockingWithTemporaryQueue(TemporaryQueueTest.java:600)
{code}
There is while cycle which check whether producer is blocked and thus temporary
queue is full. Sometimes it can happen that producer spend all his credits too
fast and he is blocked because he waits to receive credits from server, but the
queue is not full. We have to ensure that the producer is blocked due to full
queue and it is not just temporary state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-364) [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
[
https://issues.apache.org/jira/browse/ARTEMIS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erich Duda resolved ARTEMIS-364.
Resolution: Fixed
Fix Version/s: 1.2.0
> [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
> -
>
> Key: ARTEMIS-364
> URL: https://issues.apache.org/jira/browse/ARTEMIS-364
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.activemq.artemis.tests.integration.client.PagingTest.testPagingDifferentSizes(PagingTest.java:3576)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
