0.8 RC1 available for download
Hi all, 0.8 RC1 can be found for download at: http://people.apache.org/~robbie/qpid/0.8/RC1/ Output from running RAT across the 'full release' archive can be found at: http://people.apache.org/~robbie/qpid/0.8/0.8rc1_rat_output.txt *Please* take the time to download and try out this release candidate and report your results, such that any additional issues which require addressing before the release can proceed are identified as early as possible. Thanks, Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2693) Broker instability with the topic exchange
[ https://issues.apache.org/jira/browse/QPID-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12929519#action_12929519 ] Emmanuel Bourg commented on QPID-2693: -- Thank you for the tests Robbie. I tried again with the code on the trunk and I still get the same issue. This time it occurred after 20 minutes at 100 messages per second. The exception on the client side is the same (the client is a development snapshot of qpid-0.7, so the line numbers may not match the code on the trunk) and the error seen on the broker side is: 2010-11-08 09:38:33,497 ERROR [MINANetworkDriver(Acceptor)-10] mina.MINANetworkDriver (MINANetworkDriver.java:315) - Exception thrown and no ProtocolEngine to handle it java.lang.IllegalArgumentException at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:265) at org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:125) at org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:42) at org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:101) at org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:36) at org.apache.qpid.transport.network.mina.MINANetworkDriver.messageReceived(MINANetworkDriver.java:337) at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362) at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800) at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:243) at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) That was on a Java 6u20 JVM with the default memory settings. I just unzipped the broker distribution, customized the user accounts and ran qpid.start. Broker instability with the topic exchange -- Key: QPID-2693 URL: https://issues.apache.org/jira/browse/QPID-2693 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.7 Environment: java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) Linux 2.6.24-11-pve #1 SMP PREEMPT Fri May 14 09:28:08 CEST 2010 x86_64 GNU/Linux Reporter: Emmanuel Bourg Assignee: Robbie Gemmell Priority: Critical Fix For: 0.9 I've noticed an instability of the Java broker when sending a high volume of messages to the topic exchange. The messages are non acked, non durable. After about 15 minutes the messages can no longer be dispatched and the client gets this exception: org.apache.qpid.transport.SessionException: timed out waiting for sync: complete = 77824, point = 77825 at org.apache.qpid.transport.Session.sync(Session.java:743) at org.apache.qpid.transport.Session.sync(Session.java:712) at org.apache.qpid.transport.Session.invoke(Session.java:672) at org.apache.qpid.transport.Session.invoke(Session.java:518) at org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96) at org.apache.qpid.transport.Session.messageTransfer(Session.java:880) And in the server log I get these exceptions: 2010-06-25 02:48:48,005 [ERROR] Exception thrown and no ProtocolEngine to handle it org.apache.qpid.transport.SessionException: timed out waiting for completion at org.apache.qpid.transport.Session.invoke(Session.java:635) at org.apache.qpid.server.transport.ServerSession.sendMessage(ServerSession.java:180) at org.apache.qpid.server.subscription.Subscription_0_10.send(Subscription_0_10.java:573) at org.apache.qpid.server.queue.SimpleAMQQueue.deliverMessage(SimpleAMQQueue.java:715) at org.apache.qpid.server.queue.SimpleAMQQueue.deliverToSubscription(SimpleAMQQueue.java:658) at org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:611) at org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:536) at
[jira] Commented: (QPID-2693) Broker instability with the topic exchange
[ https://issues.apache.org/jira/browse/QPID-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12929532#action_12929532 ] Robbie Gemmell commented on QPID-2693: -- Hi Emmanuel. Can you monitor the heap usage and take a thread dump once the issue occurs as I mentioned in my email? Can you also please attach the full client+broker logs, and your producer+consumer code to the JIRA to see if I can reproduce the issue using that. If you want you could try using the logging config we use for the tests (available at: qpid/java/test-profiles/log4j-test.xml) but if it runs for even 20mins you will find it produces an insane amount of information. None of the exceptions in the JIRA give much indication of what is actually going wrong so at present there is little I can do until I can reproduce it or get sufficient logs to actually analyse whats going on. Broker instability with the topic exchange -- Key: QPID-2693 URL: https://issues.apache.org/jira/browse/QPID-2693 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.7 Environment: java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) Linux 2.6.24-11-pve #1 SMP PREEMPT Fri May 14 09:28:08 CEST 2010 x86_64 GNU/Linux Reporter: Emmanuel Bourg Assignee: Robbie Gemmell Priority: Critical Fix For: 0.9 I've noticed an instability of the Java broker when sending a high volume of messages to the topic exchange. The messages are non acked, non durable. After about 15 minutes the messages can no longer be dispatched and the client gets this exception: org.apache.qpid.transport.SessionException: timed out waiting for sync: complete = 77824, point = 77825 at org.apache.qpid.transport.Session.sync(Session.java:743) at org.apache.qpid.transport.Session.sync(Session.java:712) at org.apache.qpid.transport.Session.invoke(Session.java:672) at org.apache.qpid.transport.Session.invoke(Session.java:518) at org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96) at org.apache.qpid.transport.Session.messageTransfer(Session.java:880) And in the server log I get these exceptions: 2010-06-25 02:48:48,005 [ERROR] Exception thrown and no ProtocolEngine to handle it org.apache.qpid.transport.SessionException: timed out waiting for completion at org.apache.qpid.transport.Session.invoke(Session.java:635) at org.apache.qpid.server.transport.ServerSession.sendMessage(ServerSession.java:180) at org.apache.qpid.server.subscription.Subscription_0_10.send(Subscription_0_10.java:573) at org.apache.qpid.server.queue.SimpleAMQQueue.deliverMessage(SimpleAMQQueue.java:715) at org.apache.qpid.server.queue.SimpleAMQQueue.deliverToSubscription(SimpleAMQQueue.java:658) at org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:611) at org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:536) at org.apache.qpid.server.transport.ServerSession$1.postCommit(ServerSession.java:157) at org.apache.qpid.server.txn.AutoCommitTransaction.enqueue(AutoCommitTransaction.java:151) at org.apache.qpid.server.transport.ServerSession.enqueue(ServerSession.java:146) at org.apache.qpid.server.transport.ServerSessionDelegate.messageTransfer(ServerSessionDelegate.java:287) at org.apache.qpid.server.transport.ServerSessionDelegate.messageTransfer(ServerSessionDelegate.java:96) at org.apache.qpid.transport.MessageTransfer.dispatch(MessageTransfer.java:103) at org.apache.qpid.transport.SessionDelegate.command(SessionDelegate.java:46) at org.apache.qpid.server.transport.ServerSessionDelegate.command(ServerSessionDelegate.java:110) at org.apache.qpid.server.transport.ServerSessionDelegate.command(ServerSessionDelegate.java:96) at org.apache.qpid.transport.Method.delegate(Method.java:159) at org.apache.qpid.transport.Session.received(Session.java:487) at org.apache.qpid.transport.Connection.dispatch(Connection.java:377) at org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:64) at org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:40) at org.apache.qpid.transport.MethodDelegate.messageTransfer(MethodDelegate.java:113) at org.apache.qpid.transport.MessageTransfer.dispatch(MessageTransfer.java:103) at org.apache.qpid.transport.ConnectionDelegate.command(ConnectionDelegate.java:54) at
[jira] Created: (QPID-2932) Add statistics generation for broker message delivery
Add statistics generation for broker message delivery - Key: QPID-2932 URL: https://issues.apache.org/jira/browse/QPID-2932 Project: Qpid Issue Type: New Feature Components: Java Broker Affects Versions: 0.5 Reporter: Andrew Kennedy Assignee: Andrew Kennedy Add the ability to generate and report on statistics for message delivery in the broker. These include message and data throughput totals, rate per second and peak rate per second. The statistics should be made available as JMX attributes at the connection, virtualhost and broker level, and should be fully configurable. This change is only being made on the 0.5.x-dev branch currently, and will need to be ported to trunk post 0.8 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Version increments
Thanks for making the release!
The file you highlight below
cpp/src/CMakeWinVersions.cmake
is loaded with 0.7.0.1 strings. As checked-in, however, the file is nothing
but comments. None of the 0.7.0.1 strings from this file makes it into the
build. The file is a placeholder for users who wish to create the WinSDK with
some other version number than 0.7.0.1. I thought that the placeholder file
would be much more useful if specific examples of what version information
could be specified, and of the exact syntax, were present.
This file can live on with the 0.7.0.1 strings and settings as they exist only
as comments.
-Chuck
- Robbie Gemmell robbie.gemm...@gmail.com wrote:
From: Robbie Gemmell robbie.gemm...@gmail.com
To: dev@qpid.apache.org
Sent: Sunday, November 7, 2010 3:22:45 PM GMT -05:00 US/Canada Eastern
Subject: Version increments
Hi all,
I have just incremented the version numbers on both the
0.8-release-candidates branch and trunk. The code versions obviously
changed from 0.7 to 0.8 and 0.9 respectively, but there were also a
few doc updates for both from 0.7 to 0.8.
Below is a list of places I found 0.7 to be used in the repo and
which
served as the basis for what I updated. Also included are some things
I didn't update, and places on the website that will need updated
once
it is more suitable to do so (i.e. once we have a 0.8 release to put
up there).
The commits were 1032366 (0.8-release-candidates) and 1032374
(trunk).
I'd appreciate people taking a look over them to verify that the
changes I made seem appropriate, and check whether I missed anything.
Thanks,
Robbie
Code Files:
===
./python/setup.py: version=0.7
./java/common.xml: property name=project.version
value=0.7/
./java/broker/src/main/java/org/apache/qpid/server/plugins/PluginManager.java:
private static final String QPID_VER_SUFFIX = version=0.7,;
./java/client/src/main/java/client.bnd:ver: 0.7.0
./java/management/eclipse-plugin/META-INF/MANIFEST.MF:Bundle-Version:
0.7.0
./java/management/common/src/main/java/management-common.bnd:ver:
0.7.0
./java/broker-plugins/experimental/shutdown/src/main/java/shutdown.bnd:ver:
0.7.0
./java/common/src/main/java/common.bnd:ver: 0.7.0
./QPID_VERSION.txt:0.7
./cpp/src/CMakeWinVersions.cmake:# set
(winver_${projectName}_FileVersionBinary0,7,0,1)
./cpp/src/CMakeWinVersions.cmake:# set
(winver_${projectName}_ProductVersionBinary 0,7,0,1)
./cpp/src/CMakeWinVersions.cmake: ...also a set of vertical
individual
version indices, discovered after opening the file for the above
changes.
./tools/setup.py: version=0.7,
./tests/setup.py: version=0.7,
./extras/qmf/setup.py: version=0.7,
Docs:
=
./doc/book/src/java/broker/configuration/Topic-Configuration.xml:
paraNew in 0.7 is the ability to define configuration for topics.
Currently this is limited to
./doc/book/src/java/broker/configuration/Topic-Configuration.xml:
para As of 0.7 the topic configuration is limited to straight
string matching. This means
./doc/book/src/Programming-In-Apache-Qpid.xml: If you are
using JMS Map messages and deploying a new client with any JMS client
older than 0.7 release, you must set this to true to ensure the older
clients can understand the map message encoding.
Files that mention 0.7 which were NOT changed due to the context:
==
./cpp/src/qmf/agentCapability.h: * Legacy (Qpid 0.7 C++ Agent,
0.7
Broker Agent) capabilities
./cpp/bld-winsdk.ps1:# 4. Args[3] holds the version number.
0.7.946106-99
Website source files, to be modified upon release completion:
=
./doc/website/template/template.html: lia
href=documentation.html#doc07Version 0.7/a/li
./doc/website/content/getting_started.html: liInstructions for a
href=http://qpid.apache.org/books/0.7/AMQP-Messaging-Broker-CPP-Book/html/ch01.html#section-Running-a-Qpid-CPP-Broker;
title=RASCrunning a Qpid C++ broker (AMQP 0-10) /a/li
./doc/website/content/documentation.html: h2
id=doc06Documentation for Qpid 0.7 (development branch)/h2
./doc/website/content/documentation.html: a
href=books/0.7/AMQP-Messaging-Broker-CPP-Book/pdf/AMQP-Messaging-Broker-CPP-Book.pdf
./doc/website/content/documentation.html: a
href=books/0.7/AMQP-Messaging-Broker-CPP-Book/html/index.htmlHTML/a/p/li
./doc/website/content/documentation.html: pa
href=books/0.7/AMQP-Messaging-Broker-Java-Book/pdf/AMQP-Messaging-Broker-Java-Book.pdf
./doc/website/content/documentation.html: a
href=books/0.7/AMQP-Messaging-Broker-Java-Book/html/index.htmlHTML/a/p/li
./doc/website/content/documentation.html: a
href=books/0.7/Programming-In-Apache-Qpid/pdf/Programming-In-Apache-Qpid.pdf
./doc/website/content/documentation.html: a
Re: Version increments
I did notice it was just comments but I just updated them anwyay...in
general I wanted to eradicate as many references to 0.7 as I could
since referring to unreleased version numbers only seems to have
confused people thus far, so I think its best that the release doesnt
where its at all acceptable to change it :)
Robbie
On 8 November 2010 15:15, Chuck Rolke cro...@redhat.com wrote:
Thanks for making the release!
The file you highlight below
cpp/src/CMakeWinVersions.cmake
is loaded with 0.7.0.1 strings. As checked-in, however, the file is nothing
but comments. None of the 0.7.0.1 strings from this file makes it into the
build. The file is a placeholder for users who wish to create the WinSDK with
some other version number than 0.7.0.1. I thought that the placeholder file
would be much more useful if specific examples of what version information
could be specified, and of the exact syntax, were present.
This file can live on with the 0.7.0.1 strings and settings as they exist
only as comments.
-Chuck
- Robbie Gemmell robbie.gemm...@gmail.com wrote:
From: Robbie Gemmell robbie.gemm...@gmail.com
To: dev@qpid.apache.org
Sent: Sunday, November 7, 2010 3:22:45 PM GMT -05:00 US/Canada Eastern
Subject: Version increments
Hi all,
I have just incremented the version numbers on both the
0.8-release-candidates branch and trunk. The code versions obviously
changed from 0.7 to 0.8 and 0.9 respectively, but there were also a
few doc updates for both from 0.7 to 0.8.
Below is a list of places I found 0.7 to be used in the repo and
which
served as the basis for what I updated. Also included are some things
I didn't update, and places on the website that will need updated
once
it is more suitable to do so (i.e. once we have a 0.8 release to put
up there).
The commits were 1032366 (0.8-release-candidates) and 1032374
(trunk).
I'd appreciate people taking a look over them to verify that the
changes I made seem appropriate, and check whether I missed anything.
Thanks,
Robbie
Code Files:
===
./python/setup.py: version=0.7
./java/common.xml: property name=project.version
value=0.7/
./java/broker/src/main/java/org/apache/qpid/server/plugins/PluginManager.java:
private static final String QPID_VER_SUFFIX = version=0.7,;
./java/client/src/main/java/client.bnd:ver: 0.7.0
./java/management/eclipse-plugin/META-INF/MANIFEST.MF:Bundle-Version:
0.7.0
./java/management/common/src/main/java/management-common.bnd:ver:
0.7.0
./java/broker-plugins/experimental/shutdown/src/main/java/shutdown.bnd:ver:
0.7.0
./java/common/src/main/java/common.bnd:ver: 0.7.0
./QPID_VERSION.txt:0.7
./cpp/src/CMakeWinVersions.cmake:# set
(winver_${projectName}_FileVersionBinary 0,7,0,1)
./cpp/src/CMakeWinVersions.cmake:# set
(winver_${projectName}_ProductVersionBinary 0,7,0,1)
./cpp/src/CMakeWinVersions.cmake: ...also a set of vertical
individual
version indices, discovered after opening the file for the above
changes.
./tools/setup.py: version=0.7,
./tests/setup.py: version=0.7,
./extras/qmf/setup.py: version=0.7,
Docs:
=
./doc/book/src/java/broker/configuration/Topic-Configuration.xml:
paraNew in 0.7 is the ability to define configuration for topics.
Currently this is limited to
./doc/book/src/java/broker/configuration/Topic-Configuration.xml:
para As of 0.7 the topic configuration is limited to straight
string matching. This means
./doc/book/src/Programming-In-Apache-Qpid.xml: If you are
using JMS Map messages and deploying a new client with any JMS client
older than 0.7 release, you must set this to true to ensure the older
clients can understand the map message encoding.
Files that mention 0.7 which were NOT changed due to the context:
==
./cpp/src/qmf/agentCapability.h: * Legacy (Qpid 0.7 C++ Agent,
0.7
Broker Agent) capabilities
./cpp/bld-winsdk.ps1:# 4. Args[3] holds the version number.
0.7.946106-99
Website source files, to be modified upon release completion:
=
./doc/website/template/template.html: lia
href=documentation.html#doc07Version 0.7/a/li
./doc/website/content/getting_started.html: liInstructions for a
href=http://qpid.apache.org/books/0.7/AMQP-Messaging-Broker-CPP-Book/html/ch01.html#section-Running-a-Qpid-CPP-Broker;
title=RASCrunning a Qpid C++ broker (AMQP 0-10) /a/li
./doc/website/content/documentation.html: h2
id=doc06Documentation for Qpid 0.7 (development branch)/h2
./doc/website/content/documentation.html: a
href=books/0.7/AMQP-Messaging-Broker-CPP-Book/pdf/AMQP-Messaging-Broker-CPP-Book.pdf
./doc/website/content/documentation.html: a
href=books/0.7/AMQP-Messaging-Broker-CPP-Book/html/index.htmlHTML/a/p/li
./doc/website/content/documentation.html: pa
[jira] Created: (QPID-2933) Messaging .NET binding has several assembly properties misnamed
Messaging .NET binding has several assembly properties misnamed --- Key: QPID-2933 URL: https://issues.apache.org/jira/browse/QPID-2933 Project: Qpid Issue Type: Bug Affects Versions: 0.9 Environment: Windows build for .NET Binding Reporter: Chuck Rolke Assignee: Chuck Rolke Priority: Minor Fix For: 0.9 Several files have cut-paste errors in AssemblyInfo.cs files, misnaming AssemblyTitle and AssemblyProduct -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2934) Feature to pass the authenticated userId to QMF agent method handlers for authorization
Feature to pass the authenticated userId to QMF agent method handlers for authorization --- Key: QPID-2934 URL: https://issues.apache.org/jira/browse/QPID-2934 Project: Qpid Issue Type: New Feature Components: Qpid Managment Framework Affects Versions: 0.9 Reporter: Ted Ross Assignee: Ted Ross Priority: Minor Fix For: 0.9 In order to authorize method calls in QMF, the method handler needs to be provided with the authenticated user-id of the requestor (i.e. the content of the user-id message header as authenticated by the message broker). This change provides a new method to Manageable (in the C++ agent API) called AuthorizeMethod. It is virtual and may optionally be overridden by the application. If overridden, it is invoked immediately prior to the call to ManagementMethod (the method handler) with the method-id, method-arguments, and the user-id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2934) Feature to pass the authenticated userId to QMF agent method handlers for authorization
[ https://issues.apache.org/jira/browse/QPID-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated QPID-2934: --- Attachment: QPID2934.diff This patch implements the proposed solution. Feature to pass the authenticated userId to QMF agent method handlers for authorization --- Key: QPID-2934 URL: https://issues.apache.org/jira/browse/QPID-2934 Project: Qpid Issue Type: New Feature Components: Qpid Managment Framework Affects Versions: 0.9 Reporter: Ted Ross Assignee: Ted Ross Priority: Minor Fix For: 0.9 Attachments: QPID2934.diff In order to authorize method calls in QMF, the method handler needs to be provided with the authenticated user-id of the requestor (i.e. the content of the user-id message header as authenticated by the message broker). This change provides a new method to Manageable (in the C++ agent API) called AuthorizeMethod. It is virtual and may optionally be overridden by the application. If overridden, it is invoked immediately prior to the call to ManagementMethod (the method handler) with the method-id, method-arguments, and the user-id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2935) Support best effort producer flow control within the AMQP 0.10 implementation.
Support best effort producer flow control within the AMQP 0.10 implementation. Key: QPID-2935 URL: https://issues.apache.org/jira/browse/QPID-2935 Project: Qpid Issue Type: New Feature Components: C++ Broker, C++ Client Affects Versions: 0.9 Environment: any Reporter: Ken Giusti Assignee: Ken Giusti Fix For: Future To what extent, if any, could producer flow control be supported on the existing (pre-1.0) protocol? In the current C++ broker/client implementation, when a queue on the broker fills to the point where it cannot accept any more messages (--default-queue-limit hit), the broker will forcibly disconnect any client that attempts to route a message to that queue. This is an abrupt failure - the producing client is not privy to the queue's remaining capacity. The broker provides no feedback to the producing client, which could be used to throttle the client's message production rate. The purpose of this JIRA is to explore the possible methods for implementing producer throttling on the current 0.10 C++ codebase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2935) Support best effort producer flow control within the AMQP 0.10 implementation.
[ https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12929805#action_12929805 ] Ken Giusti commented on QPID-2935: -- The 0.10 AMQP spec defines the use of credit as a mechanism to control the amount of data that is transferred between a client and a server (see section 2.6.1. Flow Control in the AMQP spec 0.10). In theory, the broker should be able to throttle the production rate of a client by intelligently managing the rate for which it replenishes credit to that client. For example, the broker could delay the completion of a message transfer should it detect that one or more queues that are destinations of the message transfer are nearing their limits. The current broker implementation supports the notion of asynchronous enqueuing - that there is a potential delay between the receipt of a message and the point in at which the message completes enqueueing to all destination queues. The broker delays the completion of the message transfer (from the producer's point of view) until the enqueueing has completed. This concept may be able to be extended to consider the capacity of the destination queues: do not complete a message transfer until all destination queues have a reasonable amount of capacity available. Support best effort producer flow control within the AMQP 0.10 implementation. Key: QPID-2935 URL: https://issues.apache.org/jira/browse/QPID-2935 Project: Qpid Issue Type: New Feature Components: C++ Broker, C++ Client Affects Versions: 0.9 Environment: any Reporter: Ken Giusti Assignee: Ken Giusti Fix For: Future To what extent, if any, could producer flow control be supported on the existing (pre-1.0) protocol? In the current C++ broker/client implementation, when a queue on the broker fills to the point where it cannot accept any more messages (--default-queue-limit hit), the broker will forcibly disconnect any client that attempts to route a message to that queue. This is an abrupt failure - the producing client is not privy to the queue's remaining capacity. The broker provides no feedback to the producing client, which could be used to throttle the client's message production rate. The purpose of this JIRA is to explore the possible methods for implementing producer throttling on the current 0.10 C++ codebase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2935) Support best effort producer flow control within the AMQP 0.10 implementation.
[ https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated QPID-2935: - Attachment: QPID-2935.tgz A very hacky proof-of-concept of the delayed completion approach. Includes same sender and receiver clients (including a spout derivation). Loosely based on the IncompleteMessageList object in the broker's SessionState object. Associates a list of overflow messages and a timer thread with the broker's SessionState for a (producer) client. Should a message fail to enqueue to a queue due to limit overflow, this hack stores the message on the overflow list. All further messages that arrive from that client are also queued to the overflow list (preserving order). Periodically, the timer thread attempts to route the message at the head of the overflow list. Should the routing succeed (there was room on the destination queues), the head message is removed from the list, and the next message is routed. I've modified the client side to wait for capacity to become available when it is exhausted. When run against the example slow consumer (receiver.cpp), the sender client will occasionally block in the send() api call, until space becomes available on the queue. Support best effort producer flow control within the AMQP 0.10 implementation. Key: QPID-2935 URL: https://issues.apache.org/jira/browse/QPID-2935 Project: Qpid Issue Type: New Feature Components: C++ Broker, C++ Client Affects Versions: 0.9 Environment: any Reporter: Ken Giusti Assignee: Ken Giusti Fix For: Future Attachments: QPID-2935.tgz To what extent, if any, could producer flow control be supported on the existing (pre-1.0) protocol? In the current C++ broker/client implementation, when a queue on the broker fills to the point where it cannot accept any more messages (--default-queue-limit hit), the broker will forcibly disconnect any client that attempts to route a message to that queue. This is an abrupt failure - the producing client is not privy to the queue's remaining capacity. The broker provides no feedback to the producing client, which could be used to throttle the client's message production rate. The purpose of this JIRA is to explore the possible methods for implementing producer throttling on the current 0.10 C++ codebase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
