Converting Qpid Broker configuration from older versions to new
Hello, I am in the process of upgrading the Qpid Broker version that my organization is using from 0.32 to 7.0.6. I know this is quite a big jump. A former employee already did some of the work to upgrade to 6.0.5, but we never finished the upgrade before he left, and now we want to upgrade to 7.0.6. I mention this because we don't have adequate testing around the configuration for 6.0.5, so the most well-known, stable configuration that we have is for 0.32. Do you provide tools for converting the JSON configuration from older versions to newer versions? Thanks, Brian O'Shea -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Apache Qpid JMS 0.37.0
On 09/28/2018 01:32 PM, Robbie Gemmell wrote: Hi folks, I have put together a spin for a 0.37.0 Qpid JMS client release, please give it a test out and vote accordingly. The source and binary archives can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/jms/0.37.0-rc1/ The maven artifacts are also staged for now at: https://repository.apache.org/content/repositories/orgapacheqpid-1159 The JIRAs assigned are: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524&version=12343889 Regards, Robbie P.S. If you want to test it out using maven (e.g with the examples src, or your own things), you can temporarily add this to your poms to access the staging repo: staging https://repository.apache.org/content/repositories/orgapacheqpid-1159 The dependency for the client itself would then be: org.apache.qpid qpid-jms-client 0.37.0 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org +1 * Checked for license and notice files in archives * Validated signatures and checksums * Built from source and ran the tests * Built ActiveMQ 5.x master using staged artifacts and ran the AMQP tests * Built ActiveMQ Artemis 2.6.3 using staged artifacts and ran the AMQP tests -- Tim Bish - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Apache Qpid JMS 0.37.0
On Fri, 28 Sep 2018 at 18:32, Robbie Gemmell wrote: > > Hi folks, > > I have put together a spin for a 0.37.0 Qpid JMS client release, > please give it a test out and vote accordingly. > > The source and binary archives can be grabbed from: > https://dist.apache.org/repos/dist/dev/qpid/jms/0.37.0-rc1/ > > The maven artifacts are also staged for now at: > https://repository.apache.org/content/repositories/orgapacheqpid-1159 > > The JIRAs assigned are: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524&version=12343889 > > Regards, > Robbie > > P.S. If you want to test it out using maven (e.g with the examples > src, or your own things), you can temporarily add this to your poms to > access the staging repo: > > > > staging > > https://repository.apache.org/content/repositories/orgapacheqpid-1159 > > > > The dependency for the client itself would then be: > > > org.apache.qpid > qpid-jms-client > 0.37.0 > +1 I checked things over as follows: - Verified the sig and checksum files. - Checked LICENCE and NOTICE files in the archives. - Ran mvn apache-rat:check to check licence headers in source archive. - Ran the source build and tests. - Built Qpid Broker-J master using the staging repo and ran the systests. - Built ActiveMQ 5.x master using the staging repo and ran the AMQP tests. - Built a modified ActiveMQ Artemis 2.6.3 with the repo, ran the AMQP tests. - Ran the HelloWorld example against Qpid Broker-J master, Qpid Dispatch 1.3.0, and Qpid C++ broker 1.38.0. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[VOTE] Release Apache Qpid JMS 0.37.0
Hi folks, I have put together a spin for a 0.37.0 Qpid JMS client release, please give it a test out and vote accordingly. The source and binary archives can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/jms/0.37.0-rc1/ The maven artifacts are also staged for now at: https://repository.apache.org/content/repositories/orgapacheqpid-1159 The JIRAs assigned are: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524&version=12343889 Regards, Robbie P.S. If you want to test it out using maven (e.g with the examples src, or your own things), you can temporarily add this to your poms to access the staging repo: staging https://repository.apache.org/content/repositories/orgapacheqpid-1159 The dependency for the client itself would then be: org.apache.qpid qpid-jms-client 0.37.0 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Send timeout in proton C++
On 28/09/18 16:26, Gordon Sim wrote: On 28/09/18 16:13, HADI Ali wrote: The action I want to take is to stop the send. Ah, that I'm afraid cannot be done. Is there a way other than stopping the container to do this ? Even stopping the container won't actually 'stop' the send, it will just prevent processing of any acknowledgement if it does arrive. That last clause is a little clumsily worded. What I mean is that if the transfer has already been sent and you are just waiting for the ack, then stopping the container will just stop waiting for the ack. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Send timeout in proton C++
On 28/09/18 16:13, HADI Ali wrote: The action I want to take is to stop the send. Ah, that I'm afraid cannot be done. Is there a way other than stopping the container to do this ? Even stopping the container won't actually 'stop' the send, it will just prevent processing of any acknowledgement if it does arrive. (You *can* set a TTL on the message, but once transferred you can't cancel it in anyway; the protocol has no support for that). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Send timeout in proton C++
The action I want to take is to stop the send. Is there a way other than stopping the container to do this ? For example, during the receive, we are using the drain function after the timeout to stop receiving. Thanks, Ali -Original Message- From: Gordon Sim Sent: vendredi 28 septembre 2018 13:00 To: users@qpid.apache.org Subject: Re: Send timeout in proton C++ On 28/09/18 10:49, ali hadi wrote: > Hello, > > > > Our messaging topology uses a dispatch-router in front of many Java brokers. > > In the case where all our brokers are down, we want to throw an > exception to the producer after a timeout. This is not possible with > the idle-timeout parameter since the producer is connected to the > dispatch router which is still responding. > > Is there an equivalent to the JMS send timeout parameter or a way to > not let the producer hanging forever in proton C++? No, but you can implement a timeout like that using the schedule() method on the container. On sending a message, schedule a check on the return tracker after the appropriate timeout. If when that fire the delivery the tracker refers to has not been settled, you can take whatever action needed to handle the timeout. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org *** This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Problems building dispatch-router 1.3.0
On Fri, Sep 28, 2018 at 6:07 AM Rabih M wrote:
> Hello,
>
> We are trying to build the latest released version of the dispatch router
> 1.3.0.
> We are using redhat OS (2.6.32-358.el6.x86_64 GNU/Linux), GCC 4.9.2 and
> Python
> 2.7.8.
>
What operating system and version are you using?
Thanks.
>
> And we have 2 failing unit tests:
>
> system_tests_two_routers:
>
>
>
> [linux] 30: FAIL: test_10_propagated_disposition
> (system_tests_two_routers.TwoRouterTest)
>
> [linux] 30:
>
> [linux] 30: Traceback (most recent call last):
>
> [linux] 30: File
>
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_two_routers.py",
> line 191, in test_10_propagated_disposition
>
> [linux] 30: test.run()
>
> [linux] 30: File
>
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_two_routers.py",
> line 1229, in run
>
> [linux] 30: self.test.assertEqual(['accept', 'reject'],
> sorted(self.settled))
>
> [linux] 30: AssertionError: Lists differ: [u'accept', u'reject'] !=
> [u'reject']
>
> [linux] 30:
>
> [linux] 30: First differing element 0:
>
> [linux] 30: accept
>
> [linux] 30: reject
>
> [linux] 30:
>
> [linux] 30: First list contains 1 additional elements.
>
> [linux] 30: First extra element 1:
>
> [linux] 30: reject
>
> [linux] 30:
>
> [linux] 30: - [u'accept', u'reject']
>
> [linux] 30: + [u'reject']
>
> [linux] 30:
>
>
> And system_tests_console :
>
>
>
> Test command: /opt/rh/python27/root/usr/bin/python
> ".../dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-x"
> "unit2" "-v" "system_tests_console"
>
> [linux] 48: Test timeout computed to be: 1500
>
> [linux] 48: ERROR
>
> [linux] 48:
>
> [linux] 48: =
>
> [linux] 48: ERROR: setUpClass (system_tests_console.ConsoleTest)
>
> [linux] 48: -
>
> [linux] 48: Traceback (most recent call last):
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_console.py",
> line 45, in setUpClass
>
> [linux] 48: cls.router = cls.tester.qdrouterd('test-router', config)
>
> [linux] 48: File
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 557, in qdrouterd
>
> [linux] 48: return self.cleanup(Qdrouterd(*args, **kwargs))
>
> [linux] 48: File
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 352, in __init__
>
> [linux] 48: self.wait_ready()
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 478, in wait_ready
>
> [linux] 48: self.wait_ports(**retry_kwargs)
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 463, in wait_ports
>
> [linux] 48: wait_ports(self.ports_family, **retry_kwargs)
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 185, in wait_ports
>
> [linux] 48: wait_port(port=port, protocol_family=protocol_family,
> **retry_kwargs)
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 177, in wait_port
>
> [linux] 48: raise Exception("wait_port timeout on host %s port %s:
> %s"%(host, port, e))
>
> [linux] 48: Exception: wait_port timeout on host 127.0.0.1 port 27703:
> [Errno 111] Connection refused
>
>
> Any idea why this is happening?
>
> Best regards,
> Rabih
>
Re: Problems building dispatch-router 1.3.0
Were there any core dumps in the test directories?
On Fri, Sep 28, 2018 at 6:07 AM Rabih M wrote:
> Hello,
>
> We are trying to build the latest released version of the dispatch router
> 1.3.0.
> We are using redhat OS (2.6.32-358.el6.x86_64 GNU/Linux), GCC 4.9.2 and
> Python
> 2.7.8.
>
> And we have 2 failing unit tests:
>
> system_tests_two_routers:
>
>
>
> [linux] 30: FAIL: test_10_propagated_disposition
> (system_tests_two_routers.TwoRouterTest)
>
> [linux] 30:
>
> [linux] 30: Traceback (most recent call last):
>
> [linux] 30: File
>
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_two_routers.py",
> line 191, in test_10_propagated_disposition
>
> [linux] 30: test.run()
>
> [linux] 30: File
>
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_two_routers.py",
> line 1229, in run
>
> [linux] 30: self.test.assertEqual(['accept', 'reject'],
> sorted(self.settled))
>
> [linux] 30: AssertionError: Lists differ: [u'accept', u'reject'] !=
> [u'reject']
>
> [linux] 30:
>
> [linux] 30: First differing element 0:
>
> [linux] 30: accept
>
> [linux] 30: reject
>
> [linux] 30:
>
> [linux] 30: First list contains 1 additional elements.
>
> [linux] 30: First extra element 1:
>
> [linux] 30: reject
>
> [linux] 30:
>
> [linux] 30: - [u'accept', u'reject']
>
> [linux] 30: + [u'reject']
>
> [linux] 30:
>
>
> And system_tests_console :
>
>
>
> Test command: /opt/rh/python27/root/usr/bin/python
> ".../dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-x"
> "unit2" "-v" "system_tests_console"
>
> [linux] 48: Test timeout computed to be: 1500
>
> [linux] 48: ERROR
>
> [linux] 48:
>
> [linux] 48: =
>
> [linux] 48: ERROR: setUpClass (system_tests_console.ConsoleTest)
>
> [linux] 48: -
>
> [linux] 48: Traceback (most recent call last):
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_console.py",
> line 45, in setUpClass
>
> [linux] 48: cls.router = cls.tester.qdrouterd('test-router', config)
>
> [linux] 48: File
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 557, in qdrouterd
>
> [linux] 48: return self.cleanup(Qdrouterd(*args, **kwargs))
>
> [linux] 48: File
> ".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 352, in __init__
>
> [linux] 48: self.wait_ready()
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 478, in wait_ready
>
> [linux] 48: self.wait_ports(**retry_kwargs)
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 463, in wait_ports
>
> [linux] 48: wait_ports(self.ports_family, **retry_kwargs)
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 185, in wait_ports
>
> [linux] 48: wait_port(port=port, protocol_family=protocol_family,
> **retry_kwargs)
>
> [linux] 48: File
>
> "/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
> line 177, in wait_port
>
> [linux] 48: raise Exception("wait_port timeout on host %s port %s:
> %s"%(host, port, e))
>
> [linux] 48: Exception: wait_port timeout on host 127.0.0.1 port 27703:
> [Errno 111] Connection refused
>
>
> Any idea why this is happening?
>
> Best regards,
> Rabih
>
Re: Send timeout in proton C++
On 28/09/18 10:49, ali hadi wrote: Hello, Our messaging topology uses a dispatch-router in front of many Java brokers. In the case where all our brokers are down, we want to throw an exception to the producer after a timeout. This is not possible with the idle-timeout parameter since the producer is connected to the dispatch router which is still responding. Is there an equivalent to the JMS send timeout parameter or a way to not let the producer hanging forever in proton C++? No, but you can implement a timeout like that using the schedule() method on the container. On sending a message, schedule a check on the return tracker after the appropriate timeout. If when that fire the delivery the tracker refers to has not been settled, you can take whatever action needed to handle the timeout. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Problems building dispatch-router 1.3.0
Hello,
We are trying to build the latest released version of the dispatch router
1.3.0.
We are using redhat OS (2.6.32-358.el6.x86_64 GNU/Linux), GCC 4.9.2 and Python
2.7.8.
And we have 2 failing unit tests:
system_tests_two_routers:
[linux] 30: FAIL: test_10_propagated_disposition
(system_tests_two_routers.TwoRouterTest)
[linux] 30:
[linux] 30: Traceback (most recent call last):
[linux] 30: File
".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_two_routers.py",
line 191, in test_10_propagated_disposition
[linux] 30: test.run()
[linux] 30: File
".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_two_routers.py",
line 1229, in run
[linux] 30: self.test.assertEqual(['accept', 'reject'],
sorted(self.settled))
[linux] 30: AssertionError: Lists differ: [u'accept', u'reject'] !=
[u'reject']
[linux] 30:
[linux] 30: First differing element 0:
[linux] 30: accept
[linux] 30: reject
[linux] 30:
[linux] 30: First list contains 1 additional elements.
[linux] 30: First extra element 1:
[linux] 30: reject
[linux] 30:
[linux] 30: - [u'accept', u'reject']
[linux] 30: + [u'reject']
[linux] 30:
And system_tests_console :
Test command: /opt/rh/python27/root/usr/bin/python
".../dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-x"
"unit2" "-v" "system_tests_console"
[linux] 48: Test timeout computed to be: 1500
[linux] 48: ERROR
[linux] 48:
[linux] 48: =
[linux] 48: ERROR: setUpClass (system_tests_console.ConsoleTest)
[linux] 48: -
[linux] 48: Traceback (most recent call last):
[linux] 48: File
"/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_tests_console.py",
line 45, in setUpClass
[linux] 48: cls.router = cls.tester.qdrouterd('test-router', config)
[linux] 48: File
".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
line 557, in qdrouterd
[linux] 48: return self.cleanup(Qdrouterd(*args, **kwargs))
[linux] 48: File
".../dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
line 352, in __init__
[linux] 48: self.wait_ready()
[linux] 48: File
"/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
line 478, in wait_ready
[linux] 48: self.wait_ports(**retry_kwargs)
[linux] 48: File
"/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
line 463, in wait_ports
[linux] 48: wait_ports(self.ports_family, **retry_kwargs)
[linux] 48: File
"/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
line 185, in wait_ports
[linux] 48: wait_port(port=port, protocol_family=protocol_family,
**retry_kwargs)
[linux] 48: File
"/data/jenkins-slave/home/workspace/proton-acceptance/dispatch-workspace/qpid-dispatch-1.3.0/tests/system_test.py",
line 177, in wait_port
[linux] 48: raise Exception("wait_port timeout on host %s port %s:
%s"%(host, port, e))
[linux] 48: Exception: wait_port timeout on host 127.0.0.1 port 27703:
[Errno 111] Connection refused
Any idea why this is happening?
Best regards,
Rabih
Send timeout in proton C++
Hello, Our messaging topology uses a dispatch-router in front of many Java brokers. In the case where all our brokers are down, we want to throw an exception to the producer after a timeout. This is not possible with the idle-timeout parameter since the producer is connected to the dispatch router which is still responding. Is there an equivalent to the JMS send timeout parameter or a way to not let the producer hanging forever in proton C++? Regards, Ali
Re: Qpid C++ session.release behavior
On 28/09/18 04:07, msharee9 wrote: Hi A quick question abiut the release method. The API doc says that the broker MAY redeliver a released message. Does this mean the message is not guaranteed to be redelivered? That depends on the broker being used. For the c++ broker, at present it will always be delivered. In theory it could eventually decide to dead-letter the message, but in practice the c++ broker does not do that at this time. What is the behavior of broker in case of multiple consumers trying to fetch from the same queue when broker redelivers a released message from one of the consumers? Again that depends on the broker being used. The c++ broker will effectively return the message to the queue to be consumed by any of the currently active consumers. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Qpid C++ session.release behavior
Hi A quick question abiut the release method. The API doc says that the broker MAY redeliver a released message. Does this mean the message is not guaranteed to be redelivered? What is the behavior of broker in case of multiple consumers trying to fetch from the same queue when broker redelivers a released message from one of the consumers? -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
