Re: qpid-cpp-0.35 errors

On 05/11/18 20:57, rammohan ganapavarapu wrote: Actually there are no messages in queue, all they messages got consumed by consumer. But it still will not enqueue any further messages? Can you reproduce this easily? One other suggestion is to try with the linear store rather than the

Re: qpid-cpp-0.35 errors

On 30/10/18 18:59, rammohan ganapavarapu wrote: There are two more error from my original post, can some one help me to understand when qpid throws these error? 1. 1. 2018-10-22 08:05:30 [Broker] error Channel exception: not-attached: Channel 0 is not attached

Re: [RESULT] [VOTE] Release Apache Qpid Dispatch 1.4.1

On 30/10/18 00:10, Ganesh Murthy wrote: There were 6 binding +1 votes and no other votes. The vote has passed. I will add the files to the dist release repo and create the final tag shortly. The website will be updated after the release has had time to sync to the mirrors. Thanks to everybody

Re: qpid-cpp-0.35 errors

On 29/10/18 21:45, rammohan ganapavarapu wrote: I will try to produce, do have any suggestions on what to check in trace logs? for qpidd, adding --log-enable trace+:Network to whatever other logging options you have should do it

Re: queue paging

On 29/10/18 20:41, rammohan ganapavarapu wrote: Now i understand your earlier statement " *Messages that are larger than a single page are not supported at present*" since paging uses OS page size (4096) and default page factor is 1, if my message is bigger than this it will throw error message

Re: queue paging

On 29/10/18 18:21, rammohan ganapavarapu wrote: On Mon, Oct 29, 2018 at 10:00 AM Gordon Sim wrote: On 28/10/18 02:23, rammohan ganapavarapu wrote: Hi, I have create a durable queue with following arguments: qpid.paging=True durable=true qpid.max_pages_loaded=10 qpid.page_factor=1 so

Re: queue paging

On 28/10/18 02:23, rammohan ganapavarapu wrote: Hi, I have create a durable queue with following arguments: qpid.paging=True durable=true qpid.max_pages_loaded=10 qpid.page_factor=1 so this means my broker will keep 10 * 4028 = 4kb worth of messages (un consumed) in the memory and offload the

Re: qpid-cpp-0.35 errors

On 26/10/18 00:44, rammohan ganapavarapu wrote: Any idea when do we see this error? In AMQP 0-10, the connection-close frame allows an informational message (replyText) to be included. This must be less than 256 bytes. It sounds like something is either trying to exceed that, or succeeding

Re: [VOTE] Release Qpid Dispatch Router 1.4.1 (RC3)

On 25/10/18 14:59, Ganesh Murthy wrote: Hello All, Please cast your vote on this thread to release RC3 as the official Qpid Dispatch Router version 1.4.1. RC3 of Qpid Dispatch Router version 1.4.1 can be found here: https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.4.1-rc3/

Re: [VOTE CANCELED] Release Qpid Dispatch Router 1.4.1 (RC2)

On 25/10/18 14:56, Ganesh Murthy wrote: I am canceling the vote for Qpid Dispatch Router 1.4.1 (RC2) due a memory leak that was discovered. Here is the JIRA which details the problem - https://issues.apache.org/jira/browse/DISPATCH-1157 I will put out a vote shortly for 1.4.1 RC3 which will

Re: [VOTE] Release Qpid Dispatch Router 1.4.1 (RC2)

On 23/10/18 15:58, Gordon Sim wrote: On 23/10/18 15:42, Ganesh Murthy wrote: Hello All,   Please cast your vote on this thread to release RC2 as the official Qpid Dispatch Router version  1.4.1. RC2 of Qpid Dispatch Router version 1.4.1 can be found here: https://dist.apache.org

Re: Go Electron: Large Messages Fail To Send

On 24/10/18 11:35, rk wrote: OK thanks. I can get a capture of the wire output is there anything in particular I should be looking for that might cause this behaviour? More than one thread trying to operate on the same underlying proton connection would certainly cause problems. It could be

