[jira] [Assigned] (QPID-6916) Refactor system test suite to no longer assume exclusive use of port 15672 etc
[ https://issues.apache.org/jira/browse/QPID-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reassigned QPID-6916: -- Assignee: (was: Lorenz Quack) > Refactor system test suite to no longer assume exclusive use of port 15672 etc > -- > > Key: QPID-6916 > URL: https://issues.apache.org/jira/browse/QPID-6916 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall > Fix For: qpid-java-6.1 > > > Currently the system test suite assumes it may use certain ports, for > instance 15672. This is inflexible and means that running two test suites > concurrent is problematic. Both the Java and CPP Brokers have the ability to > allocate ports dynamically (port 0). > Change the system test suite to use port zero. > This change will have to accommodate both the Java and CPP Broker. > The simplicity, the Java BDB HA system tests will be excluded from the > initial scope. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6916) Refactor system test suite to no longer assume exclusive use of port 15672 etc
[ https://issues.apache.org/jira/browse/QPID-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062005#comment-15062005 ] ASF subversion and git services commented on QPID-6916: --- Commit 1720539 from [~lorenz.quack] in branch 'java/trunk' [ https://svn.apache.org/r1720539 ] QPID-6916: [SysTests] Refactor systest to allow running most tests on port 0 in parallel > Refactor system test suite to no longer assume exclusive use of port 15672 etc > -- > > Key: QPID-6916 > URL: https://issues.apache.org/jira/browse/QPID-6916 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Lorenz Quack > Fix For: qpid-java-6.1 > > > Currently the system test suite assumes it may use certain ports, for > instance 15672. This is inflexible and means that running two test suites > concurrent is problematic. Both the Java and CPP Brokers have the ability to > allocate ports dynamically (port 0). > Change the system test suite to use port zero. > This change will have to accommodate both the Java and CPP Broker. > The simplicity, the Java BDB HA system tests will be excluded from the > initial scope. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6916) Refactor system test suite to no longer assume exclusive use of port 15672 etc
[ https://issues.apache.org/jira/browse/QPID-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-6916: --- Status: Reviewable (was: In Progress) > Refactor system test suite to no longer assume exclusive use of port 15672 etc > -- > > Key: QPID-6916 > URL: https://issues.apache.org/jira/browse/QPID-6916 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Lorenz Quack > Fix For: qpid-java-6.1 > > > Currently the system test suite assumes it may use certain ports, for > instance 15672. This is inflexible and means that running two test suites > concurrent is problematic. Both the Java and CPP Brokers have the ability to > allocate ports dynamically (port 0). > Change the system test suite to use port zero. > This change will have to accommodate both the Java and CPP Broker. > The simplicity, the Java BDB HA system tests will be excluded from the > initial scope. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6951) [Java Client] AMQSession.deregisterConsumer() leaks Memory
[
https://issues.apache.org/jira/browse/QPID-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-6951:
-
Attachment: QPID-6951-fix.diff
> [Java Client] AMQSession.deregisterConsumer() leaks Memory
> --
>
> Key: QPID-6951
> URL: https://issues.apache.org/jira/browse/QPID-6951
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.32, qpid-java-6.0
>Reporter: Lorenz Quack
> Attachments: QPID-6951-fix.diff
>
>
> {{AMQSession.deregisterConsumer()}} contains the following code:
> {code}
> if (_transacted)
> {
> _removedConsumers.add(consumer);
> }
> {code}
> However, the {{_removedConsumers}} list is only cleaned up on rollback and
> nowhere else.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-6951) [Java Client] AMQSession.deregisterConsumer() leaks Memory
[
https://issues.apache.org/jira/browse/QPID-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-6951:
Assignee: Alex Rudyy
> [Java Client] AMQSession.deregisterConsumer() leaks Memory
> --
>
> Key: QPID-6951
> URL: https://issues.apache.org/jira/browse/QPID-6951
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.32, qpid-java-6.0
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Attachments: QPID-6951-fix.diff
>
>
> {{AMQSession.deregisterConsumer()}} contains the following code:
> {code}
> if (_transacted)
> {
> _removedConsumers.add(consumer);
> }
> {code}
> However, the {{_removedConsumers}} list is only cleaned up on rollback and
> nowhere else.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output
[
https://issues.apache.org/jira/browse/QPID-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062186#comment-15062186
]
Alex Rudyy commented on QPID-6953:
--
Rob,
Commit [r1720183|https://svn.apache.org/r1720183] broke message encryption on
0-10 path.
MessageEncryptionTest is failing constantly on 0-10 profile. 0-9 profile is Ok
{noformat}
Running org.apache.qpid.systest.messageencryption.MessageEncryptionTest
Tests run: 6, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 8.888 sec <<<
FAILURE! - in org.apache.qpid.systest.messageencryption.MessageEncryptionTest
testEncryptionFromBURLAddress(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.336 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testEncryptionFromBURLAddress(MessageEncryptionTest.java:169)
testEncryptionUsingMessageHeader(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.273 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testEncryptionUsingMessageHeader(MessageEncryptionTest.java:89)
testBrokerAsTrustStoreProvider(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.303 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testBrokerAsTrustStoreProvider(MessageEncryptionTest.java:211)
testEncryptionFromADDRAddress(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.298 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testEncryptionFromADDRAddress(MessageEncryptionTest.java:127)
{noformat}
> [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use
> QpidByteBuffer for encoding output
> -
>
> Key: QPID-6953
> URL: https://issues.apache.org/jira/browse/QPID-6953
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Currently many parts of the AMQP 0-8/9/9-1 codec offer two methods for
> encoding, one which uses a "DataOutput" object, and one which uses a
> QpidByteBuffer or ByteBufferSender. Examples of the former should be
> removed, and the latter used exclusively.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output
[
https://issues.apache.org/jira/browse/QPID-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062186#comment-15062186
]
Alex Rudyy edited comment on QPID-6953 at 12/17/15 3:37 PM:
Rob,
Commit [r1720183|https://svn.apache.org/r1720183] broke message encryption on
0-10 path.
MessageEncryptionTest is failing constantly on 0-10 profile. 0-9 profile is Ok
{noformat}
Running org.apache.qpid.systest.messageencryption.MessageEncryptionTest
Tests run: 6, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 8.888 sec <<<
FAILURE! - in org.apache.qpid.systest.messageencryption.MessageEncryptionTest
testEncryptionFromBURLAddress(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.336 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testEncryptionFromBURLAddress(MessageEncryptionTest.java:169)
testEncryptionUsingMessageHeader(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.273 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testEncryptionUsingMessageHeader(MessageEncryptionTest.java:89)
testBrokerAsTrustStoreProvider(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.303 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testBrokerAsTrustStoreProvider(MessageEncryptionTest.java:211)
testEncryptionFromADDRAddress(org.apache.qpid.systest.messageencryption.MessageEncryptionTest)
Time elapsed: 1.298 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at
org.apache.qpid.systest.messageencryption.MessageEncryptionTest.testEncryptionFromADDRAddress(MessageEncryptionTest.java:127)
{noformat}
NPE is reported in test logs
{noformat}
2015-12-17 15:24:17,136 ERROR [Dispatcher-1-Conn-10]
o.a.q.c.BasicMessageConsumer Caught exception (dump follows) - ignoring...
java.lang.NullPointerException: null
at
org.apache.qpid.client.message.AMQMessageDelegate_0_10.(AMQMessageDelegate_0_10.java:120)
~[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.message.AMQMessageDelegate_0_10.(AMQMessageDelegate_0_10.java:106)
~[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.message.Encrypted010MessageFactory.createMessage(Encrypted010MessageFactory.java:160)
~[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.message.AbstractJMSMessageFactory.create010MessageWithBody(AbstractJMSMessageFactory.java:177)
~[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.message.AbstractJMSMessageFactory.createMessage(AbstractJMSMessageFactory.java:198)
~[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.message.MessageFactoryRegistry.createMessage(MessageFactoryRegistry.java:160)
~[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.BasicMessageConsumer_0_10.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_10.java:212)
[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.BasicMessageConsumer_0_10.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_10.java:55)
[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:722)
~[qpid-client-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
at
[jira] [Commented] (QPID-6935) Infinite recursion resulting in huge number of Transfer objects created in Delivery, until OutOfMemory
[ https://issues.apache.org/jira/browse/QPID-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062404#comment-15062404 ] Leo Riguspi commented on QPID-6935: --- Hi Rob, the content in each transfer object seems to be different, at least for the ones we looked at. But there were 49000 Transfer objects in the previous heap dump and 115000 in the new one so it is not possible to say. The problem is that we can't even reproduce the error. We tried to inject several messages, even larger than 10MB. We took heap dumps after each message but can't see anything abnormal. Could the issue be in Camel's code? > Infinite recursion resulting in huge number of Transfer objects created in > Delivery, until OutOfMemory > -- > > Key: QPID-6935 > URL: https://issues.apache.org/jira/browse/QPID-6935 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 1.0 Client >Affects Versions: 0.32 > Environment: Linux RedHat 7 >Reporter: Leo Riguspi >Priority: Blocker > Attachments: Heap.png, Heap2.png, memory_dump.txt, snapshot1.png, > snapshot2.png > > > We have an Apache ActiveMQ 5.12 running for 2 months now and a Java AMQP > client publishing a few messages every few minutes. Messages are small, less > than 1K and are immediately consumed. > For the second time in two months the client exploded with an OutOfMemory > error. By analysing the memory the culprit seems to be the ArrayList of > Trasfer objects in the Delivery. All of a sudden, for some reason it just > keeps creating new Trasfers until the memory is full. > We have a screenshot of the memory dump in which there are more than 49000 > Trasfer objects in the same Delivery. Unfortunately there seems to be no way > to attach it to this issue. > We did not find a way to reproduce the problem but it looks like some > combination of conditions cause the SessionEndpoint::sendTransfer recursive > method to call itself over and over, each time adding a new Transfer object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-142) Clean up the IdGenerator used to create ID values for JMS resources
[ https://issues.apache.org/jira/browse/QPIDJMS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062378#comment-15062378 ] ASF subversion and git services commented on QPIDJMS-142: - Commit b14b3db9780bb5456ea06da00a79f18fa0a872c9 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=b14b3db ] QPIDJMS-142 remove the synchronized from the generate method as it is not needed any longer. > Clean up the IdGenerator used to create ID values for JMS resources > --- > > Key: QPIDJMS-142 > URL: https://issues.apache.org/jira/browse/QPIDJMS-142 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.7.0 > > > The current IdGenerator implementation uses some less than optimal logic to > create ID values for the JMS resources. We can streamline and simplify this > using UUID values with some optional additional identifying bits. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6935) Infinite recursion resulting in huge number of Transfer objects created in Delivery, until OutOfMemory
[ https://issues.apache.org/jira/browse/QPID-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062489#comment-15062489 ] Rob Godfrey commented on QPID-6935: --- Since the content is different my best guess is it is not the client causing the error when receiving, I struggle to see a way where the client could internally be generating multiple frames with differing content. I'd doubt that the error would be in Camel (though I'm not very familiar with that product) since I presume it is just managing the orchestration for receiving from Q1 and then republishing to Q2. I'd guess that the error was either in the message as it was sent into Q1 originally, or in the broker code that is serialising the message from Q1 and sending it to the client. I may be completely wrong though :) What might be useful is if you can build a patched version of the client which does something like checked to see if a delivery has more that 100 transfers added to it, and if so starts turning on debug protocol logging. > Infinite recursion resulting in huge number of Transfer objects created in > Delivery, until OutOfMemory > -- > > Key: QPID-6935 > URL: https://issues.apache.org/jira/browse/QPID-6935 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 1.0 Client >Affects Versions: 0.32 > Environment: Linux RedHat 7 >Reporter: Leo Riguspi >Priority: Blocker > Attachments: Heap.png, Heap2.png, memory_dump.txt, snapshot1.png, > snapshot2.png > > > We have an Apache ActiveMQ 5.12 running for 2 months now and a Java AMQP > client publishing a few messages every few minutes. Messages are small, less > than 1K and are immediately consumed. > For the second time in two months the client exploded with an OutOfMemory > error. By analysing the memory the culprit seems to be the ArrayList of > Trasfer objects in the Delivery. All of a sudden, for some reason it just > keeps creating new Trasfers until the memory is full. > We have a screenshot of the memory dump in which there are more than 49000 > Trasfer objects in the same Delivery. Unfortunately there seems to be no way > to attach it to this issue. > We did not find a way to reproduce the problem but it looks like some > combination of conditions cause the SessionEndpoint::sendTransfer recursive > method to call itself over and over, each time adding a new Transfer object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output
[ https://issues.apache.org/jira/browse/QPID-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062339#comment-15062339 ] Rob Godfrey commented on QPID-6953: --- Where/how are you seeing this? The Apache Jenkins instances look like they are passing on 0-10. Running locally on revision r1720340 I see no issues using mms.0-10 and bdb.0-10 profiles. > [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use > QpidByteBuffer for encoding output > - > > Key: QPID-6953 > URL: https://issues.apache.org/jira/browse/QPID-6953 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > Currently many parts of the AMQP 0-8/9/9-1 codec offer two methods for > encoding, one which uses a "DataOutput" object, and one which uses a > QpidByteBuffer or ByteBufferSender. Examples of the former should be > removed, and the latter used exclusively. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-199) Add Dockerfiles that launches the dispatch router inside a container for RHEL and Debian based systems
[ https://issues.apache.org/jira/browse/DISPATCH-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-199. Resolution: Fixed Fix Version/s: 0.6 > Add Dockerfiles that launches the dispatch router inside a container for RHEL > and Debian based systems > -- > > Key: DISPATCH-199 > URL: https://issues.apache.org/jira/browse/DISPATCH-199 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ganesh Murthy > Fix For: 0.6 > > > Add sample dockerfiles that launch dispatch router inside a docker container. > Create dockerfiles for RHEL and Debian based systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-199) Add Dockerfiles that launches the dispatch router inside a container for RHEL and Debian based systems
[ https://issues.apache.org/jira/browse/DISPATCH-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062635#comment-15062635 ] ASF GitHub Bot commented on DISPATCH-199: - Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/41 > Add Dockerfiles that launches the dispatch router inside a container for RHEL > and Debian based systems > -- > > Key: DISPATCH-199 > URL: https://issues.apache.org/jira/browse/DISPATCH-199 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ganesh Murthy > > Add sample dockerfiles that launch dispatch router inside a docker container. > Create dockerfiles for RHEL and Debian based systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-199) Add Dockerfiles that launches the dispatch router inside a container for RHEL and Debian based systems
[ https://issues.apache.org/jira/browse/DISPATCH-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062633#comment-15062633 ] ASF subversion and git services commented on DISPATCH-199: -- Commit a6d5be7b57c9943cd42a00ad7eedb0ff638c8354 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a6d5be7 ] DISPATCH-199 - Added dockerfiles that will help launch the dispatch router inside docker containers > Add Dockerfiles that launches the dispatch router inside a container for RHEL > and Debian based systems > -- > > Key: DISPATCH-199 > URL: https://issues.apache.org/jira/browse/DISPATCH-199 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ganesh Murthy > > Add sample dockerfiles that launch dispatch router inside a docker container. > Create dockerfiles for RHEL and Debian based systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-199 - Added dockerfiles that ...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/41 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 41456: Add message annotation support to the C++ bindings
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41456/#review111068 --- Ship it! Go ahead and commit it. I am going to make some changes but I will do the properties and annotations together when I do, meantime this works. Point me at the relevant interop test code and I'll update it when I get there. I note you just have annotations, I'm trying to figure out if we need separate delivery and message annotations. I don't see anything in the spec that allows you to distinguish them by key only so I suspect we might. - Alan Conway On Dec. 16, 2015, 7:12 p.m., Kim van der Riet wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41456/ > --- > > (Updated Dec. 16, 2015, 7:12 p.m.) > > > Review request for qpid and Alan Conway. > > > Repository: qpid-proton-git > > > Description > --- > > Qpid-interop-test needs to use annotations in the c++ bindings for JMS > messages which rely upon them for successfully identifying a message type. > This patch is the bare-bones only, there are no comments or tests. > > > Diffs > - > > proton-c/bindings/cpp/include/proton/message.hpp 0954b49 > proton-c/bindings/cpp/src/message.cpp dd57606 > > Diff: https://reviews.apache.org/r/41456/diff/ > > > Testing > --- > > Tested within qpid-interop-test for JMS message tests, works as expected. > > > Thanks, > > Kim van der Riet > >
[jira] [Commented] (QPID-6951) [Java Client] AMQSession.deregisterConsumer() leaks Memory
[
https://issues.apache.org/jira/browse/QPID-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062867#comment-15062867
]
ASF subversion and git services commented on QPID-6951:
---
Commit 1720664 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1720664 ]
QPID-6951: Stop tracking closed consumers and remove dead code trying to
release pending messages on closed consumers as corresponidng queue is already
cleared on consumer close
> [Java Client] AMQSession.deregisterConsumer() leaks Memory
> --
>
> Key: QPID-6951
> URL: https://issues.apache.org/jira/browse/QPID-6951
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.32, qpid-java-6.0
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Attachments: QPID-6951-fix.diff
>
>
> {{AMQSession.deregisterConsumer()}} contains the following code:
> {code}
> if (_transacted)
> {
> _removedConsumers.add(consumer);
> }
> {code}
> However, the {{_removedConsumers}} list is only cleaned up on rollback and
> nowhere else.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-143) What Qpid AMQP 1.0 client to use?
[ https://issues.apache.org/jira/browse/QPIDJMS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Soderquist updated QPIDJMS-143: Description: Over the months I have found at least four Qpid client libraries that could be used to implement a Java AMQP 1.0 client. My challenge is knowing what I should use. I'm not sure what clients will be supported and some of them I have yet to get to work. I will list the libraries by their Maven artifact id: qpid-jms-client: Found easily on the Qpid web site. I have been able to send, but not receive messages. proton-j: Looks great. API looks simple. I have never been able to send or receive messages. qpid-amqp-1-0-client: This is the library I have used for non-JMS implementations. I have been able to both send and receive messages. It performs well but appears to not be supported after version 0.32. qpid-amqp-1-0-client-jms: This is the library I have used for JMS implementations. I have been able to both send and receive messages. It performs well but appears to not be supported after version 0.32. I'm just trying to understand what works today and what direction Qpid client development is going. I don't want to be using something that doesn't work but I also don't want to use something that is deprecated. was: Over the months I have found at least four Qpid client libraries that could be used to implement a Java AMQP 1.0 client. My challenge is knowing what I should use. I'm not sure what clients will be supported and some of them I have yet to get to work. I will list the libraries by their Maven artifact id: qpid-jms-client: Found easily on the Qpid web site. I have been able to send, but not receive messages. proton-j: Looks great. API looks simple. I have never been able to send or receive messages. qpid-amqp-1-0-client: This is the library I have used for non-JMS implementations. I have been able to both send and receive messages. It performs well but appears to not be supported after version 0.32. qpid-amqp-1-0-client-jms: This is the library I have used for JMS implementations. I have been able to both send and receive messages. It performs well but appears to not be supported after version 0.32. I'm just trying to understand what works today and what direction Qpid client development is going. I don't want to be using something that doesn't work but I also don't want to use something that is deprecated. > What Qpid AMQP 1.0 client to use? > - > > Key: QPIDJMS-143 > URL: https://issues.apache.org/jira/browse/QPIDJMS-143 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Mark Soderquist > > Over the months I have found at least four Qpid client libraries that could > be used to implement a Java AMQP 1.0 client. My challenge is knowing what I > should use. I'm not sure what clients will be supported and some of them I > have yet to get to work. I will list the libraries by their Maven artifact id: > qpid-jms-client: Found easily on the Qpid web site. I have been able to send, > but not receive messages. > proton-j: Looks great. API looks simple. I have never been able to send or > receive messages. > qpid-amqp-1-0-client: This is the library I have used for non-JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > qpid-amqp-1-0-client-jms: This is the library I have used for JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > I'm just trying to understand what works today and what direction Qpid client > development is going. I don't want to be using something that doesn't work > but I also don't want to use something that is deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDJMS-143) What Qpid AMQP 1.0 client to use?
[ https://issues.apache.org/jira/browse/QPIDJMS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed QPIDJMS-143. Resolution: Invalid JIRA is not really the place to ask project related questions, please use the mailing lists instead: https://qpid.apache.org/discussion.html > What Qpid AMQP 1.0 client to use? > - > > Key: QPIDJMS-143 > URL: https://issues.apache.org/jira/browse/QPIDJMS-143 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Mark Soderquist > > Over the months I have found at least four Qpid client libraries that could > be used to implement a Java AMQP 1.0 client. My challenge is knowing what I > should use. I'm not sure what clients will be supported and some of them I > have yet to get to work. I will list the libraries by their Maven artifact id: > qpid-jms-client: Found easily on the Qpid web site. I have been able to send, > but not receive messages. > proton-j: Looks great. API looks simple. I have never been able to send or > receive messages. > qpid-amqp-1-0-client: This is the library I have used for non-JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > qpid-amqp-1-0-client-jms: This is the library I have used for JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > I'm just trying to understand what works today and what direction Qpid client > development is going. I don't want to be using something that doesn't work > but I also don't want to use something that is deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-144) Transport resources need to be more proactively cleaned up on failed operations.
Timothy Bish created QPIDJMS-144: Summary: Transport resources need to be more proactively cleaned up on failed operations. Key: QPIDJMS-144 URL: https://issues.apache.org/jira/browse/QPIDJMS-144 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.6.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.7.0 During SSL handshake as well as some other cases we should ensure that transport resources get cleaned up in a timely manner. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-143) What Qpid AMQP 1.0 client to use?
[ https://issues.apache.org/jira/browse/QPIDJMS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063035#comment-15063035 ] Timothy Bish commented on QPIDJMS-143: -- Thanks for popping that answer in here Rob, was hoping that when this question hit the mailing list (looks like is has now) you'd offer some history on the older JMS client bits. :) > What Qpid AMQP 1.0 client to use? > - > > Key: QPIDJMS-143 > URL: https://issues.apache.org/jira/browse/QPIDJMS-143 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Mark Soderquist > > Over the months I have found at least four Qpid client libraries that could > be used to implement a Java AMQP 1.0 client. My challenge is knowing what I > should use. I'm not sure what clients will be supported and some of them I > have yet to get to work. I will list the libraries by their Maven artifact id: > qpid-jms-client: Found easily on the Qpid web site. I have been able to send, > but not receive messages. > proton-j: Looks great. API looks simple. I have never been able to send or > receive messages. > qpid-amqp-1-0-client: This is the library I have used for non-JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > qpid-amqp-1-0-client-jms: This is the library I have used for JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > I'm just trying to understand what works today and what direction Qpid client > development is going. I don't want to be using something that doesn't work > but I also don't want to use something that is deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-144) Transport resources need to be more proactively cleaned up on failed operations.
[ https://issues.apache.org/jira/browse/QPIDJMS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-144: - Description: During SSL handshake failures as well as some other cases we should ensure that transport resources get cleaned up in a timely manner. (was: During SSL handshake as well as some other cases we should ensure that transport resources get cleaned up in a timely manner. ) > Transport resources need to be more proactively cleaned up on failed > operations. > > > Key: QPIDJMS-144 > URL: https://issues.apache.org/jira/browse/QPIDJMS-144 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.7.0 > > > During SSL handshake failures as well as some other cases we should ensure > that transport resources get cleaned up in a timely manner. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-143) What Qpid AMQP 1.0 client to use?
[ https://issues.apache.org/jira/browse/QPIDJMS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063022#comment-15063022 ] Rob Godfrey commented on QPIDJMS-143: - I note [~tabish121] has already marked this as invalid, and suggested mailing the list... but since I'd already typed up this reply, I'll post this here anyway :-) Hi Mark, As you note, the future direction within Qpid is the qpid-jms-client which itself is built on top of the proton-j libraries. (Proton itself has multiple sub-components / APIs which are IMHO a little confusing in their multitude, and their target audience. People talking about the proton API may be meaning Messenger, the Engine API or the Reactive API ... or something else :-) ) While we are not planning any future feature releases for the qpid-amqp-1-0-client / qpid-amqp-1-0-client-jms, I'm open to releasing bug-fixes / small enhancements if there is demand... I can certainly see us doing an 0.32.1, 0.32.2 etc. In terms of history, the qpid-amqp-1-0-client grew out of prototyping work that I was doing as part of the evolution of AMQP 1.0 - I'd never really planned on releasing it to the wider world (and the (lack of) design testifies to that). As part of proving out AMQP 1.0 we also want to demonstrate that we could implement JMS on top of AMQP, so I took the prototyping work I had done and wrapped another library around it to create the qpid-amqp-1-0-client-jms... again, I'd not really imagined releasing or maintaining this... however in the way of these things there was an obvious and immediate demand for Java / JMS support for AMQP ... and since I had this code lying around and people wanted it immediately, I contributed it to the Apache Qpid project. At the same time, the Qpid project was defining how it wanted to support AMQP 1.0 development, and the concept there was to build a small reusable library which could be integrated into many platforms (not just Qpid) and available in multiple languages (not just Java). This became Apache Qpid Proton. Since this is where the project sees the future in terms of AMQP 1.0 support, we also looked to build a JMS compliant library on top of the Proton underpinnings. After the 0.32 release we believed that the functionality in the qpid-jms-client was generally comparable to what was available in the qpid-amqp-1-0-client-jms and as such we decided to guide users to qpid-jms-client. Releases of the new client are *far* more frequent than of the older client, and where functionality is missing, or bugs are discovered you should see a far quicker turn-around time thanks to the great work of [~gemmellr] and [~tabish121]]. I'm not sure if there is a preferred non-JMS Java API... I'll let others speak to that point. > What Qpid AMQP 1.0 client to use? > - > > Key: QPIDJMS-143 > URL: https://issues.apache.org/jira/browse/QPIDJMS-143 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Mark Soderquist > > Over the months I have found at least four Qpid client libraries that could > be used to implement a Java AMQP 1.0 client. My challenge is knowing what I > should use. I'm not sure what clients will be supported and some of them I > have yet to get to work. I will list the libraries by their Maven artifact id: > qpid-jms-client: Found easily on the Qpid web site. I have been able to send, > but not receive messages. > proton-j: Looks great. API looks simple. I have never been able to send or > receive messages. > qpid-amqp-1-0-client: This is the library I have used for non-JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > qpid-amqp-1-0-client-jms: This is the library I have used for JMS > implementations. I have been able to both send and receive messages. It > performs well but appears to not be supported after version 0.32. > I'm just trying to understand what works today and what direction Qpid client > development is going. I don't want to be using something that doesn't work > but I also don't want to use something that is deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-144) Transport resources need to be more proactively cleaned up on failed operations.
[ https://issues.apache.org/jira/browse/QPIDJMS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063063#comment-15063063 ] ASF subversion and git services commented on QPIDJMS-144: - Commit f89097978785ff03b1b45a53c0441c488b68eaf6 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=f890979 ] QPIDJMS-144 Add some more clenaup code in the failure cases. > Transport resources need to be more proactively cleaned up on failed > operations. > > > Key: QPIDJMS-144 > URL: https://issues.apache.org/jira/browse/QPIDJMS-144 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.7.0 > > > During SSL handshake failures as well as some other cases we should ensure > that transport resources get cleaned up in a timely manner. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
