Review Request: Avoid using ntohl()/ntohs()/htonl()/htons()
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8385/ --- Review request for qpid, Cliff Jansen and Rafael Schloming. Description --- Removed the use of [nh]to[hn][ls] in the ANSI only part of the code as they are part of BSD sockets API not in ANSI C. There is now some duplication of code which should be removed, but nothing serious in my opinion. This addresses bug PROTON-121. https://issues.apache.org/jira/browse/PROTON-121 Diffs - /proton/trunk/proton-c/src/codec/codec.c 1417656 /proton/trunk/proton-c/src/framing/framing.c 1417656 Diff: https://reviews.apache.org/r/8385/diff/ Testing --- Compiled under Fedora and run proton-test against the built code. Thanks, Andrew Stitcher
[jira] [Comment Edited] (QPID-4387) HA test_failover_send_receive sporadically stalls
[ https://issues.apache.org/jira/browse/QPID-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525818#comment-13525818 ] Alan Conway edited comment on QPID-4387 at 12/6/12 10:29 PM: - To reproduce, cd to tests build directory and: source test_env.sh; while ha_tests.py *.test_failover_send_receive -DDURATION=2; do date; done Actual result: fails after a few iterations with a message AssertionError: Stalled... Expected result: test loop should continue forever. was (Author: aconway): To reproduce, cd to tests build directory and: source test_env.sh; while ha_tests.py *.test_failover_send_receive; do date; done Actual result: the tests eventually fail with a message AssertionError: Stalled... Expected result: test loop should continue forever. > HA test_failover_send_receive sporadically stalls > -- > > Key: QPID-4387 > URL: https://issues.apache.org/jira/browse/QPID-4387 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.19 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > > test_failover_send_receive fails sporadically with an error like: > AssertionError: Stalled test9 at 1548 > one of the receivers has exceeded the timeout for getting another message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4387) HA test_failover_send_receive sporadically stalls
[ https://issues.apache.org/jira/browse/QPID-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525818#comment-13525818 ] Alan Conway commented on QPID-4387: --- To reproduce, cd to tests build directory and: source test_env.sh; while ha_tests.py *.test_failover_send_receive; do date; done Actual result: the tests eventually fail with a message AssertionError: Stalled... Expected result: test loop should continue forever. > HA test_failover_send_receive sporadically stalls > -- > > Key: QPID-4387 > URL: https://issues.apache.org/jira/browse/QPID-4387 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.19 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > > test_failover_send_receive fails sporadically with an error like: > AssertionError: Stalled test9 at 1548 > one of the receivers has exceeded the timeout for getting another message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking
Hi both, Thanks for this - and sorry for the problems it caused you Alan. I did this a while back for Qpid 0.12 'cause I'm running Ubuntu 11.10 (well Mint 12 really) and ended up tearing my hair out for a while. I'd sort of assumed that Qpid was mainly going to be targeted ad RHEL given the RH core team so had resigned myself to always having to hack and patch to get it up and running on Ubuntu and had submitted this more in hope than anything. It's the main reason I've stuck with 0.12 as my work on the Qpid Web UI hasn't left me much time to tinker with this stuff. I'm really pleased that this stuff is making it into main now, so thanks for that and sorry for the issues, I'm afraid that I know SFA about the magic of libtool/automake and all that I'm afraid I was winging it rather - it's a miracle it worked as well as it did :-) Cheers, Frase. On 06/12/12 15:18, Alan Conway wrote: On Thu, 2012-12-06 at 11:54 +, Gordon Sim wrote: On 12/05/2012 08:44 PM, Alan Conway wrote: There is a serious problem with this patch. My build (on RHEL5 at trunk r1417511) fails with lots of these: g++: /usr/lib64/libqpidcommon.so: No such file or directory g++: /usr/lib64/libqpidtypes.so: No such file or directory It looksl like using -lqpidcommon on the link line tries to link with the library installed in /usr/lib, and fails to build if Qpid is not installed. It is most important that qpid's own libraries be specified via an explicit path, and not discovered by the linker, to ensure that a build actually links with its own libraries. I'm not sure what the proper way to do this is with libtool (curse you libtool) but I don't think we can leave it this way. I couldn't reproduce the problem on RHEL 5.8, using latest trunk. Whether or not there were qpid libraries installed it seemed to pick up the correct ones from the build for me). That said, we should probably be linking against the .la with libtool? That seems to have been the approach previously which didn't cause these problems. Attached is a patch that would do this. Are you able to test it on the system that caused problems to ensure it does actually fix the problem? It works for me on Fedora 17 and RHEL 5.8, but as I say I couldn't reproduce the problem in the first place. The patch works, I approve. Using full paths to the libs is much safer than letting the linker find them. I misspoke earlier - I actually saw this on RHEL 6.2. Cheers, Alan. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4485) QMF agent management object list corruption.
[ https://issues.apache.org/jira/browse/QPID-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512091#comment-13512091 ] Ken Giusti commented on QPID-4485: -- thanks - merged to 0.20: http://svn.apache.org/viewvc?view=revision&revision=1418065 > QMF agent management object list corruption. > > > Key: QPID-4485 > URL: https://issues.apache.org/jira/browse/QPID-4485 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework >Affects Versions: 0.19 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.21 > > > agentLock mutex is not held during message handling. This will lead to > corruption of the management object database maintained by the Agent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking
On Thu, 2012-12-06 at 18:36 +, Fraser Adams wrote: > Hi both, > Thanks for this - and sorry for the problems it caused you Alan. I did > this a while back for Qpid 0.12 'cause I'm running Ubuntu 11.10 (well > Mint 12 really) and ended up tearing my hair out for a while. > > I'd sort of assumed that Qpid was mainly going to be targeted ad RHEL > given the RH core team so had resigned myself to always having to hack > and patch to get it up and running on Ubuntu and had submitted this more > in hope than anything. > > It's the main reason I've stuck with 0.12 as my work on the Qpid Web UI > hasn't left me much time to tinker with this stuff. > > I'm really pleased that this stuff is making it into main now, so thanks > for that and sorry for the issues, I'm afraid that I know SFA about the > magic of libtool/automake and all that I'm afraid I was winging it > rather - it's a miracle it worked as well as it did :-) > No need to apologize, breaking things is an inevitable part of making them better :) Your contributions are greatly appreciated. I *really* hate libtool/automake. It's over-complicated and not at all intuitive. I dream of the day we'll toss it and use cmake only (though I may come to hate cmake after that...) Cheers, Alan. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: More 0.20 requests for inclusion
On Tue, 4 Dec 2012, Ken Giusti wrote: Hi Justin, Caught this the other day: https://issues.apache.org/jira/browse/QPID-4485 Not technically a regression, but a potential crasher with a simple fix. What say ye? -K Approved. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4485) QMF agent management object list corruption.
[ https://issues.apache.org/jira/browse/QPID-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512057#comment-13512057 ] Justin Ross commented on QPID-4485: --- Reviewed by Ted. Approved for 0.20. > QMF agent management object list corruption. > > > Key: QPID-4485 > URL: https://issues.apache.org/jira/browse/QPID-4485 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework >Affects Versions: 0.19 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.21 > > > agentLock mutex is not held during message handling. This will lead to > corruption of the management object database maintained by the Agent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4485) QMF agent management object list corruption.
[ https://issues.apache.org/jira/browse/QPID-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-4485: -- Assignee: Ken Giusti (was: Ted Ross) > QMF agent management object list corruption. > > > Key: QPID-4485 > URL: https://issues.apache.org/jira/browse/QPID-4485 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework >Affects Versions: 0.19 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.21 > > > agentLock mutex is not held during message handling. This will lead to > corruption of the management object database maintained by the Agent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: another 0.20 request (was Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking)
On 12/06/2012 07:37 PM, Justin Ross wrote: On Thu, 6 Dec 2012, Gordon Sim wrote: Justin, can I request permission to make that change to 0.20 also? Simply because we backported the change that caused this error in Alan's case and he reports this fixes it. Approved. Thanks! Committed to branch now. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3723) qpid 0.12 make fails on Linux Mint 12 (I think derived from Ubuntu 11.10)
[ https://issues.apache.org/jira/browse/QPID-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512055#comment-13512055 ] Gordon Sim commented on QPID-3723: -- Further fix was backported to 0.20 as r1418048. > qpid 0.12 make fails on Linux Mint 12 (I think derived from Ubuntu 11.10) > -- > > Key: QPID-3723 > URL: https://issues.apache.org/jira/browse/QPID-3723 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: 0.12, 0.19 > Environment: qpid 0.12 C++ > make fails on Linux Mint 12 but will probably also have issues with any very > recent gcc version. > also Ubuntu 12.04 >Reporter: Fraser Adams > Fix For: 0.20, 0.21 > > Attachments: fix-explicit-link-problem.patch > > > make for qpid 0.12 fails in a number of places. > See the following mailing list thread for more details: > http://qpid.2158936.n2.nabble.com/qpid-0-12-make-fails-on-Linux-Mint-12-I-think-derived-from-Ubuntu-11-10-td7140482.html > I believe this relates to changes made to the linker behaviour for recent gcc > versions so I suspect that this issue isn't limited to Linux Mint 12. See > http://fedoraproject.org/wiki/UnderstandingDSOLinkChange (this is a Fedora > page and I'm using Mint but the symptoms seem identical). > I've put together a patch for this which I'll attach when the Jira gets > created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4485) QMF agent management object list corruption.
[ https://issues.apache.org/jira/browse/QPID-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512053#comment-13512053 ] Ted Ross commented on QPID-4485: Looks good, ship it. > QMF agent management object list corruption. > > > Key: QPID-4485 > URL: https://issues.apache.org/jira/browse/QPID-4485 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework >Affects Versions: 0.19 >Reporter: Ken Giusti >Assignee: Ted Ross > Fix For: 0.21 > > > agentLock mutex is not held during message handling. This will lead to > corruption of the management object database maintained by the Agent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: More 0.20 requests for inclusion
On Wed, 5 Dec 2012, Hiram Chirino wrote: Not sure if it's too late to add more bits into 0.20, but I would love it if rev 1417368 to fix QPID-4454 could get merged in. This change would allow us to fully pass the Joram JMS compliance test suite against ActiveMQ's proton based AMQP 1.0 impl. Not too late. I asked Rob about this, and he favors it for 0.20. Approved. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: another 0.20 request (was Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking)
On Thu, 6 Dec 2012, Gordon Sim wrote: Justin, can I request permission to make that change to 0.20 also? Simply because we backported the change that caused this error in Alan's case and he reports this fixes it. Approved. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3723) qpid 0.12 make fails on Linux Mint 12 (I think derived from Ubuntu 11.10)
[ https://issues.apache.org/jira/browse/QPID-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511597#comment-13511597 ] Justin Ross commented on QPID-3723: --- Gordon made a further fix in r1418000. Alan reviewed it. Approved for 0.20. > qpid 0.12 make fails on Linux Mint 12 (I think derived from Ubuntu 11.10) > -- > > Key: QPID-3723 > URL: https://issues.apache.org/jira/browse/QPID-3723 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: 0.12, 0.19 > Environment: qpid 0.12 C++ > make fails on Linux Mint 12 but will probably also have issues with any very > recent gcc version. > also Ubuntu 12.04 >Reporter: Fraser Adams > Fix For: 0.20, 0.21 > > Attachments: fix-explicit-link-problem.patch > > > make for qpid 0.12 fails in a number of places. > See the following mailing list thread for more details: > http://qpid.2158936.n2.nabble.com/qpid-0-12-make-fails-on-Linux-Mint-12-I-think-derived-from-Ubuntu-11-10-td7140482.html > I believe this relates to changes made to the linker behaviour for recent gcc > versions so I suspect that this issue isn't limited to Linux Mint 12. See > http://fedoraproject.org/wiki/UnderstandingDSOLinkChange (this is a Fedora > page and I'm using Mint but the symptoms seem identical). > I've put together a patch for this which I'll attach when the Jira gets > created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4493) Memory leak in perl bindings?
[
https://issues.apache.org/jira/browse/QPID-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511591#comment-13511591
]
Darryl L. Pierce commented on QPID-4493:
I found the problem exists even without the larger capacity: it just takes a
lot longer to show up. I ran the above setup but without setting the capacity
and found that, after 2.5 hours, memory had leaked to 2.8% of available in Perl.
Talking with someone else here who mentioned a similar memory leak in Perl
bindings generated in Swig. He's getting me some details for how they diagnosed
the problem and hopefully that will lend itself to the solution.
> Memory leak in perl bindings?
> -
>
> Key: QPID-4493
> URL: https://issues.apache.org/jira/browse/QPID-4493
> Project: Qpid
> Issue Type: Bug
>Affects Versions: 0.18, 0.20
> Environment: RHEL5, RHEL6
>Reporter: Jimmy Jones
>Assignee: Darryl L. Pierce
> Attachments: drain.pl, map_sender.pl
>
>
> I've been having problems with long running code using the perl bindings
> leaking memory, specifically after calls to getProperties and decodeMap.
> To reproduce - edit drain.pl to call {{$receiver->setCapacity(100)}} and then
> run {{drain.pl -f amq.match}}. You'll also need to hack map_sender.pl to send
> to amq.match and loop forever (both attached). The memory usage of drain.pl
> will now start growing...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4454) [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
[
https://issues.apache.org/jira/browse/QPID-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511515#comment-13511515
]
Justin Ross commented on QPID-4454:
---
Reviewed by Rob. Approved for 0.20.
> [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
> ---
>
> Key: QPID-4454
> URL: https://issues.apache.org/jira/browse/QPID-4454
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Hiram Chirino
>Assignee: Rob Godfrey
> Fix For: 0.21
>
> Attachments: QPID-4454-v2.patch
>
>
> The following test case fails:
> Queue dest = session.createQueue("test");
> Message message = session.createMessage();
> message.setJMSReplyTo(dest);
> assertTrue(message.getJMSReplyTo().equals(dest));
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4454) [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
[
https://issues.apache.org/jira/browse/QPID-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated QPID-4454:
--
Fix Version/s: 0.20
> [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
> ---
>
> Key: QPID-4454
> URL: https://issues.apache.org/jira/browse/QPID-4454
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Hiram Chirino
>Assignee: Rob Godfrey
> Fix For: 0.20, 0.21
>
> Attachments: QPID-4454-v2.patch
>
>
> The following test case fails:
> Queue dest = session.createQueue("test");
> Message message = session.createMessage();
> message.setJMSReplyTo(dest);
> assertTrue(message.getJMSReplyTo().equals(dest));
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
another 0.20 request (was Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking)
On 12/06/2012 03:18 PM, Alan Conway wrote: On Thu, 2012-12-06 at 11:54 +, Gordon Sim wrote: On 12/05/2012 08:44 PM, Alan Conway wrote: There is a serious problem with this patch. My build (on RHEL5 at trunk r1417511) fails with lots of these: g++: /usr/lib64/libqpidcommon.so: No such file or directory g++: /usr/lib64/libqpidtypes.so: No such file or directory It looksl like using -lqpidcommon on the link line tries to link with the library installed in /usr/lib, and fails to build if Qpid is not installed. It is most important that qpid's own libraries be specified via an explicit path, and not discovered by the linker, to ensure that a build actually links with its own libraries. I'm not sure what the proper way to do this is with libtool (curse you libtool) but I don't think we can leave it this way. I couldn't reproduce the problem on RHEL 5.8, using latest trunk. Whether or not there were qpid libraries installed it seemed to pick up the correct ones from the build for me). That said, we should probably be linking against the .la with libtool? That seems to have been the approach previously which didn't cause these problems. Attached is a patch that would do this. Are you able to test it on the system that caused problems to ensure it does actually fix the problem? It works for me on Fedora 17 and RHEL 5.8, but as I say I couldn't reproduce the problem in the first place. The patch works, I approve. Using full paths to the libs is much safer than letting the linker find them. I misspoke earlier - I actually saw this on RHEL 6.2. I couldn't reproduce on RHEL 6.2 either... however I have committed to trunk (see r1418000) as I think we are agreed it is a safer change anyway. Justin, can I request permission to make that change to 0.20 also? Simply because we backported the change that caused this error in Alan's case and he reports this fixes it. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4454) [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
[
https://issues.apache.org/jira/browse/QPID-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511491#comment-13511491
]
Rob Godfrey commented on QPID-4454:
---
Yes - I'm happy for this to go into 0.20 (the scope is limited to the JMS
client and the changes are required to fully implement features of the JMS API)
> [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
> ---
>
> Key: QPID-4454
> URL: https://issues.apache.org/jira/browse/QPID-4454
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Hiram Chirino
>Assignee: Rob Godfrey
> Fix For: 0.21
>
> Attachments: QPID-4454-v2.patch
>
>
> The following test case fails:
> Queue dest = session.createQueue("test");
> Message message = session.createMessage();
> message.setJMSReplyTo(dest);
> assertTrue(message.getJMSReplyTo().equals(dest));
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4490) Durable messages with TTL do not expire after broker recovery (c++ store)
[
https://issues.apache.org/jira/browse/QPID-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511480#comment-13511480
]
Chuck Rolke commented on QPID-4490:
---
Fixed even more in r1417963
> Durable messages with TTL do not expire after broker recovery (c++ store)
> -
>
> Key: QPID-4490
> URL: https://issues.apache.org/jira/browse/QPID-4490
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> Durable messages with TTL which are later recovered from the c++ store do not
> expire. The following demonstrates:
> 1. Start broker:
> ./qpidd --load-module msgstore.so --auth no --log-enable info+
> 2. Run client to send two messages:
> ./qpid-send -m 2 --ttl 10 --durable yes -a "test; {create: always, node:
> {durable: True}}"
> 3. Stop and restart broker, recovering the messages.
> 4. Run client to receive messages one at a time:
> ./qpid-receive -m 1 --print-header yes -a test
> TTL: 10
> Durable: true
> Redelivered: true
> Properties: {sn:1, ts:1354716748759170497, x-amqp-0-10.routing-key:test}
> ./qpid-receive -m 1 --print-header yes -a test
> TTL: 10
> Durable: true
> Redelivered: true
> Properties: {sn:2, ts:1354716748759340826, x-amqp-0-10.routing-key:test}
> For both messages the TTL of the recovered messages is set to 10 (the
> initial setting), but the timer is not running, and the TTL never decreases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4454) [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
[
https://issues.apache.org/jira/browse/QPID-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511473#comment-13511473
]
Justin Ross commented on QPID-4454:
---
Rob, should we port this one to 0.20?
> [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
> ---
>
> Key: QPID-4454
> URL: https://issues.apache.org/jira/browse/QPID-4454
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Hiram Chirino
>Assignee: Rob Godfrey
> Fix For: 0.21
>
> Attachments: QPID-4454-v2.patch
>
>
> The following test case fails:
> Queue dest = session.createQueue("test");
> Message message = session.createMessage();
> message.setJMSReplyTo(dest);
> assertTrue(message.getJMSReplyTo().equals(dest));
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4454) [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
[
https://issues.apache.org/jira/browse/QPID-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated QPID-4454:
--
Assignee: Rob Godfrey
> [AMQP 1.0 JMS Client] getJMSReplyTo() != the value set with setJMSReplyTo()
> ---
>
> Key: QPID-4454
> URL: https://issues.apache.org/jira/browse/QPID-4454
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Hiram Chirino
>Assignee: Rob Godfrey
> Fix For: 0.21
>
> Attachments: QPID-4454-v2.patch
>
>
> The following test case fails:
> Queue dest = session.createQueue("test");
> Message message = session.createMessage();
> message.setJMSReplyTo(dest);
> assertTrue(message.getJMSReplyTo().equals(dest));
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4485) QMF agent management object list corruption.
[ https://issues.apache.org/jira/browse/QPID-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-4485: -- Assignee: Ted Ross (was: Ken Giusti) > QMF agent management object list corruption. > > > Key: QPID-4485 > URL: https://issues.apache.org/jira/browse/QPID-4485 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework >Affects Versions: 0.19 >Reporter: Ken Giusti >Assignee: Ted Ross > Fix For: 0.21 > > > agentLock mutex is not held during message handling. This will lead to > corruption of the management object database maintained by the Agent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4485) QMF agent management object list corruption.
[ https://issues.apache.org/jira/browse/QPID-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511469#comment-13511469 ] Justin Ross commented on QPID-4485: --- Ted, please review. > QMF agent management object list corruption. > > > Key: QPID-4485 > URL: https://issues.apache.org/jira/browse/QPID-4485 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework >Affects Versions: 0.19 >Reporter: Ken Giusti >Assignee: Ted Ross > Fix For: 0.21 > > > agentLock mutex is not held during message handling. This will lead to > corruption of the management object database maintained by the Agent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4472) NPE when connecting over AMQP 1.0 with no SASL layer
[
https://issues.apache.org/jira/browse/QPID-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross resolved QPID-4472.
---
Resolution: Fixed
Assignee: Rob Godfrey
> NPE when connecting over AMQP 1.0 with no SASL layer
>
>
> Key: QPID-4472
> URL: https://issues.apache.org/jira/browse/QPID-4472
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.20
>Reporter: Gordon Sim
>Assignee: Rob Godfrey
> Fix For: 0.20, 0.21
>
>
> In doing some interop testing, I ran the c++ client (qpid::messaging) against
> the java broker without a SASL layer, triggering a NullPointerException and
> broker shutdown:
> {noformat}
> [Broker] BRK-1004 : Qpid Broker Ready
> java.lang.NullPointerException
> at
> org.apache.qpid.server.protocol.ProtocolEngine_1_0_0.received(ProtocolEngine_1_0_0.java:280)
> at
> org.apache.qpid.server.protocol.ProtocolEngine_1_0_0.received(ProtocolEngine_1_0_0.java:49)
> at
> org.apache.qpid.server.protocol.MultiVersionProtocolEngine$SelfDelegateProtocolEngine.received(MultiVersionProtocolEngine.java:556)
> at
> org.apache.qpid.server.protocol.MultiVersionProtocolEngine$SelfDelegateProtocolEngine.received(MultiVersionProtocolEngine.java:442)
> at
> org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
> at
> org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:37)
> at
> org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161)
> at java.lang.Thread.run(Thread.java:722)
>
> #
> # Unhandled Exception java.lang.NullPointerException in Thread IoReceiver -
> /127.0.0.1:59542
> #
> # Exiting
> #
>
> java.lang.NullPointerException
> at
> org.apache.qpid.server.protocol.ProtocolEngine_1_0_0.closed(ProtocolEngine_1_0_0.java:293)
> at
> org.apache.qpid.server.protocol.MultiVersionProtocolEngine.closed(MultiVersionProtocolEngine.java:102)
> at
> org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:222)
> at java.lang.Thread.run(Thread.java:722)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking
On Thu, 2012-12-06 at 11:54 +, Gordon Sim wrote: > On 12/05/2012 08:44 PM, Alan Conway wrote: > > There is a serious problem with this patch. My build (on RHEL5 at trunk > > r1417511) fails with lots of these: > > > > g++: /usr/lib64/libqpidcommon.so: No such file or directory > > g++: /usr/lib64/libqpidtypes.so: No such file or directory > > > > > > It looksl like using -lqpidcommon on the link line tries to link with > > the library installed in /usr/lib, and fails to build if Qpid is not > > installed. > > > > It is most important that qpid's own libraries be specified via an > > explicit path, and not discovered by the linker, to ensure that a build > > actually links with its own libraries. > > > > I'm not sure what the proper way to do this is with libtool (curse you > > libtool) but I don't think we can leave it this way. > > I couldn't reproduce the problem on RHEL 5.8, using latest trunk. > Whether or not there were qpid libraries installed it seemed to pick up > the correct ones from the build for me). > > That said, we should probably be linking against the .la with libtool? > That seems to have been the approach previously which didn't cause these > problems. > > Attached is a patch that would do this. Are you able to test it on the > system that caused problems to ensure it does actually fix the problem? > It works for me on Fedora 17 and RHEL 5.8, but as I say I couldn't > reproduce the problem in the first place. The patch works, I approve. Using full paths to the libs is much safer than letting the linker find them. I misspoke earlier - I actually saw this on RHEL 6.2. Cheers, Alan. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Memory leak in perl bindings?
On Thu, Dec 06, 2012 at 09:25:13AM +0100, Jimmy Jones wrote: > Would someone mind having a look at QPID-4493 - I seem to have a very > reproducible example (with drain.pl) of the perl bindings leaking memory > when calling getProperties or decodeMap, which is causing me a few > headaches for my long running processes! Unless I'm missing something? Sure, I'll look into it. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpuL9VMUQ95F.pgp Description: PGP signature
[jira] [Assigned] (QPID-4493) Memory leak in perl bindings?
[
https://issues.apache.org/jira/browse/QPID-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Pierce reassigned QPID-4493:
--
Assignee: Darryl L. Pierce
> Memory leak in perl bindings?
> -
>
> Key: QPID-4493
> URL: https://issues.apache.org/jira/browse/QPID-4493
> Project: Qpid
> Issue Type: Bug
>Affects Versions: 0.18, 0.20
> Environment: RHEL5, RHEL6
>Reporter: Jimmy Jones
>Assignee: Darryl L. Pierce
> Attachments: drain.pl, map_sender.pl
>
>
> I've been having problems with long running code using the perl bindings
> leaking memory, specifically after calls to getProperties and decodeMap.
> To reproduce - edit drain.pl to call {{$receiver->setCapacity(100)}} and then
> run {{drain.pl -f amq.match}}. You'll also need to hack map_sender.pl to send
> to amq.match and loop forever (both attached). The memory usage of drain.pl
> will now start growing...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking
On 12/05/2012 08:44 PM, Alan Conway wrote: There is a serious problem with this patch. My build (on RHEL5 at trunk r1417511) fails with lots of these: g++: /usr/lib64/libqpidcommon.so: No such file or directory g++: /usr/lib64/libqpidtypes.so: No such file or directory It looksl like using -lqpidcommon on the link line tries to link with the library installed in /usr/lib, and fails to build if Qpid is not installed. It is most important that qpid's own libraries be specified via an explicit path, and not discovered by the linker, to ensure that a build actually links with its own libraries. I'm not sure what the proper way to do this is with libtool (curse you libtool) but I don't think we can leave it this way. I couldn't reproduce the problem on RHEL 5.8, using latest trunk. Whether or not there were qpid libraries installed it seemed to pick up the correct ones from the build for me). That said, we should probably be linking against the .la with libtool? That seems to have been the approach previously which didn't cause these problems. Attached is a patch that would do this. Are you able to test it on the system that caused problems to ensure it does actually fix the problem? It works for me on Fedora 17 and RHEL 5.8, but as I say I couldn't reproduce the problem in the first place. Index: cpp/bindings/qmf2/examples/cpp/Makefile.am === --- cpp/bindings/qmf2/examples/cpp/Makefile.am (revision 1417786) +++ cpp/bindings/qmf2/examples/cpp/Makefile.am (working copy) @@ -21,16 +21,19 @@ AM_CPPFLAGS = $(INCLUDE) +TYPES_LIB=$(top_builddir)/src/libqpidtypes.la +MESSAGING_LIB=$(top_builddir)/src/libqpidmessaging.la + noinst_PROGRAMS=agent event_driven_list_agents list_agents print_events agent_SOURCES=agent.cpp -agent_LDADD=$(top_builddir)/src/libqmf2.la -lqpidtypes -lqpidmessaging +agent_LDADD=$(top_builddir)/src/libqmf2.la $(TYPES_LIB) $(MESSAGING_LIB) list_agents_SOURCES=list_agents.cpp -list_agents_LDADD=$(top_builddir)/src/libqmf2.la -lqpidmessaging +list_agents_LDADD=$(top_builddir)/src/libqmf2.la $(MESSAGING_LIB) event_driven_list_agents_SOURCES=event_driven_list_agents.cpp -event_driven_list_agents_LDADD=$(top_builddir)/src/libqmf2.la -lqpidmessaging +event_driven_list_agents_LDADD=$(top_builddir)/src/libqmf2.la $(MESSAGING_LIB) print_events_SOURCES=print_events.cpp -print_events_LDADD=$(top_builddir)/src/libqmf2.la -lqpidtypes -lqpidmessaging +print_events_LDADD=$(top_builddir)/src/libqmf2.la $(TYPES_LIB) $(MESSAGING_LIB) Index: cpp/examples/makedist.mk === --- cpp/examples/makedist.mk (revision 1417786) +++ cpp/examples/makedist.mk (working copy) @@ -20,6 +20,7 @@ AM_CXXFLAGS = $(WARNING_CFLAGS) INCLUDES = -I$(top_srcdir)/include -I$(top_builddir)/include CLIENT_LIB=$(top_builddir)/src/libqpidclient.la +COMMON_LIB=$(top_builddir)/src/libqpidcommon.la CONSOLE_LIB=$(top_builddir)/src/libqmfconsole.la CLIENTFLAGS=-lqpidclient CONSOLEFLAGS=-lqmfconsole Index: cpp/examples/messaging/Makefile.am === --- cpp/examples/messaging/Makefile.am (revision 1417786) +++ cpp/examples/messaging/Makefile.am (working copy) @@ -22,6 +22,7 @@ AM_CXXFLAGS = $(WARNING_CFLAGS) INCLUDES = -I$(top_srcdir)/include -I$(top_builddir)/include CLIENT_LIB=$(top_builddir)/src/libqpidmessaging.la +TYPES_LIB=$(top_builddir)/src/libqpidtypes.la CLIENTFLAGS=-lqpidmessaging noinst_PROGRAMS=drain spout client server map_sender map_receiver hello_world hello_xml @@ -33,10 +34,10 @@ hello_xml_LDADD=$(CLIENT_LIB) drain_SOURCES=drain.cpp OptionParser.h OptionParser.cpp -drain_LDADD=$(CLIENT_LIB) -lqpidtypes +drain_LDADD=$(CLIENT_LIB) $(TYPES_LIB) spout_SOURCES=spout.cpp OptionParser.h OptionParser.cpp -spout_LDADD=$(CLIENT_LIB) -lqpidtypes +spout_LDADD=$(CLIENT_LIB) $(TYPES_LIB) client_SOURCES=client.cpp client_LDADD=$(CLIENT_LIB) @@ -45,10 +46,10 @@ server_LDADD=$(CLIENT_LIB) map_sender_SOURCES=map_sender.cpp -map_sender_LDADD=$(CLIENT_LIB) -lqpidtypes +map_sender_LDADD=$(CLIENT_LIB) $(TYPES_LIB) map_receiver_SOURCES=map_receiver.cpp -map_receiver_LDADD=$(CLIENT_LIB) -lqpidtypes +map_receiver_LDADD=$(CLIENT_LIB) $(TYPES_LIB) examples_DATA= \ hello_world.cpp \ Index: cpp/examples/old_api/direct/Makefile.am === --- cpp/examples/old_api/direct/Makefile.am (revision 1417786) +++ cpp/examples/old_api/direct/Makefile.am (working copy) @@ -23,13 +23,13 @@ noinst_PROGRAMS=direct_producer listener declare_queues direct_producer_SOURCES=direct_producer.cpp -direct_producer_LDADD=$(CLIENT_LIB) -lqpidcommon +direct_producer_LDADD=$(CLIENT_LIB) $(COMMON_LIB) listener_SOURCES=listener.cpp -listener_LDADD=$(CLIENT_LIB) -lqpidcommon +listener_LDADD=$(CLIENT_LIB) $(COMMON_LIB) declare_queues_SOURCES=de
Memory leak in perl bindings?
Hi, Would someone mind having a look at QPID-4493 - I seem to have a very reproducible example (with drain.pl) of the perl bindings leaking memory when calling getProperties or decodeMap, which is causing me a few headaches for my long running processes! Unless I'm missing something? Many thanks, Jimmy - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4493) Memory leak in perl bindings?
[
https://issues.apache.org/jira/browse/QPID-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Jones updated QPID-4493:
--
Attachment: map_sender.pl
drain.pl
> Memory leak in perl bindings?
> -
>
> Key: QPID-4493
> URL: https://issues.apache.org/jira/browse/QPID-4493
> Project: Qpid
> Issue Type: Bug
>Affects Versions: 0.18, 0.20
> Environment: RHEL5, RHEL6
>Reporter: Jimmy Jones
> Attachments: drain.pl, map_sender.pl
>
>
> I've been having problems with long running code using the perl bindings
> leaking memory, specifically after calls to getProperties and decodeMap.
> To reproduce - edit drain.pl to call {{$receiver->setCapacity(100)}} and then
> run {{drain.pl -f amq.match}}. You'll also need to hack map_sender.pl to send
> to amq.match and loop forever (both attached). The memory usage of drain.pl
> will now start growing...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4493) Memory leak in perl bindings?
Jimmy Jones created QPID-4493:
-
Summary: Memory leak in perl bindings?
Key: QPID-4493
URL: https://issues.apache.org/jira/browse/QPID-4493
Project: Qpid
Issue Type: Bug
Affects Versions: 0.18, 0.20
Environment: RHEL5, RHEL6
Reporter: Jimmy Jones
Attachments: drain.pl, map_sender.pl
I've been having problems with long running code using the perl bindings
leaking memory, specifically after calls to getProperties and decodeMap.
To reproduce - edit drain.pl to call {{$receiver->setCapacity(100)}} and then
run {{drain.pl -f amq.match}}. You'll also need to hack map_sender.pl to send
to amq.match and loop forever (both attached). The memory usage of drain.pl
will now start growing...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