Re: [VOTE] Release Apache Qpid C++ 1.39.0

On 22/10/18 13:47, Justin Ross wrote: Hi, everyone. Please test this release candidate and vote based on what you find. Source archive and signatures: https://dist.apache.org/repos/dist/dev/qpid/cpp/1.39.0-rc1/ Issues:

Re: [VOTE] Release Apache Qpid C++ 1.39.0

On 22/10/18 19:03, Gordon Sim wrote: On 22/10/18 13:47, Justin Ross wrote: Hi, everyone.  Please test this release candidate and vote based on what you find. Source archive and signatures: https://dist.apache.org/repos/dist/dev/qpid/cpp/1.39.0-rc1/ I am seeing failures in the 'unit_test

Re: [VOTE] Release Qpid Dispatch Router 1.4.1 (RC2)

On 23/10/18 15:42, Ganesh Murthy wrote: Hello All, Please cast your vote on this thread to release RC2 as the official Qpid Dispatch Router version 1.4.1. RC2 of Qpid Dispatch Router version 1.4.1 can be found here: https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.4.1-rc2/

Re: [VOTE] Release Apache Qpid C++ 1.39.0

On 22/10/18 13:47, Justin Ross wrote: Hi, everyone. Please test this release candidate and vote based on what you find. Source archive and signatures: https://dist.apache.org/repos/dist/dev/qpid/cpp/1.39.0-rc1/ I am seeing failures in the 'unit_test' and 'sasl_tests' (running on fedora

Re: Go Electron: Large Messages Fail To Send

On 22/10/18 08:27, rk wrote: [0x7f80ec001c20]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"1", message-format=0] (20016) "\x00SpE\x00SsE\x00Sw\xb0\x00\x00N xxx... (truncated) [0x7f80ec001c20]:RAW:

Re: [VOTE] Release Qpid Dispatch Router 1.4.1 (RC1)

On 19/10/18 15:12, Ganesh Murthy wrote: Hello All, Please cast your vote on this thread to release RC1 as the official Qpid Dispatch Router version 1.4.1. RC1 of Qpid Dispatch Router version 1.4.1 can be found here: https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.4.1-rc1/

Re: Go Electron: Large Messages Fail To Send

On 19/10/18 12:13, rk wrote: Using the python client I can send much larger messages than 16k to the same broker so it appears to be an issue with the Go bindings. The issue can be recreated by editing the example send.go file in the electron repo to look like

Re: [ANNOUNCE] Apache Qpid Dispatch 1.4.0 released

On 18/10/18 13:35, Gordon Sim wrote: On 18/10/18 09:23, Hudalla Kai (INST/ECS4) wrote: Is it policy to not include e.g. a version property in the connection properties when Dispatch Router opens/accepts a connection? Again, my fault. In general the router does indicate the version. The auth

Re: Changes to auth plugin in Dispatch Router

On 18/10/18 21:56, Gordon Sim wrote: The fix is straightforward. I'll update the tests to ensure we don't regress on this aspect again. https://issues.apache.org/jira/browse/DISPATCH-1149, fixed on master - To unsubscribe, e

Re: Changes to auth plugin in Dispatch Router

On 18/10/18 15:07, Hudalla Kai (INST/ECS4) wrote: I am supplying them from the auth service in the same format that worked in 1.1.0. This is not a result of any change in the auth plugin itself. Since 1.2.0, setting the valid sources and targets on the policy_settings of the connection no

Re: Changes to auth plugin in Dispatch Router

