[jira] Issue Comment Edited: (QPID-3059) Example TopicListener.cs does not await the arrival of messages
[ https://issues.apache.org/jira/browse/QPID-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994885#comment-12994885 ] Keith Wall edited comment on QPID-3059 at 2/16/11 11:08 AM: Changed TopicListener example code. It now uses a monitor to either await the arrival of the the shutdown message (from TopicPublisher), or a timeout occurs. I puzzled how the example has ever worked. The Dispatcher thread created in ./Qpid.Client/Client/AmqChannel.cs has always had IsBackground set to true, and http://msdn.microsoft.com/en-us/library/h339syd0%28v=vs.71%29.aspx says "a background thread will not keep the managed execution environment alive" so without a foreground thread, the VM will always terminate. was (Author: k-wall): Changed TopicListener example code. It now uses a monitor to either await the arrival of the the shutdown message (from TopicPublisher), or a timeout occurs. > Example TopicListener.cs does not await the arrival of messages > --- > > Key: QPID-3059 > URL: https://issues.apache.org/jira/browse/QPID-3059 > Project: Qpid > Issue Type: Bug > Components: Dot Net Client >Affects Versions: 0.8 > Environment: Linux, Mono JIT compiler version 2.6.7 (tarball Mon Jul > 19 18:28:58 UTC 2010) >Reporter: Keith Wall >Priority: Minor > Attachments: > 0001-QPID-3059-Used-a-monitor-to-ensure-that-the-main-thr.patch > > > I'm trying to run the TopicListener/TopicPublisher provided in the source > tree of the dotnet 0.8 client (The Java Broker Compatible client) . I'm > running on a Linux host under Mono. > I find when I execute TopicListener.exe it immediately writes "Waiting for > messages..." to the console and then exits. The problem seem to me that the > main thread is being allowed to terminate so the program is exiting before it > has a chance to hear the messages of TopicPublisher. > mono ./bin/mono-2.0/debug/TopicListener.exe > Waiting for messages..." -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-3059) Example TopicListener.cs does not await the arrival of messages
[ https://issues.apache.org/jira/browse/QPID-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3059: - Description: I'm trying to run the TopicListener/TopicPublisher provided in the source tree of the dotnet 0.8 client (The Java Broker Compatible client) . I'm running on a Linux host under Mono. I find when I execute TopicListener.exe it immediately writes "Waiting for messages..." to the console and then exits. The problem seems to me that the main thread is being allowed to terminate so the program is exiting before it has a chance to hear the messages of TopicPublisher. mono ./bin/mono-2.0/debug/TopicListener.exe Waiting for messages... was: I'm trying to run the TopicListener/TopicPublisher provided in the source tree of the dotnet 0.8 client (The Java Broker Compatible client) . I'm running on a Linux host under Mono. I find when I execute TopicListener.exe it immediately writes "Waiting for messages..." to the console and then exits. The problem seem to me that the main thread is being allowed to terminate so the program is exiting before it has a chance to hear the messages of TopicPublisher. mono ./bin/mono-2.0/debug/TopicListener.exe Waiting for messages..." Correct minor typo. > Example TopicListener.cs does not await the arrival of messages > --- > > Key: QPID-3059 > URL: https://issues.apache.org/jira/browse/QPID-3059 > Project: Qpid > Issue Type: Bug > Components: Dot Net Client >Affects Versions: 0.8 > Environment: Linux, Mono JIT compiler version 2.6.7 (tarball Mon Jul > 19 18:28:58 UTC 2010) >Reporter: Keith Wall >Priority: Minor > Attachments: > 0001-QPID-3059-Used-a-monitor-to-ensure-that-the-main-thr.patch > > > I'm trying to run the TopicListener/TopicPublisher provided in the source > tree of the dotnet 0.8 client (The Java Broker Compatible client) . I'm > running on a Linux host under Mono. > I find when I execute TopicListener.exe it immediately writes "Waiting for > messages..." to the console and then exits. The problem seems to me that > the main thread is being allowed to terminate so the program is exiting > before it has a chance to hear the messages of TopicPublisher. > mono ./bin/mono-2.0/debug/TopicListener.exe > Waiting for messages... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3061) Discrepancies between CMake and Automake
Discrepancies between CMake and Automake Key: QPID-3061 URL: https://issues.apache.org/jira/browse/QPID-3061 Project: Qpid Issue Type: Bug Components: Build Tools Affects Versions: 0.8 Reporter: Ted Ross Assignee: Ted Ross Priority: Minor Fix For: 0.9 There are some changes that were put into Autoconf/Automake but not Cmake. This issue is for tracking the synchronization of cmake to automake. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3062) Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x)
Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x) Key: QPID-3062 URL: https://issues.apache.org/jira/browse/QPID-3062 Project: Qpid Issue Type: Improvement Components: Dot Net Client Affects Versions: 0.8 Reporter: Keith Wall Assignee: Keith Wall Priority: Minor We have an additional example (suitable for the AMQP0-8 .net client - qpid-dotnet-0-8-x-x) which may be of use to the Qpid/.net community. This improvement provides this patch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-3062) Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x)
[ https://issues.apache.org/jira/browse/QPID-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3062: - Attachment: 0001-QPID-3062-Additional-example-for-the-.net-client.patch Hi Andew As discussed - this is the extra example as a patch. Can you please review? You'll see I renamed Publish.cs to Producer.cs to avoid confusion with TopicPublisher.cs. It would have been nice to bring together all the examples beneath an examples/ directory, but I don't have access to Microsoft Visual Studio 2008 to be able to refactor its project files. cheers Keith > Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x) > > > Key: QPID-3062 > URL: https://issues.apache.org/jira/browse/QPID-3062 > Project: Qpid > Issue Type: Improvement > Components: Dot Net Client >Affects Versions: 0.8 >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Attachments: > 0001-QPID-3062-Additional-example-for-the-.net-client.patch > > > We have an additional example (suitable for the AMQP0-8 .net client - > qpid-dotnet-0-8-x-x) which may be of use to the Qpid/.net community. > This improvement provides this patch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-3062) Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x)
[ https://issues.apache.org/jira/browse/QPID-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-3062: Assignee: Andrew Kennedy (was: Keith Wall) > Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x) > > > Key: QPID-3062 > URL: https://issues.apache.org/jira/browse/QPID-3062 > Project: Qpid > Issue Type: Improvement > Components: Dot Net Client >Affects Versions: 0.8 >Reporter: Keith Wall >Assignee: Andrew Kennedy >Priority: Minor > Attachments: > 0001-QPID-3062-Additional-example-for-the-.net-client.patch > > > We have an additional example (suitable for the AMQP0-8 .net client - > qpid-dotnet-0-8-x-x) which may be of use to the Qpid/.net community. > This improvement provides this patch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3057) New Visual Studio solution to build org.apache.qpid.messaging.sessionreceiver separately
[ https://issues.apache.org/jira/browse/QPID-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995321#comment-12995321 ] Chuck Rolke commented on QPID-3057: --- +1 to adding the new solution file. I had a concern about having the sessionreceiver project file referenced by two solution files (the existing one and this proposed new one) but that concern was misguided. It's fine to refer to the csproj project file in any number of solutions. Don't forget the copyright notice. > New Visual Studio solution to build org.apache.qpid.messaging.sessionreceiver > separately > > > Key: QPID-3057 > URL: https://issues.apache.org/jira/browse/QPID-3057 > Project: Qpid > Issue Type: Improvement > Components: C++ Client >Affects Versions: 0.8 > Environment: Windows, Visual Studio, MSBuild >Reporter: Steve Huston >Priority: Minor > Fix For: 0.9 > > Attachments: org.apache.qpid.messaging.sessionreceiver.sln > > > qpid/packaging/windows/installer.proj is a MSBuild project that builds an > installable Windows kit. The MSBuild steps can't build vcproj and csproj > files in the same step/solution, so attempting to build all of > qpid/cpp/bindings/qpid/dotnet/org.apache.qpid.messaging.sln can get the > org.apache.qpid.messaging project, but not > org.apache.qpid.messaging./sessionreceiver. I'd like to add a > org.apache.qpid.messaging.sessionreceiver.sln file that builds only the > sessionreceiver dll. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995336#comment-12995336 ] michael j. goulish commented on QPID-2993: -- Well, with the latest code tree ( r1071018 ) I do indeed find something interesting. I cannot get it to actually crash, but with the attached script ( 2993_bug.sh ) running on a fast 8-proc system, I was able to see 2 out of 10 instances of broker A2 failing to start up, and logging the following error: 2011-02-16 09:34:23 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical cluster(20.0.100.36:11855 READY/error) local error 1498 did not occur on member 20.0.100.36:11714: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-02-16 09:34:23 notice cluster(20.0.100.36:11855 LEFT/error) leaving cluster A 2011-02-16 09:34:23 notice Shut down > Federated source-local links crash remotely federated cluster member on local > cluster startup > - > > Key: QPID-2993 > URL: https://issues.apache.org/jira/browse/QPID-2993 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Clustering >Affects Versions: 0.8 > Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell > Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 >Reporter: Mark Moseley >Assignee: michael j. goulish > Attachments: cluster-fed-src.sh > > > This is related to JIRA 2992 that I opened, but this is for source-local > routes. Given the same setup as in JIRA 2992 but using source-local routes > (and obviously with the exchanges switched accordingly in the qpid-route > statements), i.e. cluster A and cluster B with the routes between A1<->B1, > when cluster B shuts down in the order B2->B1 and starts back up, the static > routes are not correctly re-bound on cluster A's side. However if cluster B > is shut down in the order B1->B2 and started back up, the route is correctly > created and works. However in the non-functioning case (B2->B1, or A2->A1), > there is an additional side-effect: on node A2, qpidd crashes with the > following error (cluster A is called 'walclust', B is bosclust): > 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not > attached (qpid/amqp_0_10/SessionHandler.cpp:39) > 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error > 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not > attached (qpid/amqp_0_10/SessionHandler.cpp:39) > 2011-01-07 18:57:35 critical Error delivering frames: local error did not > occur on all cluster members : not-attached: Channel 1 is not attached > (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) > 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving > cluster walclust > 2011-01-07 18:57:35 notice Shut down > This happens on both sides of the cluster, so it's not limited to one or the > other. This crash does *not* occur in the A1->A2/B1->B2 test (i.e. the test > where the route is re-bound correctly). I can cause this to reoccur pretty > much every time. I've been resetting the cluster completely to a new state > between each test. Occasionally in the B2->B1 test, A1 will also crash with > the same error (and vice versa for A2->A1 for node B1), though most of the > time, it's A2/B2 that crashes. > I was getting this same behaviour prior to upgrading corosync/openais as > well. Previously I was using the stock Squeeze versions of corosync==1.2.1 > and openais==1.1.2. The results are the same with corosync=1.3.0 and > openais==1.1.4. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2993: - Attachment: 2993_bug.sh > Federated source-local links crash remotely federated cluster member on local > cluster startup > - > > Key: QPID-2993 > URL: https://issues.apache.org/jira/browse/QPID-2993 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Clustering >Affects Versions: 0.8 > Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell > Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 >Reporter: Mark Moseley >Assignee: michael j. goulish > Attachments: 2993_bug.sh, cluster-fed-src.sh > > > This is related to JIRA 2992 that I opened, but this is for source-local > routes. Given the same setup as in JIRA 2992 but using source-local routes > (and obviously with the exchanges switched accordingly in the qpid-route > statements), i.e. cluster A and cluster B with the routes between A1<->B1, > when cluster B shuts down in the order B2->B1 and starts back up, the static > routes are not correctly re-bound on cluster A's side. However if cluster B > is shut down in the order B1->B2 and started back up, the route is correctly > created and works. However in the non-functioning case (B2->B1, or A2->A1), > there is an additional side-effect: on node A2, qpidd crashes with the > following error (cluster A is called 'walclust', B is bosclust): > 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not > attached (qpid/amqp_0_10/SessionHandler.cpp:39) > 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error > 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not > attached (qpid/amqp_0_10/SessionHandler.cpp:39) > 2011-01-07 18:57:35 critical Error delivering frames: local error did not > occur on all cluster members : not-attached: Channel 1 is not attached > (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) > 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving > cluster walclust > 2011-01-07 18:57:35 notice Shut down > This happens on both sides of the cluster, so it's not limited to one or the > other. This crash does *not* occur in the A1->A2/B1->B2 test (i.e. the test > where the route is re-bound correctly). I can cause this to reoccur pretty > much every time. I've been resetting the cluster completely to a new state > between each test. Occasionally in the B2->B1 test, A1 will also crash with > the same error (and vice versa for A2->A1 for node B1), though most of the > time, it's A2/B2 that crashes. > I was getting this same behaviour prior to upgrading corosync/openais as > well. Previously I was using the stock Squeeze versions of corosync==1.2.1 > and openais==1.1.2. The results are the same with corosync=1.3.0 and > openais==1.1.4. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Issue Comment Edited: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995336#comment-12995336 ] michael j. goulish edited comment on QPID-2993 at 2/16/11 3:23 PM: --- Well, with the latest code tree ( r1071018 ) I do indeed find something interesting. I cannot get it to actually crash, but with the attached script ( 2993_bug.sh ) running on a fast 8-proc system, I was able to see 2 out of 10 instances of broker A2 failing to start up, and logging the following error: 2011-02-16 09:34:23 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical cluster(20.0.100.36:11855 READY/error) local error 1498 did not occur on member 20.0.100.36:11714: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-02-16 09:34:23 notice cluster(20.0.100.36:11855 LEFT/error) leaving cluster A 2011-02-16 09:34:23 notice Shut down === and, by the way, the store version is 4439 was (Author: mgoulish2): Well, with the latest code tree ( r1071018 ) I do indeed find something interesting. I cannot get it to actually crash, but with the attached script ( 2993_bug.sh ) running on a fast 8-proc system, I was able to see 2 out of 10 instances of broker A2 failing to start up, and logging the following error: 2011-02-16 09:34:23 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical cluster(20.0.100.36:11855 READY/error) local error 1498 did not occur on member 20.0.100.36:11714: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-02-16 09:34:23 notice cluster(20.0.100.36:11855 LEFT/error) leaving cluster A 2011-02-16 09:34:23 notice Shut down > Federated source-local links crash remotely federated cluster member on local > cluster startup > - > > Key: QPID-2993 > URL: https://issues.apache.org/jira/browse/QPID-2993 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Clustering >Affects Versions: 0.8 > Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell > Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 >Reporter: Mark Moseley >Assignee: michael j. goulish > Attachments: 2993_bug.sh, cluster-fed-src.sh > > > This is related to JIRA 2992 that I opened, but this is for source-local > routes. Given the same setup as in JIRA 2992 but using source-local routes > (and obviously with the exchanges switched accordingly in the qpid-route > statements), i.e. cluster A and cluster B with the routes between A1<->B1, > when cluster B shuts down in the order B2->B1 and starts back up, the static > routes are not correctly re-bound on cluster A's side. However if cluster B > is shut down in the order B1->B2 and started back up, the route is correctly > created and works. However in the non-functioning case (B2->B1, or A2->A1), > there is an additional side-effect: on node A2, qpidd crashes with the > following error (cluster A is called 'walclust', B is bosclust): > 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not > attached (qpid/amqp_0_10/SessionHandler.cpp:39) > 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error > 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not > attached (qpid/amqp_0_10/SessionHandler.cpp:39) > 2011-01-07 18:57:35 critical Error delivering frames: local error did not > occur on all cluster members : not-attached: Channel 1 is not attached > (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) > 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving > cluster walclust > 2011-01-07 18:57:35 notice Shut down > This happens on both sides of the cluster, so it's not limited to one or the > other. This crash does *not* occur in the A1->A2/B1->B2 test (i.e. the test > where the route is re-bound correctly). I can cause this to reoccur pretty > much every time. I've been resetting the cluster completely to a new state > between each test. Occasionally in the B2->B1 test, A1 will also
[jira] Created: (QPID-3063) Python Client messaging/endpoints.py Connection Class: def check_closed(self): method crashes when called.
Python Client messaging/endpoints.py Connection Class: def check_closed(self): method crashes when called. --- Key: QPID-3063 URL: https://issues.apache.org/jira/browse/QPID-3063 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: 0.7 Environment: RHEL 5.0 Python2.7 Reporter: Nick Capito Priority: Trivial When calling the Connection Classes .check_closed method an exception is raised: Traceback (most recent call last): File "/Harness_Test.py", line 24, in test_create_connection self.assertFalse(connection.check_closed() ) File "/usr/local/lib/python2.7/site-packages/qpid/messaging/endpoints.py", line 200, in check_closed if self.closed: AttributeError: Connection instance has no attribute 'closed' The fix is pretty simple, get rid of the method, or add a self.closed flag to indicate failure... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] add a pre-commit hook to check for JIRA references
[X] +1, I accept the proposal and vote to add the svn pre-commit hook as outlined above. -K - Original Message - > On 15 Feb 2011, at 13:56, Ted Ross wrote: > > +1 but I would like to see a crisper definition of the proposal: > > > > Commits are rejected unless the commit comment contains a valid > > QPID- Jira reference OR 'NO-JIRA'. A Jira reference is > > valid if it references an existing issue in the Qpid project. > > I don't know if this is what is used on the ASF Subversion > repository, but it *is* the 'official' JIRA way of doing what you > want: > > https://studio.plugins.atlassian.com/wiki/display/CMMT/JIRA+Commit > +Acceptance > > Also, here's a 'crisper definition' I prepared earlier: > > https://cwiki.apache.org/confluence/display/qpid/Subversion+Commit > +Comment+Format > > Cheers, > Andrew. > -- > -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ; > -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ; > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Pre commit hook for Apache License Header ?
The automated RAT report is a good alternative IMO. However I still think a license check is not a bad idea as it will only come into play when somebody adds a file. It seems other have atleast tried this. http://osdir.com/ml/windows.dotnet.castleproject.devel/2005-07/msg00266.html Rajith On Tue, Feb 15, 2011 at 4:54 PM, Andrew Kennedy < andrewinternatio...@gmail.com> wrote: > On 15 Feb 2011, at 19:49, Robbie Gemmell wrote: > >> There is scope for inaccurate results on licence matching, and >> exceptions could also be a pain if conducted pre-commit, so I'm not >> sure it should be a commit hook. We should really just have RAT >> running automated checks for us on the ASF CI boxes (along with >> several other types of testing...) on a regular basis. >> > > > Agree. > > There is a Maven plug-in for that. I have set up my Mavenised Qpid build to > run a RAT report automatically during CI, as part of the "mvn site" > generation. This works vey nicely, and if^H^Hwhen we move to Maven from Ant, > we can set it up very easily. > > Andrew. > -- > -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ; > -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ; > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
Re: 0.10 release update - feature integration week
On Tue, Feb 15, 2011 at 2:08 AM, Justin Ross wrote: > Hi, folks. Our schedule (appended below) calls for all major features to be > functionally complete and on trunk by the 16th, this Wednesday. I'd love to be able to get my PHP binding into the next release... but its not quite complete yet (very, very close). > We can make exceptions for changes that don't threaten to destabilize the > release. If you'd like an exception, it's quite important that we discuss > it now. So I'd like an exception then :) The PHP binding certainly won't destabilize anything. But if it makes more sense to put the PHP binding off to a later release to give it time to mature / prove, then that's fine with me ;) As it is, I expect it to be "complete" sometime next week (though I'm not sure how much is involved in implementing automake support (?). Thanks :) BTW, what happened to a 0.9 release? Are odd point releases being used for dev-only, or was 0.9 skipped for some reason (eg syncing with AMQP standard versioning?), or is 0.9 still in progress are you guys are just looking even further ahead to 0.10? (just curious). paul. > > I'll begin running the release scripts tomorrow in order to discover any new > issues for the alpha release. > > Thanks, > Justin > > --- > > 0.10 feature and improvement jiras: > > http://bit.ly/h3Q7Sk > > 0.10 schedule: > > 16 Feb > > - Alpha > - Trunk remains open > - Feature integration ends > - The alpha release tests the release process after the > introduction of major features > > 2 Mar, 2 weeks later > > - Beta > - Branch for release (trunk remains open) > - Release branch commits require approval > - Release manager produces outstanding bug report, triages bugs > > 16 Mar, 2 weeks later > > - RC1 > > 23 Mar, 1 week later > > - RC2 > > 30 Mar, 1 week later > > - RC3 > - Targeted release date > > > > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.10 release update - feature integration week
On 02/16/2011 04:10 PM, Paul Colby wrote: As it is, I expect it to be "complete" sometime next week (though I'm not sure how much is involved in implementing automake support (?). go for it, let's try get it in. BTW, what happened to a 0.9 release? Are odd point releases being used for dev-only, or was 0.9 skipped for some reason (eg syncing with AMQP standard versioning?), or is 0.9 still in progress are you guys are just looking even further ahead to 0.10? (just curious). 0.9 is the dev release Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.10 release update - feature integration week
On Thu, 17 Feb 2011, Paul Colby wrote: On Tue, Feb 15, 2011 at 2:08 AM, Justin Ross wrote: Hi, folks. Our schedule (appended below) calls for all major features to be functionally complete and on trunk by the 16th, this Wednesday. I'd love to be able to get my PHP binding into the next release... but its not quite complete yet (very, very close). We can make exceptions for changes that don't threaten to destabilize the release. If you'd like an exception, it's quite important that we discuss it now. So I'd like an exception then :) The PHP binding certainly won't destabilize anything. But if it makes more sense to put the PHP binding off to a later release to give it time to mature / prove, then that's fine with me ;) As it is, I expect it to be "complete" sometime next week (though I'm not sure how much is involved in implementing automake support (?). Thanks :) Hi, Paul. I agree, a new binding, provided it's isolated, is not a danger to the release. That means you have more time, until we branch for beta. I'd like to hear others' comments, but I tend to think we should adopt things like this under some kind of preview status so that we can carefully communicate about API stability and support. BTW, what happened to a 0.9 release? Are odd point releases being used for dev-only, or was 0.9 skipped for some reason (eg syncing with AMQP standard versioning?), or is 0.9 still in progress are you guys are just looking even further ahead to 0.10? (just curious). We use linux kernel-esque numbering, meaning 0.9 is dev only. 0.9 turns into 0.10 upon release. Justin - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2784) C++ Example with new Addressing and API
[ https://issues.apache.org/jira/browse/QPID-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995553#comment-12995553 ] William Henry commented on QPID-2784: - Can someone please look over this and replace the old tradedemo with this feeddemo example? > C++ Example with new Addressing and API > --- > > Key: QPID-2784 > URL: https://issues.apache.org/jira/browse/QPID-2784 > Project: Qpid > Issue Type: Improvement > Components: Qpid Examples >Affects Versions: 0.7 >Reporter: William Henry > Fix For: 0.9 > > Attachments: feeddemo.tar > > Original Estimate: 2h > Remaining Estimate: 2h > > I've updated the trade demo (tradedemo) example for the new addressing and > renamed it feeddemo (as it is really about ticker and market data feeds and > not trades). > I'd like to know if this sort of demo is still useful. I think it is, but we > also have the reservation system demo. What's nice about this example is that > is used TTL and LVQ. > See the attached files. Note that the OptionParser.h/.cpp is the one already > used in drain/spout etc. so it ought to be made common. > It can be tested tested by: > 1. running setup_broker.sh which creates the exchanges. > 2. Run a feed_listener (you can run it for ticker info or market data using > -t or -m or with a custom exchange or all three: > a. ./feed_listener -t 1 -m 0 (actually default is this so you can just run > ./feed_listener) > b. ./feed_listener -t 0 -m 1 > c. ./feed_listener -t 0 -m 0 TICKER/NYSE.RHT > d. ./feed_listener -m 1 TICKER/NYSE.RHT(TICKER/NYSE.RHT is just an > example) > 3. Run feed_publisher e.g.: ./feed_publisher -c 1000 > William -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.10 release update - feature integration week
Hi Justin, I'm going to try and get Kerry Bonin's QPID-2519 in, allowing the broker to run as a service on Windows. Is it legit to get that in by the end of the week or no? -Steve > -Original Message- > From: Justin Ross [mailto:jr...@redhat.com] > Sent: Monday, February 14, 2011 10:09 AM > To: dev@qpid.apache.org > Subject: 0.10 release update - feature integration week > > > Hi, folks. Our schedule (appended below) calls for all major > features to > be functionally complete and on trunk by the 16th, this Wednesday. > > This means we are rapidly approaching the point where we make > choices. If > something won't be ready in time, we need to kick it to the > next release. > > We can make exceptions for changes that don't threaten to > destabilize the > release. If you'd like an exception, it's quite important > that we discuss > it now. > > I'll begin running the release scripts tomorrow in order to > discover any > new issues for the alpha release. > > Thanks, > Justin > > --- > > 0.10 feature and improvement jiras: > >http://bit.ly/h3Q7Sk > > 0.10 schedule: > >16 Feb > > - Alpha > - Trunk remains open > - Feature integration ends > - The alpha release tests the release process after the >introduction of major features > >2 Mar, 2 weeks later > > - Beta > - Branch for release (trunk remains open) > - Release branch commits require approval > - Release manager produces outstanding bug report, triages bugs > >16 Mar, 2 weeks later > > - RC1 > >23 Mar, 1 week later > > - RC2 > >30 Mar, 1 week later > > - RC3 > - Targeted release date > > > > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.10 release update - feature integration week
Hi, Steve. End of the week is certainly okay. I see that change introduces some (warning, speaking from some naivete here) big changes to broker config. If that's the case, I'd like it to get a shot at some extra review. Justin On Wed, 16 Feb 2011, Steve Huston wrote: Hi Justin, I'm going to try and get Kerry Bonin's QPID-2519 in, allowing the broker to run as a service on Windows. Is it legit to get that in by the end of the week or no? -Steve -Original Message- From: Justin Ross [mailto:jr...@redhat.com] Sent: Monday, February 14, 2011 10:09 AM To: dev@qpid.apache.org Subject: 0.10 release update - feature integration week Hi, folks. Our schedule (appended below) calls for all major features to be functionally complete and on trunk by the 16th, this Wednesday. This means we are rapidly approaching the point where we make choices. If something won't be ready in time, we need to kick it to the next release. We can make exceptions for changes that don't threaten to destabilize the release. If you'd like an exception, it's quite important that we discuss it now. I'll begin running the release scripts tomorrow in order to discover any new issues for the alpha release. Thanks, Justin --- 0.10 feature and improvement jiras: http://bit.ly/h3Q7Sk 0.10 schedule: 16 Feb - Alpha - Trunk remains open - Feature integration ends - The alpha release tests the release process after the introduction of major features 2 Mar, 2 weeks later - Beta - Branch for release (trunk remains open) - Release branch commits require approval - Release manager produces outstanding bug report, triages bugs 16 Mar, 2 weeks later - RC1 23 Mar, 1 week later - RC2 30 Mar, 1 week later - RC3 - Targeted release date - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.10 release update - feature integration week
> Hi, Steve. End of the week is certainly okay. Ok, thanks. > I see that change introduces some (warning, speaking from > some naivete > here) big changes to broker config. If that's the case, I'd > like it to > get a shot at some extra review. It's in JIRA... Reviews are welcome. Some of my earlier review to the submitter wasn't acted on, so there's real work to be done to get it ready for inclusion. If my time is less free than I anticipate I may not have time to get it in, but I'm going to try. -Steve > On Wed, 16 Feb 2011, Steve Huston wrote: > > > Hi Justin, > > > > I'm going to try and get Kerry Bonin's QPID-2519 in, allowing the > > broker to run as a service on Windows. > > > > Is it legit to get that in by the end of the week or no? > > > > -Steve > > > >> -Original Message- > >> From: Justin Ross [mailto:jr...@redhat.com] > >> Sent: Monday, February 14, 2011 10:09 AM > >> To: dev@qpid.apache.org > >> Subject: 0.10 release update - feature integration week > >> > >> > >> Hi, folks. Our schedule (appended below) calls for all major > >> features to be functionally complete and on trunk by the > 16th, this > >> Wednesday. > >> > >> This means we are rapidly approaching the point where we make > >> choices. If something won't be ready in time, we need to > kick it to > >> the next release. > >> > >> We can make exceptions for changes that don't threaten to > destabilize > >> the release. If you'd like an exception, it's quite important > >> that we discuss > >> it now. > >> > >> I'll begin running the release scripts tomorrow in order > to discover > >> any new issues for the alpha release. > >> > >> Thanks, > >> Justin > >> > >> --- > >> > >> 0.10 feature and improvement jiras: > >> > >>http://bit.ly/h3Q7Sk > >> > >> 0.10 schedule: > >> > >>16 Feb > >> > >> - Alpha > >> - Trunk remains open > >> - Feature integration ends > >> - The alpha release tests the release process after the > >>introduction of major features > >> > >>2 Mar, 2 weeks later > >> > >> - Beta > >> - Branch for release (trunk remains open) > >> - Release branch commits require approval > >> - Release manager produces outstanding bug report, > triages bugs > >> > >>16 Mar, 2 weeks later > >> > >> - RC1 > >> > >>23 Mar, 1 week later > >> > >> - RC2 > >> > >>30 Mar, 1 week later > >> > >> - RC3 > >> - Targeted release date > >> > >> > >> > >> > >> > >> > >> > - > >> Apache Qpid - AMQP Messaging Implementation > >> Project: http://qpid.apache.org > >> Use/Interact: mailto:dev-subscr...@qpid.apache.org > >> > >> > > > > > > > - > > Apache Qpid - AMQP Messaging Implementation > > Project: http://qpid.apache.org > > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-3016) Java JMS client ReplyTo memory leak
[
https://issues.apache.org/jira/browse/QPID-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kennedy reassigned QPID-3016:
Assignee: Robbie Gemmell (was: Andrew Kennedy)
Please review
> Java JMS client ReplyTo memory leak
> ---
>
> Key: QPID-3016
> URL: https://issues.apache.org/jira/browse/QPID-3016
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.8
> Environment: Fedora 14: 2.6.35.10-74.fc14.x86_64
> Broker: qpidd (qpidc) version 0.8
> Java Client 0.8
> OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-x86_64)
> OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
>Reporter: David Kellum
>Assignee: Robbie Gemmell
>
> I'm using the Java 0.8 client JMS interface. Relevant Client code is below.
> If I make async requests to a queue with setJMSReplyTo as temporary queue for
> responses, the client process will run out of memory after about 3.2M
> request/response message pairs. This is at 512MB max java heap, though growth
> appears to be consistently linear. Note that I use a semaphore between
> request and response to keep ~1000 unanswered requests open in the client and
> block before sending more. Thus this should not be a matter of simply
> saturating the client with unsent messages.
> Here is the top of the jhat histogram from jmap heap dump shortly before
> client runs out of memory:
> class org.apache.qpid.collections.ReferenceMap$SoftRef 3253120
> 143137280
> class org.apache.qpid.collections.ReferenceMap$Entry3253120
> 117112320
> class [Lorg.apache.qpid.collections.ReferenceMap$Entry; 1
> 67108880
> class org.apache.qpid.transport.ReplyTo 3253120
> 61809280
> Note that 3253120 appears to match the total number of request/replies
> successfully processed by the client up to this point. Or in other words, its
> leaking one ReplyTo object and associated (not so?) soft references per
> request/response.
> If instead I replace the temporary queue with a fixed response and drop use
> of setJMSReplyTo(), the client works fine, no memory leak.
> Below are more details when running with the temp response queue:
> % qpid-config queues
> Queue Name Attributes
> ==
> TempQueued4051d9d-37d3-4306-a1fc-91b93f7082c8 auto-del excl
> iudex-brutefuzzy-request --max-queue-size=10
> --limit-policy=reject
> Client startup Log:
> 635 [main] INFO o.a.q.j.PropertiesFileInitialContextFactory - No Provider
> URL specified.
> 726 [main] INFO o.a.qpid.client.AMQConnection -
> Connection:amqp://qpid:@default-client/default-vhost?brokerlist='tcp://localhost:5672'
> 973 [main] INFO o.a.q.c.p.AMQProtocolSession - Using ProtocolVersion for
> Session:0-10
> 990 [main] INFO o.a.q.c.h.ClientMethodDispatcherImpl - New Method
> Dispatcher:AMQProtocolSession[null]
> 1002 [main] INFO o.a.qpid.client.AMQConnection - Connecting with
> ProtocolHandler Version:0-10
> 1150 [main] INFO o.a.qpid.client.AMQConnection - Connected with
> ProtocolHandler Version:0-10
> 1192 [main] INFO o.a.qpid.client.AMQSession - Created
> session:org.apache.qpid.client.AMQSession_0_10@1b7c63f
> 1280 [main] INFO o.a.q.c.BasicMessageProducer_0_10 - MessageProducer
> org.apache.qpid.client.BasicMessageProducer_0_10@1727745 using publish mode :
> ASYNC_PUBLISH_ALL
> 1503 [main] INFO o.a.qpid.client.AMQSession - Prefetching delayed existing
> messages will not flow until requested via receive*() or setML().
> 1586 [main] INFO o.a.q.c.AMQSession.Dispatcher - Dispatcher-Channel-1 created
> 1586 [Dispatcher-Channel-1] INFO o.a.q.c.AMQSession.Dispatcher -
> Dispatcher-Channel-1 started
> Relevent client code:
> public class Client
> implements MessageListener, Closeable, ExceptionListener
> {
> public Client( JMSContext context )
> throws JMSException, NamingException
> {
> _connection = context.createConnection();
> _session = context.createSession( _connection );
> Destination requestQueue =
> context.lookupDestination( "iudex-brutefuzzy-request" );
> _producer = _session.createProducer( requestQueue );
> context.close();
> _responseQueue = _session.createTemporaryQueue();
> _session.createConsumer( _responseQueue ).setMessageListener(this);
> _connection.start();
> }
> public void sendRequest( long simhash, boolean doAdd )
> throws JMSException, InterruptedException
> {
> Builder bldr = Request.newBuilder();
> bldr.setSimhash( simhash );
> bldr.setAction( doAdd ? RequestAction.ADD : RequestAction.CHECK_ONLY
> );
> BytesMessag
[jira] Resolved: (QPID-3016) Java JMS client ReplyTo memory leak
[
https://issues.apache.org/jira/browse/QPID-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kennedy resolved QPID-3016.
--
Resolution: Fixed
Fix Version/s: 0.9
Ready for review
> Java JMS client ReplyTo memory leak
> ---
>
> Key: QPID-3016
> URL: https://issues.apache.org/jira/browse/QPID-3016
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.8
> Environment: Fedora 14: 2.6.35.10-74.fc14.x86_64
> Broker: qpidd (qpidc) version 0.8
> Java Client 0.8
> OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-x86_64)
> OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
>Reporter: David Kellum
>Assignee: Robbie Gemmell
> Fix For: 0.9
>
>
> I'm using the Java 0.8 client JMS interface. Relevant Client code is below.
> If I make async requests to a queue with setJMSReplyTo as temporary queue for
> responses, the client process will run out of memory after about 3.2M
> request/response message pairs. This is at 512MB max java heap, though growth
> appears to be consistently linear. Note that I use a semaphore between
> request and response to keep ~1000 unanswered requests open in the client and
> block before sending more. Thus this should not be a matter of simply
> saturating the client with unsent messages.
> Here is the top of the jhat histogram from jmap heap dump shortly before
> client runs out of memory:
> class org.apache.qpid.collections.ReferenceMap$SoftRef 3253120
> 143137280
> class org.apache.qpid.collections.ReferenceMap$Entry3253120
> 117112320
> class [Lorg.apache.qpid.collections.ReferenceMap$Entry; 1
> 67108880
> class org.apache.qpid.transport.ReplyTo 3253120
> 61809280
> Note that 3253120 appears to match the total number of request/replies
> successfully processed by the client up to this point. Or in other words, its
> leaking one ReplyTo object and associated (not so?) soft references per
> request/response.
> If instead I replace the temporary queue with a fixed response and drop use
> of setJMSReplyTo(), the client works fine, no memory leak.
> Below are more details when running with the temp response queue:
> % qpid-config queues
> Queue Name Attributes
> ==
> TempQueued4051d9d-37d3-4306-a1fc-91b93f7082c8 auto-del excl
> iudex-brutefuzzy-request --max-queue-size=10
> --limit-policy=reject
> Client startup Log:
> 635 [main] INFO o.a.q.j.PropertiesFileInitialContextFactory - No Provider
> URL specified.
> 726 [main] INFO o.a.qpid.client.AMQConnection -
> Connection:amqp://qpid:@default-client/default-vhost?brokerlist='tcp://localhost:5672'
> 973 [main] INFO o.a.q.c.p.AMQProtocolSession - Using ProtocolVersion for
> Session:0-10
> 990 [main] INFO o.a.q.c.h.ClientMethodDispatcherImpl - New Method
> Dispatcher:AMQProtocolSession[null]
> 1002 [main] INFO o.a.qpid.client.AMQConnection - Connecting with
> ProtocolHandler Version:0-10
> 1150 [main] INFO o.a.qpid.client.AMQConnection - Connected with
> ProtocolHandler Version:0-10
> 1192 [main] INFO o.a.qpid.client.AMQSession - Created
> session:org.apache.qpid.client.AMQSession_0_10@1b7c63f
> 1280 [main] INFO o.a.q.c.BasicMessageProducer_0_10 - MessageProducer
> org.apache.qpid.client.BasicMessageProducer_0_10@1727745 using publish mode :
> ASYNC_PUBLISH_ALL
> 1503 [main] INFO o.a.qpid.client.AMQSession - Prefetching delayed existing
> messages will not flow until requested via receive*() or setML().
> 1586 [main] INFO o.a.q.c.AMQSession.Dispatcher - Dispatcher-Channel-1 created
> 1586 [Dispatcher-Channel-1] INFO o.a.q.c.AMQSession.Dispatcher -
> Dispatcher-Channel-1 started
> Relevent client code:
> public class Client
> implements MessageListener, Closeable, ExceptionListener
> {
> public Client( JMSContext context )
> throws JMSException, NamingException
> {
> _connection = context.createConnection();
> _session = context.createSession( _connection );
> Destination requestQueue =
> context.lookupDestination( "iudex-brutefuzzy-request" );
> _producer = _session.createProducer( requestQueue );
> context.close();
> _responseQueue = _session.createTemporaryQueue();
> _session.createConsumer( _responseQueue ).setMessageListener(this);
> _connection.start();
> }
> public void sendRequest( long simhash, boolean doAdd )
> throws JMSException, InterruptedException
> {
> Builder bldr = Request.newBuilder();
> bldr.setSimhash( simhash );
> bldr.setAction( doAdd ? RequestAction.ADD : RequestAction.CHECK_ONLY
>
[jira] Resolved: (QPID-3048) InternalBrokerBasecase not removing all log actors
[ https://issues.apache.org/jira/browse/QPID-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy resolved QPID-3048. -- Resolution: Fixed Committed changes > InternalBrokerBasecase not removing all log actors > -- > > Key: QPID-3048 > URL: https://issues.apache.org/jira/browse/QPID-3048 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.9 > > > The InternalBrokerbaseCase checks if CurrentActor.get() returns null, however > in CurrentActor this can never happen, since we return a default if the stack > is empty. Adding a removeAll method to CurrentActor will allow test cases to > clean up properly. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Closed: (QPID-3048) InternalBrokerBasecase not removing all log actors
[ https://issues.apache.org/jira/browse/QPID-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy closed QPID-3048. Closing issue > InternalBrokerBasecase not removing all log actors > -- > > Key: QPID-3048 > URL: https://issues.apache.org/jira/browse/QPID-3048 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.9 > > > The InternalBrokerbaseCase checks if CurrentActor.get() returns null, however > in CurrentActor this can never happen, since we return a default if the stack > is empty. Adding a removeAll method to CurrentActor will allow test cases to > clean up properly. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
