[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
[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-tabpanel&focusedCommentId=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] 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] 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-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] 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
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 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" wrote: > >> From: "Robbie Gemmell" >> 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: > 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: >> New 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: >> 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: > href="documentation.html#doc07">Version 0.7 >> ./doc/website/content/getting_started.html: Instructions for > href="http://qpid.apache.org/books/0.7/AMQP-Messaging-Broker-CPP-Book/html/ch01.html#section-Running-a-Qpid-CPP-Broker"; >> title="RASC">running a Qpid C++ broker (AMQP 0-10) >> ./doc/website/content/documentation.html: > id="doc06">Documentation for Qpid 0.7 (development branch) >> ./doc/website/content/documentation.html: > href="books/0.7/AMQP-Messaging-Broker-CPP-Book/pdf/AMQP-Messaging-Broker-CPP-Book.pdf" >> ./doc/website/content/documentation.html: > href="books/0.7/AMQP-Messaging-Broker-CPP-Book/html/inde
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" wrote: > From: "Robbie Gemmell" > 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: 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: > New 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: >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: href="documentation.html#doc07">Version 0.7 > ./doc/website/content/getting_started.html: Instructions for href="http://qpid.apache.org/books/0.7/AMQP-Messaging-Broker-CPP-Book/html/ch01.html#section-Running-a-Qpid-CPP-Broker"; > title="RASC">running a Qpid C++ broker (AMQP 0-10) > ./doc/website/content/documentation.html: id="doc06">Documentation for Qpid 0.7 (development branch) > ./doc/website/content/documentation.html: href="books/0.7/AMQP-Messaging-Broker-CPP-Book/pdf/AMQP-Messaging-Broker-CPP-Book.pdf" > ./doc/website/content/documentation.html: href="books/0.7/AMQP-Messaging-Broker-CPP-Book/html/index.html">HTML > ./doc/website/content/documentation.html: href="books/0.7/AMQP-Messaging-Broker-Java-Book/pdf/AMQP-Messaging-Broker-Java-Book.pdf" > ./doc/website/content/documentation.html: href="books/0.7/AMQP-Messaging-Broker-Java-Book/html/index.html">HTML > ./doc/website/content/documentation.html: href="books/0.7/Programming-In-Apache-Qpid/pdf/Programming-In-Apache-Qpid.pdf" > ./doc/website/content/documentation.html: href="books/0.7/Programming-In-Ap
[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
[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-tabpanel&focusedCommentId=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(Co
[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-tabpanel&focusedCommentId=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 > org.apa
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