On 18/10/18 10:04, Hudalla Kai (INST/ECS4) wrote: here is the router configuration file I am using: [ ["router", { "id": "Hono.Example.Router", "mode": "standalone", "workerThreads": 3 }], ["authServicePlugin", { "name": "Hono Auth", "host": "10.56.84.13",

Re: [ANNOUNCE] Apache Qpid Dispatch 1.4.0 released

On 18/10/18 09:23, Hudalla Kai (INST/ECS4) wrote: On Tue, 2018-10-16 at 09:40 -0400, Ganesh Murthy wrote: The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Dispatch 1.4.0 Qpid Dispatch is a router for the Advanced Message

Re: Go Electron Header Subscription

On 18/10/18 10:09, rk wrote: Thanks for the reply, I seem to of got it working by changing the Go code tohttps://play.golang.org/p/3805Mlqu5f4. Though I'm not sure what the string in the filter map (currently "selector") represents, I seem to be able to put anything in there. Yes, the value of

Re: Go Electron Header Subscription

On 17/10/18 16:57, rk wrote: I'm attempting to get a Go electron receiver working using a filter that should give me behaviour akin to the legacy header exchange bindings. My understanding is this can be done using this filter apache.org:legacy-amqp-headers-binding:map. However the Go receiver

Re: Client to broker connection status using C++ API

On 17/10/18 17:15, trivedi_ravi13 wrote: Hi, I've a requirement to monitor if a particular client is connected successfully to the broker or not periodically. Is there a way using C++ APIs to get the status of all connected clients on Qpid 0.24 ? Yes. Different brokers have different

Re: Latest passing build fails unit tests

On 12/10/18 16:22, Chester wrote: I noticed this build: https://builds.apache.org/blue/organizations/jenkins/Qpid-cpp-trunk-test/detail/Qpid-cpp-trunk-test/1284/pipeline is marked as successful. The build log says: *91% tests passed, 2 tests failed out of 22* *Total Test time (real) = 2508.89

Re: [VOTE] Release Qpid Dispatch Router 1.4.0 (RC1)

On 12/10/18 16:11, Ganesh Murthy wrote: Hello All, Please cast your vote on this thread to release RC1 as the official Qpid Dispatch Router version 1.4.0. RC1 of Qpid Dispatch Router version 1.4.0 can be found here: https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.4.0-rc1/

Re: Connection closed events

On 12/10/18 22:03, Gordon Sim wrote: On 12/10/18 21:57, areddy wrote: Thank you. I'll try on_connection_error. This happens once every ~500 messages. Most of the time messages are being transmitted correctly and accepted by activemq. I'm running activemq 5.15.6. *PS:* I'm running

Re: Connection closed events

On 12/10/18 21:57, areddy wrote: Thank you. I'll try on_connection_error. This happens once every ~500 messages. Most of the time messages are being transmitted correctly and accepted by activemq. I'm running activemq 5.15.6. *PS:* I'm running a multithreaded application where threads share an

Re: ServiceBus - Send message to DeadLetterQueue

On 12/10/18 15:22, akabhishek1 wrote: Hi Team, We are using "qpid-jms-client-0.34.0" to publish message on Azure ServiceBus. We have requirement to send message on "DeadLetterQueue". I am able to receive message from "DeadLetterQueue" but not able to send message. Can we send message to

Re: [VOTE] Release Apache Qpid Proton 0.26.0 (RC2)

On 04/10/18 13:27, Robbie Gemmell wrote: Hi folks, I have put together a second spin for a Qpid Proton 0.26.0 release, please give it a test out and vote accordingly. The files can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/proton/0.26.0-rc2/ The JIRAs assigned are:

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

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

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

Re: Race condition in MessagingHandler

On 21/09/18 16:38, areddy wrote: Thank you for confirming that and providing an alternative. It looks like the EventInjector is the correct way to handle this situation, is that correct ? Yes, that is what it is intended for to allow actions from other threads to be injected as events into

Re: Race condition in MessagingHandler

On 21/09/18 16:15, areddy wrote: Hello, i'm using MessagingHandler to consume messages off of activemq. This is my configuration 1. prefetch = 0 and I only process 1 message at a time. 2. auto_accept=False. 3. on_message creates a new thread on every message to "consume" the message I've

Re: [Dispatch Router] amqp:not-found

On 17/09/18 10:52, VERMEULEN Olivier wrote: Hello, Our messaging topology uses a dispatch-router in front of a bunch of brokers (the Java one). Note that we never use the dispatch-router for direct communication between a producer and a consumer, everything goes through a broker. Now when we

Re: Signing AMQP messages

On 13/09/18 19:54, Gordon Sim wrote: On 13/09/18 19:40, Chuck Rolke wrote: I'd put the signature in part of the 'bare message', such as application properties, which passes from sender to receiver unmodified. That would require the signature to be in the bytes the signature signs. I should

Re: Signing AMQP messages

On 13/09/18 19:40, Chuck Rolke wrote: I'd put the signature in part of the 'bare message', such as application properties, which passes from sender to receiver unmodified. That would require the signature to be in the bytes the signature signs. The 'footer' section was designed to be used

Re: [VOTE] Release Apache Qpid Proton 0.25.0

+1 - verified signature and checksum - built and installed from source including tests - ran all python examples (using master qpid-cpp broker for non-direct ones) - ran relevant python examples against dispatch 1.3.0 (built against 0.24.0) - compiled c++ examples[1] and ran some against

Re: [VOTE] Release Qpid for Java 6.1.7

On 28/08/18 13:27, Oleksandr Rudyy wrote: Hi all, I built a release candidate for 6.1.7 version of the Qpid for Java. Please give it a test out and vote accordingly. +1, built from source including tests, ran client example against c++ broker, ran qpid::messaging c++ examples (0-10 and 1.0)

Re: Message headers when talking to ActiveMQ?

On 27/08/18 16:26, Андрей Парамонов wrote: Hello! I'm trying to use Qpid Proton Python bindings to talk to ActiveMQ message broker. So far sending simple text messages worked fine, however proton.Message class doesn't seem to present any way to set custom message headers. For example, when

Re: qpid proton not sending EMPTY FRAME

On 24/08/18 20:59, areddy wrote: Thank you. that helps. I tried processing messages in another thread so the the event thread can continue sending heartbeats, and qpid does in fact send them out now. But now the link credit is replenished immediately after on_message, which causes the client to

Re: qpid proton not sending EMPTY FRAME

On 24/08/18 20:20, areddy wrote: I modified simple_recv.py and set auto_accept=False and then added a sleep in the on_message method. It is single threaded. If you sleep on the event thread it cannot do anything including sending heartbeats.

Re: [VOTE] Release Apache qpid-interop-test 0.2.0 (RC4)

On 14/08/18 14:52, Kim van der Riet wrote: Hi, I have assembled a proposed release for Apache Qpid Interop Test 0.2.0 (RC4). The Python path issue found in RC3 was fixed. Please try it out and test it, then vote accordingly on this thread. +1 (managed to build it from source - build needs

Re: can't build interop test

On 23/08/18 15:42, Kim van der Riet wrote: When running make for the first time, there should be generator messages as a part of the initial cmake output: $ make -- xpath found: /usr/bin/xpath -- Python 2 install directory name: python2.7 -- Python 3 install directory name: python3.6 -- Java

Re: can't build interop test

On 23/08/18 15:28, Kim van der Riet wrote: Do you see any error messages from the generator? Not when running cmake, just the error reported in first mail. Where should I be looking? - To unsubscribe, e-mail:

Re: can't build interop test

On 23/08/18 15:05, Kim van der Riet wrote: I am surprised. Do you have Python 3.x installed and working? The generator uses Python 3, and as I look at the CMakeLists file, I see that no check enforces the availability of Python 3. This could be an installer bug. Seems to be: $ python3 -i

can't build interop test

On 22/08/18 17:10, Kim van der Riet wrote: The correct link for the files is: https://dist.apache.org/repos/dist/dev/qpid/interop-test/0.2.0-rc4/ This is not a vote. I did try to build the source for this. I got an error from cmake: "C++ generation failed"

Re: [Dispatcher] Issue with request/response pattern using jms temporary queue

On 15/08/18 10:07, BYRNE Fergus wrote: Hi Gordon, Thanks for your fast response. I have made the changes suggested and I still get the same behaviour. Output from the test - 2018-08-15 09:52:43,305 [localhost:5672]] - INFO SaslMechanismFinder - Best match for SASL auth was:

Re: [Dispatcher] Issue with request/response pattern using jms temporary queue

On 14/08/18 22:21, fergus wrote: Hi, I am having an issue implementing a request/response pattern using JMS temporary queues (dynamic addressing). The docker compose to run the brokers and dispatcher and code is shared @ https://github.com/fbyrne/qpid-dispatch-jms The test code 1.

Re: [VOTE] Release Apache Qpid JMS AMQP 0-x 6.3.3

On 13/08/18 18:22, Oleksandr Rudyy wrote: I built a candidate release for version 6.3.3 of Qpid JMS AMQP 0-x. Please test and vote accordingly. +1, verified checksum and signature, built from source including tests, ran example against c++ broker over amqp 0-10

Re: [VOTE] Release Apache Qpid Proton-J 0.29.0

On 10/08/18 21:12, Robbie Gemmell wrote: I have put together a spin for a Qpid Proton-J 0.29.0 release, please test it and vote accordingly. +1 (built from source, ran tests with and without PN_TRACE_FRM set). - To

Re: local-idle-timeout expired

On 10/08/18 10:18, Chenxiong Qi wrote: I met this problem as well. I'm using python-qpid-proton 0.24.0 and there is no network issue in my case. My case is the message handler usually runs to handle task for a long time and messages are coming from producer continuously in the same time during

Re: QPID C++ Client SSL Environment Variables

On 09/08/18 21:37, Chris Whelan wrote: Hello, I am facing a problem with programmatically setting the QPID_SSL_CERT_PASSWORD_FILE environment variable in my program.  It appears that although I have not directly referenced any QPID classes at the point where I set the environment variable

Re: [VOTE] Release Qpid Dispatch Router 1.3.0 (RC1)

On 07/08/18 20:07, Ganesh Murthy wrote: Hello All, Please cast your vote on this thread to release RC1 as the official Qpid Dispatch Router version 1.3.0. RC1 of Qpid Dispatch Router version 1.3.0 can be found here: https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.3.0-rc1/

Re: Java Broker (7.0.6) stops delivering queue/consumer messages after 4 GB data transfer

On 06/08/18 18:25, Rob Godfrey wrote: So, I'm not familiar with the C++ API, if there were an obvious way to switch from "credit" mode to "window" mode (which is the protocol default) then that would likely work around the problem. Which API are you using? The recommended qpid::messaging API

Re: [VOTE] Release Apache Qpid Proton-J 0.27.3

On 31/07/18 16:00, Robbie Gemmell wrote: Hi folks, I have put together a spin for a Qpid Proton-J 0.27.3 release, please test it and vote accordingly. +1, built from source including successful run of all tests. - To

Re: [VOTE] Release Apache Qpid Proton-J 0.28.1

On 31/07/18 17:18, Robbie Gemmell wrote: Hi folks, I have put together a spin for a Qpid Proton-J 0.28.1 release, please test it and vote accordingly. +1, built from source including successful run of all tests. - To

Re: Temporary queues deletion

On 01/08/18 11:44, Michael Ivanov wrote: Currently I have the following: [0x55da51103a80]: -> AMQP [0x55da51103a80]:0 -> @open(16) [container-id="03F84325-E282-4535-800D-637EB4383871", hostname="localhost", channel-max=32767] [0x55da51103a80]:0 -> @begin(17) [next-outgoing-id=0,

Re: Temporary queues deletion

On 31/07/18 21:21, Michael Ivanov wrote: Then I modified messenger.c (starting from line 1768) and set 'exclusive' property there on source terminus when creating queue using '#' specifier [...] And after that I have seen that my temporary queues started to be created in exclusive mode, at

Re: [qpid-cpp client] Open connection to broker waits forever - patch attached

On 24/07/18 15:27, cwan wrote: qpid_client_connect_timeout.patch Attached is a patch to add connect timeout to qpid-cpp client's open connection call. A new option called "connect-timeout" can be used to specify

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On 20/07/18 15:50, Andrew Stitcher wrote: On Fri, 2018-07-20 at 10:47 -0400, Andrew Stitcher wrote: On Fri, 2018-07-20 at 15:44 +0100, Gordon Sim wrote: ... I believe Kim is using restart() but is debugging some issue where the task is postponed after it has already fired, which he does

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On 20/07/18 15:42, Andrew Stitcher wrote: I think I can help shed some light on the original intention of these two methods: Essentially they are intended for different purposes: (As Gordon says) setUpNextFire() is intended only for use with periodic timers and is intended to be used to set up

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On 20/07/18 15:18, Kim van der Riet wrote: On 07/20/2018 10:00 AM, Gordon Sim wrote: On 20/07/18 14:50, Kim van der Riet wrote: I agree that this is ambiguous. However, if the intent is to allow the timer to have period added for any state, why do we need setUpNextFire()? This idea seems

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On 20/07/18 14:50, Kim van der Riet wrote: I agree that this is ambiguous. However, if the intent is to allow the timer to have period added for any state, why do we need setUpNextFire()? This idea seems logically wrong. I believe setUpNextFire() was intended to be used by the Task subclass

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On 19/07/18 20:28, Gordon Sim wrote: On 19/07/18 16:11, Kim van der Riet wrote: The TimerTask class has two methods which change and/or set the time when the timer will fire. Both methods assume a timer period has been set when the task was originally created. setUpNextFire() is called

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On 19/07/18 16:11, Kim van der Riet wrote: The TimerTask class has two methods which change and/or set the time when the timer will fire. Both methods assume a timer period has been set when the task was originally created. setUpNextFire() is called *after* the timer has already fired, and

Re: Error when opening a connection as receiver.

On 08/07/18 21:40, Wiplash wrote: I am trying to open an receiver, but it does not work. I am trying to open the port on ampq:tcp:localhost:5672. This is the result, when I call connection.open(). So what do I need to do? It looks like you are perhaps trying to call close() on an empty session

Re: how AMQP connection can be active upto lifetime of application

On 04/07/18 17:21, akabhishek1 wrote: *OPTION* - So i have only option to handle this situation. Whenever i got this type of exception, then create New Connection, New Session and New Producer. This is not a good idea but i don't have any other option. That sounds like a reasonable solution to

Re: [Dispatch Router] non-destructive consumers

On 04/07/18 13:22, VERMEULEN Olivier wrote: Indeed with link-routes everything is working as expected. This brings another question though. I see in the docs that if I want to use server-side collectors I must use autolinks. But If want to use non-destructive consumers I have to use linkRoutes.

Re: Temporary queues deletion

On 03/07/18 21:15, Michael Ivanov wrote: Hallo, I'm trying to create a queue using qmf message to qpidd cpp (1.38) as follows (pseudocode, actually pn_data_* functions are used to construct the message): subject='broker', correlation_id='1', reply_to='X', properties={

Re: [Dispatch Router] non-destructive consumers

On 03/07/18 14:34, VERMEULEN Olivier wrote: Hello, I've been playing with the non-destructive consumers fro the past few days. First I will explain the use case that works. If I create a queue on a Broker-J (7.0.3) with ensureNonDestructiveConsumers set to true and I put a message in it, then

Re: how AMQP connection can be active upto lifetime of application

On 02/07/18 13:02, Robbie Gemmell wrote: On 2 July 2018 at 12:47, Gordon Sim wrote: On 02/07/18 12:33, akabhishek1 wrote: Conclusion - It seems, we definitely need to have one active producer/consumer Requirement - Need to create producer on demand. Could you please suggest best

Re: how AMQP connection can be active upto lifetime of application

On 02/07/18 12:33, akabhishek1 wrote: Hi Gordon And Robbie, Thanks a lot for your response. I think you are right it seems upper level exception. After doing research, i came on below conclusion. Problem - If we create only Connection(without producer and consumer) and kept Connection idle

Re: how AMQP connection can be active upto lifetime of application

On 30/06/18 14:43, Abhishek Kumar wrote: HI Team, I am using "qpid-jms-client-0.34.0" for connecting to servicebus. I am getting error "*The connection was inactive for more than the allowed 6 milliseconds and is closed by container*". I even setted as "amqp.idleTimeout=-1" but it

Re: [VOTE] Release Qpid Dispatch Router 1.2.0 (RC2)

On 29/06/18 20:21, Ganesh Murthy wrote: Hello All, Please cast your vote on this thread to release RC2 as the official Qpid Dispatch Router version 1.2.0. RC2 of Qpid Dispatch Router version 1.2.0 can be found here: https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.2.0-rc2/

Re: [VOTE] Release Apache Qpid Proton 0.24.0

On 26/06/18 18:50, Gordon Sim wrote: On 26/06/18 15:56, Robbie Gemmell wrote: Hi folks, I have put together a spin for a Qpid Proton 0.24.0 release, please give it a test out and vote accordingly. +1 * verified signature and has * built from source including tests * built dispatch 1.1.0

Re: [VOTE] Release Apache Qpid JMS 0.34.0

On 25/06/18 21:11, Robbie Gemmell wrote: Hi folks, I have put together a spin for a 0.34.0 Qpid JMS client release, please give it a test out and vote accordingly. +1, built from source including tests and ran against qdrouterd and qpidd

Re: [VOTE] Release Apache Qpid Proton 0.24.0

On 26/06/18 15:56, Robbie Gemmell wrote: Hi folks, I have put together a spin for a Qpid Proton 0.24.0 release, please give it a test out and vote accordingly. +1 * verified signature and has * built from source including tests * built dispatch 1.1.0 against it (some test failures due to

Re: [VOTE] Release Apache Qpid Broker-J 7.0.6

On 19/06/18 22:45, Oleksandr Rudyy wrote: Hi all, I created an RC1 built for a Qpid Broker-J 7.0.6 release. Please give it a test out and vote accordingly. +1, built from source including tests, ran qpid::messaging over both 1.0 and 0-10 (including conversion between them), ran python proton

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 19/06/18 22:24, Andrew Stitcher wrote: I hate to press you, but you avoided expressing a definite opinion. I'm planning to commit this change, do you object to it? I have expressed a definite opinion. I think there is a better way to solve the problem, namely fixing the server examples.

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 19/06/18 21:05, Andrew Stitcher wrote: On Tue, 2018-06-19 at 19:32 +0100, Gordon Sim wrote: On 19/06/18 19:25, Alan Conway wrote: What do you think the default server configuration should be? Should we default to excluding the offending mechs on the server side by default? To my mind

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 19/06/18 17:56, Alan Conway wrote: On Tue, Jun 19, 2018 at 11:55 AM, Gordon Sim wrote: On 19/06/18 16:44, Alan Conway wrote: A related (not identical) issue is https://issues.apache.org/jira/browse/DISPATCH-244 Andrews fix will fix that problem as well as the failures discussed here

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 19/06/18 16:44, Alan Conway wrote: A related (not identical) issue is https://issues.apache.org/jira/browse/DISPATCH-244 Andrews fix will fix that problem as well as the failures discussed here. Would setting the sasl configuration of the router for the tests not help? Installing config

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 15/06/18 20:58, Justin Ross wrote: I can't quite remember. I've just now checked all the full-fledged servers I use regularly (qpidd, qdrouterd, artemis), and they all restrict to an explicit list of mechs that excludes GSSAPI, as you suggest. It's probably something I've recently run into

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 15/06/18 19:44, Andrew Stitcher wrote: My major concern is the default *client* behaviour. In this case you don't have the config file, but you will get tripped up by mysterious failures if you have the GSSAPI mech installed. Your patch affects server behaviour also though. Even if GSSAPI

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 15/06/18 20:40, Justin Ross wrote: On Fri, Jun 15, 2018 at 12:25 PM Robbie Gemmell wrote: I think its reasonable that clients dont attempt to do GSSAPI by default unless it has been enabled in some way, since it requires specific external configuration. This is the case that interests

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 15/06/18 19:44, Andrew Stitcher wrote: Having read this email I understand that we are talking somewhat at cross purposes. I should have explained better! My major concern is the default *client* behaviour. In this case you don't have the config file, but you will get tripped up by

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 15/06/18 18:32, Gordon Sim wrote: On 15/06/18 18:02, Andrew Stitcher wrote: On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote: ... This is recorded as a JIRA [1] which has been open for a couple of years. You can of course also specify a mech list in the cyrus sasl config. True

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 15/06/18 18:02, Andrew Stitcher wrote: On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote: ... This is recorded as a JIRA [1] which has been open for a couple of years. You can of course also specify a mech list in the cyrus sasl config. True, but this is fairly complex - involving

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On 15/06/18 16:35, Andrew Stitcher wrote: There is a long standing pain point with using cyrus SASL: If you have Kerberos set up in your environment; are authenticated with Kerberos; and have the GSSAPI mechanism installed; but you are not using the ambient Kerberos credential for AMQP. In this

Re: MessageListener stop listening message and producer stop sending message, -> "qpid-jms-client - 0.32.0"

On 30/05/18 12:42, Robbie Gemmell wrote: The client has an notification system for use in its tests, which can be used to listen for such events as they occur. Using it would tie application code to the client impl, entirely at odds with using the vendor neutral JMS API, and the listener

Re: MessageListener stop listening message and producer stop sending message, -> "qpid-jms-client - 0.32.0"

On 29/05/18 20:24, Rob Godfrey wrote: On Tue, 29 May 2018 at 19:45, akabhishek1 wrote: HI Robbie, Thanks a lot for details. I am able to reproduce this issue with your finding, i am facing same idle timeOut issue for every 10m. As MessageProducer have no internal operation which will tell

Re: [VOTE] Release Apache Qpid Proton 0.23.0

On 23/05/18 20:53, Robbie Gemmell wrote: I have put together a spin for a Qpid Proton 0.23.0 release, please give it a test out and vote accordingly. +1, built from source including tests, ran python examples, build dispatch against it and ran a suite of tests for another system using this

Re: [VOTE] Release Apache Qpid JMS AMQP 0-x 6.3.1

On 15/05/18 12:36, Oleksandr Rudyy wrote: Hi folks, I built a candidate release for version 6.3.1 of Qpid JMS AMQP 0-x. Please test and vote accordingly. +1 (built from source including running tests, ran some examples against c++ broker and in conjunction with qpid::messaging over 0-10)

Re: Service Bus, connecting services behind firewall

On 15/05/18 04:49, Mansour Al Akeel wrote: Gordon, Thank you for replying. I am sorry I didn't explain it well. Maybe I was relying on the link on ServiceMix mailing list. I will try to explain it again here. We have two systems, on separate networks. System A and System B. Each of them provide

Re: Broadcast to self

On 14/05/18 20:13, Michael Ivanov wrote: I am implementing message broadcasting using fanout exchange. Several processes are subscribed to exchange and each of them can send messages to this exchange. Is it possible to prevent the sender to receive it's own message? In AMQP 0-10 there was a

<    1   2   3   4   5   6   7   8   9   10   >