RE: 0.6 Release Plans from now onwards
> Cliff can you comment on these bugs? Are they truly as important as > blocker/critical? If so unless there are patches attached to the jiras > very soon I think we'll have to omit the specific WCF source code from > this release [...] Agreed. These were marked as such because they would make a significant difference to early adopters and were thought to be doable *without* holding up the release. Right now, I feel comfortable about resolving QPID-2247 (and even QPID-2128) by tomorrow and QPID-2260 certainly by Thursday. The latter is very easy conceptually and boils down to testing in the various scenarios. Cliff -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Tuesday, December 15, 2009 2:27 PM To: Qpid Dev List Subject: 0.6 Release Plans from now onwards As I said in my beta release message I'd like to produce a release candidate at the end of this week. On the closing bugs front there are a couple of issues still (but nothing that looks deadly as far as I can tell): Essentially we have 2 blockers and 2 critical bugs. 2 Java bugs and 2 bugs for the WCF code. QPID-2273 (http://issues.apache.org/jira/browse/QPID-2273), QPID-1830 (http://issues.apache.org/jira/browse/QPID-1830) - Aidan can you give some status on these bugs? Are they going to be finished in the next couple of days? Is there much risk in the fixes? QPID-2260 (http://issues.apache.org/jira/browse/QPID-2260), QPID-2247 (http://issues.apache.org/jira/browse/QPID-2247) - These are more problematic as they don't have anyone assigned to them. It could be that Cliff is working on them, but as he isn't a commiter he can't be assigned the bugs in Jira. Cliff can you comment on these bugs? Are they truly as important as blocker/critical? If so unless there are patches attached to the jiras very soon I think we'll have to omit the specific WCF source code from this release (of course it will still be in the big source tarball). To be honest I'm really sure it's quite mature enough in any case. Assuming that we can clear these issues up (one way or another) in the next couple of days - I plan to release rc1 on Thursday/Friday this week. I will create a (preemptive) subversion tag at that point. From that point I'd like to *freeze* checkins to the tree for 2 weeks taking us effectively to the new year. If we haven't actually voted to release by then I suggest we move the branch tag to whatever the most recent qpid checkin is and do all subsequent release work on a branch, and unfreeze the trunk. This way we should have the minimum frozen time and still be able to progress. Regards Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.6 Release Plans from now onwards
On Tue, Dec 15, 2009 at 10:08 PM, Aidan Skinner wrote: > On Tue, Dec 15, 2009 at 11:46 PM, Robbie Gemmell > wrote: > >> I came up against that a couple months ago. The reason seemed to be that the >> ConversationFactory is calling toString() on a message before its sent, and >> the toString() behaviour was changed from previously outputting the hash >> code to outputting actual content. (r756228 seems to be where you'd want to >> look). The Functions.str() method does not advance the position pointer so calling toString() should not affect the content. I will investigate this tomorrow morning and comment further once I figure out the problem. > Ah, good spot. Reverting that patch fixes it for me. I'm going to > assign the bug to Rajith since just backing it out doesn't seem > entirely the right thing. > - AIdan (patch review doesn't catch everything) > -- > Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org > "A witty saying proves nothing" - Voltaire > > - > 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/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1830) BytesMessage is unreadable
[ https://issues.apache.org/jira/browse/QPID-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aidan Skinner reassigned QPID-1830: --- Assignee: Rajith Attapattu (was: Aidan Skinner) This was caused by r756228, could you fix please? Thanks, - Aidan > BytesMessage is unreadable > -- > > Key: QPID-1830 > URL: https://issues.apache.org/jira/browse/QPID-1830 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6, 0.7 >Reporter: Aidan Skinner >Assignee: Rajith Attapattu >Priority: Critical > Fix For: 0.6 > > > This can easily be seen running the interop coordinator: > 2009-04-28 14:24:38,377 INFO [main] distributedtesting.Coordinator > (Coordinator.java:285) - Found distributed test case: > org.apache.qpid.interop.testcases.InteropTestCase4P2PMessageSize > javax.jms.MessageNotReadableException: You need to call reset() to make the > message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > 2009-04-28 14:24:39,690 INFO [main] distributedtesting.Coordinator > (Coordinator.java:330) - javax.jms.MessageNotReadableException: You need to > call reset() to make the message readable > java.lang.RuntimeException: javax.jms.MessageNotReadableException: You need > to call reset() to make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:407) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > Caused by: javax.jms.MessageNotReadableException: You need to call reset() to > make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > ... 5 more > This works on the 0.5-release branch, so is presumably a recentish break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.6 Release Plans from now onwards
On Tue, Dec 15, 2009 at 11:46 PM, Robbie Gemmell wrote: > I came up against that a couple months ago. The reason seemed to be that the > ConversationFactory is calling toString() on a message before its sent, and > the toString() behaviour was changed from previously outputting the hash > code to outputting actual content. (r756228 seems to be where you'd want to > look). Ah, good spot. Reverting that patch fixes it for me. I'm going to assign the bug to Rajith since just backing it out doesn't seem entirely the right thing. - AIdan (patch review doesn't catch everything) -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.6 Release Plans from now onwards
On Tue, Dec 15, 2009 at 11:31 PM, Aidan Skinner wrote: First sign of madness this, but never mind eh? > On Tue, Dec 15, 2009 at 10:26 PM, Andrew Stitcher > wrote: > >> QPID-2273 (http://issues.apache.org/jira/browse/QPID-2273), QPID-1830 >> (http://issues.apache.org/jira/browse/QPID-1830) - Aidan can you give >> some status on these bugs? Are they going to be finished in the next >> couple of days? Is there much risk in the fixes? > > I'm currently working on QPID-2273, it's confined to the protocol > initiation so should be low risk. I'll have a fix for that soon. Patch attached to the Jira. I'd like another set of eyes on this, it works as far as my testing goes but I'm not 100% convinced it gets all the cases. Otherwise I'll commit it Thursday since it's definitely better than what we have. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2273) Java client can't negotiate to 0-9
[ https://issues.apache.org/jira/browse/QPID-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aidan Skinner updated QPID-2273: Attachment: (was: 0001-QPID-2273-set-the-protocol-version-on-the-connectio.patch) > Java client can't negotiate to 0-9 > -- > > Key: QPID-2273 > URL: https://issues.apache.org/jira/browse/QPID-2273 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6 >Reporter: Aidan Skinner >Assignee: Aidan Skinner >Priority: Blocker > Fix For: 0.6 > > Attachments: 0001-QPID-2273-make-protocol-negotiation-saner.patch > > > For instance, if you try connecting a trunk client to a 0.5 broker it fails. > This is due to the delegate using the wrong ProtocolVersion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2273) Java client can't negotiate to 0-9
[ https://issues.apache.org/jira/browse/QPID-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aidan Skinner updated QPID-2273: Attachment: 0001-QPID-2273-make-protocol-negotiation-saner.patch This patch fixes the problem for me. > Java client can't negotiate to 0-9 > -- > > Key: QPID-2273 > URL: https://issues.apache.org/jira/browse/QPID-2273 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6 >Reporter: Aidan Skinner >Assignee: Aidan Skinner >Priority: Blocker > Fix For: 0.6 > > Attachments: 0001-QPID-2273-make-protocol-negotiation-saner.patch > > > For instance, if you try connecting a trunk client to a 0.5 broker it fails. > This is due to the delegate using the wrong ProtocolVersion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2273) Java client can't negotiate to 0-9
[ https://issues.apache.org/jira/browse/QPID-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aidan Skinner updated QPID-2273: Attachment: (was: 0001-QPID-2273-make-protocol-negotiation-saner.-This-cau.patch) > Java client can't negotiate to 0-9 > -- > > Key: QPID-2273 > URL: https://issues.apache.org/jira/browse/QPID-2273 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6 >Reporter: Aidan Skinner >Assignee: Aidan Skinner >Priority: Blocker > Fix For: 0.6 > > Attachments: 0001-QPID-2273-make-protocol-negotiation-saner.patch > > > For instance, if you try connecting a trunk client to a 0.5 broker it fails. > This is due to the delegate using the wrong ProtocolVersion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.6 Release Plans from now onwards
> QPID-2260 (http://issues.apache.org/jira/browse/QPID-2260), QPID-2247 > (http://issues.apache.org/jira/browse/QPID-2247) - These are > more problematic as they don't have anyone assigned to them. > It could be that Cliff is working on them, but as he isn't a > commiter he can't be assigned the bugs in Jira. I assigned them to me. I'll most likely be handling any patches that result. I also assigned myself to QPID-2128 (https://issues.apache.org/jira/browse/QPID-2128) and elevated it to Critical. That code has been under review in the jira and resulting patches are forthcoming I believe. -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.6 Release Plans from now onwards
I came up against that a couple months ago. The reason seemed to be that the ConversationFactory is calling toString() on a message before its sent, and the toString() behaviour was changed from previously outputting the hash code to outputting actual content. (r756228 seems to be where you'd want to look). Robbie > -Original Message- > From: Aidan Skinner > QPID-1830 is more problematic, I don't really have a good handle on > what the issue there is yet. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.6 Release Plans from now onwards
It is actually possible to assign JIRA's to non-committers, I believe you just need to add the relevant JIRA account to the Contributors role for the project so that they show up as a possible assignee. Robbie > -Original Message- > From: Andrew Stitcher > QPID-2260 (http://issues.apache.org/jira/browse/QPID-2260), QPID-2247 > (http://issues.apache.org/jira/browse/QPID-2247) - These are more > problematic as they don't have anyone assigned to them. It could be > that > Cliff is working on them, but as he isn't a commiter he can't be > assigned the bugs in Jira. > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.6 Release Plans from now onwards
On Tue, Dec 15, 2009 at 10:26 PM, Andrew Stitcher wrote: > QPID-2273 (http://issues.apache.org/jira/browse/QPID-2273), QPID-1830 > (http://issues.apache.org/jira/browse/QPID-1830) - Aidan can you give > some status on these bugs? Are they going to be finished in the next > couple of days? Is there much risk in the fixes? I'm currently working on QPID-2273, it's confined to the protocol initiation so should be low risk. I'll have a fix for that soon. QPID-1830 is more problematic, I don't really have a good handle on what the issue there is yet. I don't *think* it'll be particularly invasive but it's hard to say. It seems to have been caused post-0.5, if anybody would like to claim responsibility for touching BytesMessage in the last few months and have a look that'd be great. ;) - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2224) Repeated random failures for MINANetworkDriverTest
[ https://issues.apache.org/jira/browse/QPID-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791021#action_12791021 ] Rajith Attapattu commented on QPID-2224: Ok here is another failure. Again this appears to be a random failure. Testcase: testBindOpen took 0.24 sec Testcase: testBindOpenCloseOpen took 0.026 sec Testcase: testBindPortInUse took 0.005 sec Testcase: testSend took 0.025 sec Testcase: testSetReadIdle took 1.516 sec Testcase: testSetWriteIdle took 1.51 sec Testcase: testClosed took 2.017 sec FAILED Client should have been closed junit.framework.AssertionFailedError: Client should have been closed at org.apache.qpid.transport.network.mina.MINANetworkDriverTest.testClosed(MINANetworkDriverTest.java:265) Testcase: testExceptionCaught took 0.009 sec Testcase: testGetRemoteAddress took 0.013 sec > Repeated random failures for MINANetworkDriverTest > -- > > Key: QPID-2224 > URL: https://issues.apache.org/jira/browse/QPID-2224 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Rajith Attapattu >Assignee: Aidan Skinner >Priority: Minor > Fix For: 0.7 > > > The MINANetworkDriverTest has repeated random test failures for last month > and half or so. > IIRC there two tests that behaved this way. > I will capture the logs for each different failure and add as and when they > occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2225) FailoverBeforeConsumingRecoverTest failure with Java Broker
[ https://issues.apache.org/jira/browse/QPID-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu reassigned QPID-2225: -- Assignee: Martin Ritchie > FailoverBeforeConsumingRecoverTest failure with Java Broker > --- > > Key: QPID-2225 > URL: https://issues.apache.org/jira/browse/QPID-2225 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Rajith Attapattu >Assignee: Martin Ritchie > Fix For: 0.7 > > Attachments: test-logs.tar.gz > > > The "FailoverBeforeConsumingRecoverTest" is failing when run against the in > vm broker. > logs attached. > Testcase: testRecoverResendsMsgs took 0.27 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgs(RecoverTest.java:125) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testRecoverResendsMsgsAckOnEarlier took 0.176 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgsAckOnEarlier(RecoverTest.java:142) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testAcknowledgePerConsumer took 0.194 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testAcknowledgePerConsumer(RecoverTest.java:198) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testRecoverInAutoAckListener took 31.154 sec >FAILED > null > junit.framework.AssertionFailedError >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverInAutoAckListener(RecoverTest.java:292) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > -- > Testsuite: org.apache.qpid.test.unit.ack.RecoverTest > Tests run: 4, Failures: 1, Errors: 3, Time elapsed: 31.652 sec > Testcase: testRecoverResendsMsgs took 0.161 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgs(RecoverTest.java:125) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testRecoverResendsMsgsAckOnEarlier took 0.161 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgsAckOnEarlier(RecoverTest.java:142) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testAcknowledgePerConsumer took 0.161 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testAcknowledgePerConsumer(RecoverTest.java:198) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.ja
[jira] Updated: (QPID-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston updated QPID-2128: --- Priority: Critical (was: Major) Fix Version/s: 0.6 This support is needed for 0.6. Patches for bugs identified in the code review are forthcoming. > Transaction support for the WCF channel > --- > > Key: QPID-2128 > URL: https://issues.apache.org/jira/browse/QPID-2128 > Project: Qpid > Issue Type: New Feature > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Steve Huston >Priority: Critical > Fix For: 0.6 > > Attachments: cppbld.patch, qpid2128_1.patch, wcfbld.patch > > > Transaction support is currently lacking from the WCF channel. > As an initial implementation, full distributed transaction support from > within .NET is proposed using the dtx AMQP classes and creating a plugin to > the MSDTC infrastructure to drive recovery. > Added performance from promotable transaction enlistment is deferred to a > later date. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2260) Build of Release configuration fails
[ https://issues.apache.org/jira/browse/QPID-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston reassigned QPID-2260: -- Assignee: Steve Huston > Build of Release configuration fails > > > Key: QPID-2260 > URL: https://issues.apache.org/jira/browse/QPID-2260 > Project: Qpid > Issue Type: Bug > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Steve Huston >Priority: Blocker > Fix For: 0.6 > > Original Estimate: 48h > Remaining Estimate: 48h > > Locations for the Release intermediaries are not properly resolved. > This is known issue #1 in the ReadMe.txt file and prevents non-debug versions > of the code from building without user intervention. > This should be easy to fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston reassigned QPID-2128: -- Assignee: Steve Huston > Transaction support for the WCF channel > --- > > Key: QPID-2128 > URL: https://issues.apache.org/jira/browse/QPID-2128 > Project: Qpid > Issue Type: New Feature > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Steve Huston > Attachments: cppbld.patch, qpid2128_1.patch, wcfbld.patch > > > Transaction support is currently lacking from the WCF channel. > As an initial implementation, full distributed transaction support from > within .NET is proposed using the dtx AMQP classes and creating a plugin to > the MSDTC infrastructure to drive recovery. > Added performance from promotable transaction enlistment is deferred to a > later date. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2281) Windows C++ broker does not detect and disallow multiple brokers using the same data directory
[ https://issues.apache.org/jira/browse/QPID-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-2281. --- Resolution: Fixed > Windows C++ broker does not detect and disallow multiple brokers using the > same data directory > -- > > Key: QPID-2281 > URL: https://issues.apache.org/jira/browse/QPID-2281 > Project: Qpid > Issue Type: Bug > Components: C++ Broker > Environment: Windows >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.6 > > > The LockFile implementation on Windows doesn't actually lock the the lock > file, it merely opens it. This means that the only use of this class in the > Windows broker which is to ensure that multiple brokers don't share the same > data directory is nullified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2281) Windows C++ broker does not detect and disallow multiple brokers using the same data directory
Windows C++ broker does not detect and disallow multiple brokers using the same data directory -- Key: QPID-2281 URL: https://issues.apache.org/jira/browse/QPID-2281 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Windows Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.6 The LockFile implementation on Windows doesn't actually lock the the lock file, it merely opens it. This means that the only use of this class in the Windows broker which is to ensure that multiple brokers don't share the same data directory is nullified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2280) C++ broker: Python messaging.SenderTests.testCapacityTimeout fails
C++ broker: Python messaging.SenderTests.testCapacityTimeout fails -- Key: QPID-2280 URL: https://issues.apache.org/jira/browse/QPID-2280 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Environment: Windows Reporter: Steve Huston This test started failing today, and Python tests ran successfully Sunday night, so this broke sometime between Sunday night and now. It fails with: qpid.tests.messaging.SenderTests.testCapacityTimeout fail Error during test: Traceback (most recent call last): File "C:\qpid\trunk\qpid\cpp\src\tests\..\..\..\python/qpid-python-test", line 307, in run phase() File "C:\qpid\trunk\qpid\python\qpid\tests\messaging.py", line 791, in test CapacityTimeout assert caught, "did not exceed capacity" AssertionError: did not exceed capacity Anyone who's made changes that may possibly be related to this, please comment on this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
0.6 Release Plans from now onwards
As I said in my beta release message I'd like to produce a release candidate at the end of this week. On the closing bugs front there are a couple of issues still (but nothing that looks deadly as far as I can tell): Essentially we have 2 blockers and 2 critical bugs. 2 Java bugs and 2 bugs for the WCF code. QPID-2273 (http://issues.apache.org/jira/browse/QPID-2273), QPID-1830 (http://issues.apache.org/jira/browse/QPID-1830) - Aidan can you give some status on these bugs? Are they going to be finished in the next couple of days? Is there much risk in the fixes? QPID-2260 (http://issues.apache.org/jira/browse/QPID-2260), QPID-2247 (http://issues.apache.org/jira/browse/QPID-2247) - These are more problematic as they don't have anyone assigned to them. It could be that Cliff is working on them, but as he isn't a commiter he can't be assigned the bugs in Jira. Cliff can you comment on these bugs? Are they truly as important as blocker/critical? If so unless there are patches attached to the jiras very soon I think we'll have to omit the specific WCF source code from this release (of course it will still be in the big source tarball). To be honest I'm really sure it's quite mature enough in any case. Assuming that we can clear these issues up (one way or another) in the next couple of days - I plan to release rc1 on Thursday/Friday this week. I will create a (preemptive) subversion tag at that point. From that point I'd like to *freeze* checkins to the tree for 2 weeks taking us effectively to the new year. If we haven't actually voted to release by then I suggest we move the branch tag to whatever the most recent qpid checkin is and do all subsequent release work on a branch, and unfreeze the trunk. This way we should have the minimum frozen time and still be able to progress. Regards Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2279) Removal of trivial unused stuff
Removal of trivial unused stuff --- Key: QPID-2279 URL: https://issues.apache.org/jira/browse/QPID-2279 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Trivial Fix For: 0.6 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2267) release artifact for WCF channel
[ https://issues.apache.org/jira/browse/QPID-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-2267: -- Priority: Major (was: Blocker) Fix Version/s: (was: 0.6) 0.7 > release artifact for WCF channel > > > Key: QPID-2267 > URL: https://issues.apache.org/jira/browse/QPID-2267 > Project: Qpid > Issue Type: Improvement > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Release artifacts build environment >Reporter: Cliff Jansen >Assignee: Andrew Stitcher > Fix For: 0.7 > > Attachments: rel.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > The steps to create a release artifact for the WCF channel need to be made > explicit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2267) release artifact for WCF channel
[ https://issues.apache.org/jira/browse/QPID-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790961#action_12790961 ] Andrew Stitcher commented on QPID-2267: --- However I can't see that this can be considered as any kind of real release artifact as it isn't self contained and I'm not even sure that it is buildable by itself. > release artifact for WCF channel > > > Key: QPID-2267 > URL: https://issues.apache.org/jira/browse/QPID-2267 > Project: Qpid > Issue Type: Improvement > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Release artifacts build environment >Reporter: Cliff Jansen >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.6 > > Attachments: rel.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > The steps to create a release artifact for the WCF channel need to be made > explicit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2267) release artifact for WCF channel
[ https://issues.apache.org/jira/browse/QPID-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790960#action_12790960 ] Andrew Stitcher commented on QPID-2267: --- I've applied this patch so the release script now creates a .zip file with relevant source code. > release artifact for WCF channel > > > Key: QPID-2267 > URL: https://issues.apache.org/jira/browse/QPID-2267 > Project: Qpid > Issue Type: Improvement > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Release artifacts build environment >Reporter: Cliff Jansen >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.6 > > Attachments: rel.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > The steps to create a release artifact for the WCF channel need to be made > explicit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2277) Reinstate release artifacts for native .NET client
[ https://issues.apache.org/jira/browse/QPID-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-2277. --- Resolution: Fixed > Reinstate release artifacts for native .NET client > -- > > Key: QPID-2277 > URL: https://issues.apache.org/jira/browse/QPID-2277 > Project: Qpid > Issue Type: Improvement >Affects Versions: 0.6 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.6 > > > Earlier in the 0.6 release process the .NET client was removed as it didn't > build and seemed unmaintained. This should be fixed now and a large number of > fixes have gone into the code so it should be reinstated as a release > artifact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2278) Store recovery compatibility problem introduced by alternate-exchange fix
[ https://issues.apache.org/jira/browse/QPID-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPID-2278. Resolution: Fixed Changing the order of the encoded items such that the alternate exchange is encoded last (after the args FieldTable) means that on decode, the broker can check for remaining bytes and decode the alternate-exchange name only if the string is present. Fixed in r.890965 > Store recovery compatibility problem introduced by alternate-exchange fix > - > > Key: QPID-2278 > URL: https://issues.apache.org/jira/browse/QPID-2278 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > A recent checkin (r.831082) fixed a problem in which the exchange did not > persist the alternate-exchange setting, and on recovery this was being lost. > To fix it, an additional string was added to the Exchange::encode() and > Exchange::decode() methods. However, this fix means that there is a binary > incompatibility between pre- and post-fix exchange data. Attempting to > recover stores from pre-fix brokers result in broker shutdown if recovery is > attempted using post-fix brokers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2278) Store recovery compatibility problem introduced by alternate-exchange fix
Store recovery compatibility problem introduced by alternate-exchange fix - Key: QPID-2278 URL: https://issues.apache.org/jira/browse/QPID-2278 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Kim van der Riet Assignee: Kim van der Riet A recent checkin (r.831082) fixed a problem in which the exchange did not persist the alternate-exchange setting, and on recovery this was being lost. To fix it, an additional string was added to the Exchange::encode() and Exchange::decode() methods. However, this fix means that there is a binary incompatibility between pre- and post-fix exchange data. Attempting to recover stores from pre-fix brokers result in broker shutdown if recovery is attempted using post-fix brokers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790919#action_12790919 ] Cliff Jansen commented on QPID-2128: Thank you very much for the detailed review. > Some comments/questions > Dtcplugin.cpp > 188: should host be checked for empty string? I don't think so. It is only used internally and it would take contorted programming to pass the reference parameter as a null value. > 172: "i < len" should be "i < len-1" since the next line is referencing > dsn[i+1] That's a bug, will fix. > 324: the qpid SQL storage provider does not log indoubt transactions, > so the recover will always get an empty list. If the qpid broker > crashes after prepare, the transaction is rolled back by SQL. This may > cause data inconsistency because other RMs may commit that transaction > already. Need to work with Stephen to figure out if this is an issue > in the storage provider implementation. Wow. Triple points for finding that merely from the Windows provider code. Will fix asap, thanks. > 454: if the new operator throws due to low memory condition and the > exception is handled in some other place, there could be deadlock > because the critical section is not released. Bug, will fix. > 454 - 464: if you call open first and add the new resource manager to > the map when it succeeds, there is no need to erase. Using an auto > pointer here can make it easy to release the object on failures. Good point, will rework. > 461: what exception can be thrown by delete? The destructor of > ResourceManager is empty. The destructors of Qpid::Client::Session and Connection are recursively called. > 490: if close fails, is xa_close going to retried? I see your point. The XA spec is silent on this and DTC documentation only refers to XA. Guarding against the possibility will be required. > Overall the implementation in this file does not follow the qpid style > very well. I would wrap the global variables and functions (line 91 to > 190) into a DtcPlugin class to avoid global variables and functions as > much as possible. > At least for me, the use of the critical section rmLock is not easy to > follow. Ideally thread synchronization should be encapsulated into > classes (i.e. making the class thread-safe). The ResourceManager class > can hold one critical section to synchronize communication with the > qpid broker. The DtcPlugin class can use one critical section to > synchronize access to all resource manager instances. The DtcPlugin > class can implement the XA interface and the xa_switch entry methods > (xa_open, xa_close, etc) can just call the DtcPlugin methods. Qpid > implements a scoped lock/unlock (qpid.sys.ScopedLock) but I am not > sure if you want to use it in the DTC plugin. In the trade off of addressing people familiar with COM and MSDTC versus people familiar with Qpid, I think the former makes the most sense for code maintainability. The Qpid use is practically trivial (if obscure), whereas the interaction with DTC is non-obvious and needs to be bullet proof. I would think there to be mainly scrutiny of the COM calling and callback interfaces, so sticking with a style that matches the related documentation and standard examples is probably preferable. Using the two tiered lock structure as you describe is a useful enhancement if the DTC does parallel recovery to RM instances. > AmqpConnection.cpp > 110 - 118: this can be refactored into DtxResourceManager. The > connection should not care what needs to be done for pending > transactions on connection closing. It should notify the resource > manager that the connection is closing, like what it does for > sessions. Agreed. This is left over cruft from another fix, and effectively a no-op. Will remove. > XaTransaction.cpp > 66: use InterlockedIncrement/InterlockedDecrement so you don't need > this lock OK. > 204: You can set the ref count to 1 in the constructor so you don't > have to call AddRef() after creating each object. I think that messes with traditional coding style, at least of the sample code I've seen. I think it is easier for Qpid contributors to maintain this if the constructor is "normal" and the AddRef is an additional (commented) step. > AmqpSession.cpp > 109: why not make this a method of XaTransaction? This is a convenience casting routine, just needed by AmqpSession. I try to hide native C++ Qpid definitions from the managed .NET interfaces. > 322: remove OK. > In ConnectionClosed and NotifyClosed, why is it important to flush > phase 0 (sending dtxEnd)? The broker is going to rollback all pending > transactions of a session when it is closed. If a dtx involves > multiple sessions, what is the behavior of closing one session before > commit? Unfortunately, there is no way to know when a broker will execute a dtxEnd other than waiting for the command status completion. The d
[jira] Created: (QPID-2277) Reinstate release artifacts for native .NET client
Reinstate release artifacts for native .NET client -- Key: QPID-2277 URL: https://issues.apache.org/jira/browse/QPID-2277 Project: Qpid Issue Type: Improvement Affects Versions: 0.6 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.6 Earlier in the 0.6 release process the .NET client was removed as it didn't build and seemed unmaintained. This should be fixed now and a large number of fixes have gone into the code so it should be reinstated as a release artifact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2243) 0-10 protocol connections do not have a matching JMX MBean to allow management
[ https://issues.apache.org/jira/browse/QPID-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2243: - Fix Version/s: (was: 0.6) 0.7 > 0-10 protocol connections do not have a matching JMX MBean to allow management > -- > > Key: QPID-2243 > URL: https://issues.apache.org/jira/browse/QPID-2243 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Priority: Critical > Fix For: 0.7 > > > 0-10 protocol connections do not have a matching JMX MBean to allow management -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1951) Need wrappers for Posix types declared in Windows portability layer
[ https://issues.apache.org/jira/browse/QPID-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-1951. --- Resolution: Fixed Fix Version/s: 0.6 Resolved by a little refactoring! > Need wrappers for Posix types declared in Windows portability layer > --- > > Key: QPID-1951 > URL: https://issues.apache.org/jira/browse/QPID-1951 > Project: Qpid > Issue Type: Bug > Components: C++ Client > Environment: Windows C++ >Reporter: Pete MacKinnon >Assignee: Andrew Stitcher > Fix For: 0.6 > > > Currently, these are declared in qpid/sys/windows/IntegerTypes.h > typedef int pid_t; > typedef int ssize_t; > However, these declarations can conflict with other client software C++ > headers that have their own Windows declarations of these types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2244) AMQQueueMBean.viewMessages does not show 0-10 protocol MessageTransferMessage's
[ https://issues.apache.org/jira/browse/QPID-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790873#action_12790873 ] Rob Godfrey commented on QPID-2244: --- Robbie: yeah - I think that would be sensible... the stuff that is held in "propertyFlags" should probably be displayed as the individual component properties however. Definitely not a blocker though :-) > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's > > > Key: QPID-2244 > URL: https://issues.apache.org/jira/browse/QPID-2244 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Blocker > Fix For: 0.6 > > > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's, it can only show messages based on the AMQMessage > class used by lower ptorocol versions. As such a user will not see messages > on the queue if they are produced with a 0-10 client but will for a 0-8/0-9 > client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2276) Make documentation tags wrap so pydoc can be read on 80-cols terminal
[ https://issues.apache.org/jira/browse/QPID-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned QPID-2276: - Assignee: Ted Ross (was: Rafael H. Schloming) Reassigning for Ted to look at as he owns that particular file. > Make documentation tags wrap so pydoc can be read on 80-cols terminal > - > > Key: QPID-2276 > URL: https://issues.apache.org/jira/browse/QPID-2276 > Project: Qpid > Issue Type: Improvement > Components: Python Client >Affects Versions: 0.6 > Environment: Patch against current SVN checkout (890721) >Reporter: Jan Sarenik >Assignee: Ted Ross > Fix For: 0.6 > > Attachments: console-doc.diff > > > This patch wraps the documentation tags in console.py > More to come. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2202) CMake doesn't check for presence of boost-system
[ https://issues.apache.org/jira/browse/QPID-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston resolved QPID-2202. Resolution: Fixed Fix Version/s: 0.6 Assignee: Steve Huston Fix for broken Windows config; fixed on trunk r890900. > CMake doesn't check for presence of boost-system > > > Key: QPID-2202 > URL: https://issues.apache.org/jira/browse/QPID-2202 > Project: Qpid > Issue Type: Bug > Components: Build Tools > Environment: Windows XP, CMake 2.6 patch 4, Boost 1.37 from BoostPro, > qpid trunk r834975 >Reporter: Jeff Laughlin >Assignee: Steve Huston > Fix For: 0.6 > > > CMake doesn't check for presence of boost-system library. It successfully > configures and generates, but building in VC9 fails on linking when it cannot > find the library. Installing the library and re-linking works around the > issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2228) C++ "make dist " builds the entire broker just to print out qpidd --help
[ https://issues.apache.org/jira/browse/QPID-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-2228: -- Fix Version/s: (was: 0.6) > C++ "make dist " builds the entire broker just to print out qpidd --help > > > Key: QPID-2228 > URL: https://issues.apache.org/jira/browse/QPID-2228 > Project: Qpid > Issue Type: Improvement > Components: Build Tools >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > It uses the output in the documentation for the man page. But it makes a > potentially very fast operation much slower. > It would be simple to create a trivial single file executable whose only > purpose is to print out the --help info. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2267) release artifact for WCF channel
[ https://issues.apache.org/jira/browse/QPID-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-2267: - Assignee: Andrew Stitcher > release artifact for WCF channel > > > Key: QPID-2267 > URL: https://issues.apache.org/jira/browse/QPID-2267 > Project: Qpid > Issue Type: Improvement > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Release artifacts build environment >Reporter: Cliff Jansen >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.6 > > Attachments: rel.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > The steps to create a release artifact for the WCF channel need to be made > explicit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1403) Add SSL support for C++ Windows broker/client
[ https://issues.apache.org/jira/browse/QPID-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-1403: -- Priority: Major (was: Blocker) Fix Version/s: (was: 0.6) > Add SSL support for C++ Windows broker/client > - > > Key: QPID-1403 > URL: https://issues.apache.org/jira/browse/QPID-1403 > Project: Qpid > Issue Type: New Feature > Components: C++ Broker, C++ Client >Affects Versions: M4 > Environment: Windows XP+ >Reporter: Steve Huston >Assignee: Steve Huston > > The recently added SSL support in the C++ side should be available to Windows > as well. Not yet sure how much architectural work this may be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1403) Add SSL support for C++ Windows broker/client
[ https://issues.apache.org/jira/browse/QPID-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790839#action_12790839 ] Andrew Stitcher commented on QPID-1403: --- Why is this a blocking bug? It is a new feature - I don't see how a new feature could block a release. > Add SSL support for C++ Windows broker/client > - > > Key: QPID-1403 > URL: https://issues.apache.org/jira/browse/QPID-1403 > Project: Qpid > Issue Type: New Feature > Components: C++ Broker, C++ Client >Affects Versions: M4 > Environment: Windows XP+ >Reporter: Steve Huston >Assignee: Steve Huston >Priority: Blocker > Fix For: 0.6 > > > The recently added SSL support in the C++ side should be available to Windows > as well. Not yet sure how much architectural work this may be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2276) Make documentation tags wrap so pydoc can be read on 80-cols terminal
[ https://issues.apache.org/jira/browse/QPID-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Sarenik updated QPID-2276: -- Attachment: console-doc.diff This is the patch. > Make documentation tags wrap so pydoc can be read on 80-cols terminal > - > > Key: QPID-2276 > URL: https://issues.apache.org/jira/browse/QPID-2276 > Project: Qpid > Issue Type: Improvement > Components: Python Client >Affects Versions: 0.6 > Environment: Patch against current SVN checkout (890721) >Reporter: Jan Sarenik >Assignee: Rafael H. Schloming > Fix For: 0.6 > > Attachments: console-doc.diff > > > This patch wraps the documentation tags in console.py > More to come. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2244) AMQQueueMBean.viewMessages does not show 0-10 protocol MessageTransferMessage's
[ https://issues.apache.org/jira/browse/QPID-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790832#action_12790832 ] Robbie Gemmell commented on QPID-2244: -- Should we instead be removing those from display for the 0-8/0-9(and 0-10) mesages then? > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's > > > Key: QPID-2244 > URL: https://issues.apache.org/jira/browse/QPID-2244 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Blocker > Fix For: 0.6 > > > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's, it can only show messages based on the AMQMessage > class used by lower ptorocol versions. As such a user will not see messages > on the queue if they are produced with a 0-10 client but will for a 0-8/0-9 > client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2276) Make documentation tags wrap so pydoc can be read on 80-cols terminal
Make documentation tags wrap so pydoc can be read on 80-cols terminal - Key: QPID-2276 URL: https://issues.apache.org/jira/browse/QPID-2276 Project: Qpid Issue Type: Improvement Components: Python Client Affects Versions: 0.6 Environment: Patch against current SVN checkout (890721) Reporter: Jan Sarenik Assignee: Rafael H. Schloming Fix For: 0.6 This patch wraps the documentation tags in console.py More to come. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2212) C++ messaging spout and drain examples don't build on Windows
[ https://issues.apache.org/jira/browse/QPID-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston resolved QPID-2212. Resolution: Fixed Fix Version/s: 0.6 No, that was unrelated unfortunately. The problem ended up being use of qpid::Options inlined calls to boost program_options which required adding that lib explicitly (Windows examples build without boost references normally). Fixed on trunk r890888. > C++ messaging spout and drain examples don't build on Windows > - > > Key: QPID-2212 > URL: https://issues.apache.org/jira/browse/QPID-2212 > Project: Qpid > Issue Type: Bug > Components: Qpid Examples >Affects Versions: 0.6 > Environment: Windows >Reporter: Steve Huston >Assignee: Steve Huston > Fix For: 0.6 > > > The new qpid/cpp/examples/messaging spout and drain examples get link > failures for boost::program_options entrypoints. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: r890481 Changes to TCPConnector implementation
Hi Andrew, > On Mon, 2009-12-14 at 20:13 -0500, Steve Huston wrote: > > Hi Andrew, > > > > I'll respond in more depth tomorrow, but for now I'd just > like to note > > that I'm not proposing to add a new transport - I just want > to stick a > > shim between the existing transport and the aio, on Windows only. > > Maybe we are talking at cross purposes, I'm not sure, surely > by definition adding a transport that was not previously > supported is adding a new transport regardless of the way you > do it. It's adding a new feature, yes. > I think you are trying to argue that your strategy for > adding this new ssl transport is low risk. Exactly. > I'm arguing 2 things: > > 1. I don't think I like your strategy, but I'm not 100% clear > what it is exactly yet. The whole Connector layer is a shim > layer It's a pretty hefty shim. > so adding another shim seems to me to be likely to > complicate things and hinder refactoring clean ups to merge > the existing posix ssl and tcp transports into more maintainable code. I agree that refactoring a number of things would be The Right Thing to do. There's a lot of duplicate code between the current TCP connectors, the AIO layer, and the Linux/NSS-based SSL support. Looking at it, there are some fixes/features made to the TCP-base connector, for example, that weren't migrated to the NSS-based SSL support (such as read credit). I don't want to make this problem worse by doing another copy/paste/adjust. (Actually, I did that for the initial cut of client-side SSL support... I could go back in that direction to get this in for 0.6 if needed) Lacking the resources and the time schedule to refactor both Linux and Windows at this point, I came up with a middle ground to just open up the steps in the TCPConnector so I can insert a layer that knows to handle the SSL needs. It's specific to Windows and gets the job done until we can sensibly refactor other things. Note that when I did the original Windows port, this point that things needed refactoring also came up. I was convinced to not go that route, and that this area would be revisited at some point. That day hasn't come, and I'm not holding my breath for when it does. The way I was going about this is that the Windows-specific SslConnector reuses TCPConnector's frame-handling code - SslConnector does a couple things: - Puts an SslIo shim between itself and AsynchIO that knows to handle the SSL negotiation, and encrypt/decrypt operations - Waits to initiate the AMQP protocol until after the SSL negotiation is done > 2. I'm planning to put out a release candidate at the end of > the week and I don't want to destabilise existing well > working code in the next few days. Neither do I, which is why I avoided refactoring the AMQP frame-handling code out of TCPConnector, SslConnector, et al. Linux code gets left alone; the new code is for Windows and avoids risking Linux. > I'm sorry that windows ssl will not be in 0.6, but I'm very > open to making the 0.7 release cycle very short if there are > features that people want to release very soon. It is rather important to get this into 0.6, but let me confer with the powers that be and see what we can do. > All that being said I'd be keen to see your proposed code for > review before checkin. I'll make a new jira for it when I have code ready (which should be today). -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2244) AMQQueueMBean.viewMessages does not show 0-10 protocol MessageTransferMessage's
[ https://issues.apache.org/jira/browse/QPID-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790813#action_12790813 ] Rob Godfrey commented on QPID-2244: --- clusterID never meant anything propertyFlags would have been a weird thing to expose directly - it was simply a way of packing multiple binary flags (immediate, etc.) into a single integer to save on memory overhead > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's > > > Key: QPID-2244 > URL: https://issues.apache.org/jira/browse/QPID-2244 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Blocker > Fix For: 0.6 > > > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's, it can only show messages based on the AMQMessage > class used by lower ptorocol versions. As such a user will not see messages > on the queue if they are produced with a 0-10 client but will for a 0-8/0-9 > client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2263) Housekeeping thread can throw NPE and stop running.
[ https://issues.apache.org/jira/browse/QPID-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2263. Resolution: Fixed Reviewed ok, though poss need separate JIRA for protection within housekeeping thread for exceptions > Housekeeping thread can throw NPE and stop running. > --- > > Key: QPID-2263 > URL: https://issues.apache.org/jira/browse/QPID-2263 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: M3, M4, 0.5 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > The following NPE stack trace has been observed on the housekeeping thread: > Exception in thread "Queue-housekeeping-dev" java.lang.NullPointerException > at > org.apache.qpid.server.queue.WeakReferenceMessageHandle.populateFromMessageMetaData(WeakReferenceMessageHandle.java:85) > at > org.apache.qpid.server.queue.WeakReferenceMessageHandle.loadMessageMetaData(WeakReferenceMessageHandle.java:79) > at > org.apache.qpid.server.queue.WeakReferenceMessageHandle.getContentHeaderBody(WeakReferenceMessageHandle.java:64) > at > org.apache.qpid.server.queue.AMQMessage.getContentHeaderBody(AMQMessage.java:273) > at > org.apache.qpid.server.queue.NotificationCheck$2.notifyIfNecessary(NotificationCheck.java:53) > at > org.apache.qpid.server.queue.AMQQueueMBean.checkForNotification(AMQQueueMBean.java:263) > at > org.apache.qpid.server.queue.SimpleAMQQueue.checkMessageStatus(SimpleAMQQueue.java:1627) > at > org.apache.qpid.server.virtualhost.VirtualHost$1RemoveExpiredMessagesTask.run(VirtualHost.java:268) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > Preventing the HK thread from working on deleted messages will ensure that > this situation does not occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1304) SimpleACL is unable to provide virtualhost level access control for a given user
[ https://issues.apache.org/jira/browse/QPID-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-1304. Resolution: Fixed Reviewed/tested > SimpleACL is unable to provide virtualhost level access control for a given > user > > > Key: QPID-1304 > URL: https://issues.apache.org/jira/browse/QPID-1304 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: M2.1, M3, M4, 0.5 >Reporter: Martin Ritchie >Assignee: Robbie Gemmell > Fix For: 0.6 > > > The removal of the VHostPassword file in favour of the new ACL format has > lost the ability to limit access per virtualhost. It should be possible to > define permissions for an entire virtual host on a user basis.There should be > a way to provide permissions across all artifacts in a vh for a given user. > We need to implement the section in the XML ACL file to restore the > functionality that was present with the VHost PrincipalDatabase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2093) QueueDelete doesn't check durability of queue before performing store delete
[ https://issues.apache.org/jira/browse/QPID-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2093. Resolution: Fixed Good to see both tests and comments (javadoc), good stuff > QueueDelete doesn't check durability of queue before performing store delete > > > Key: QPID-2093 > URL: https://issues.apache.org/jira/browse/QPID-2093 > Project: Qpid > Issue Type: Bug > Components: Java Management : JMX Interface >Affects Versions: 0.5 >Reporter: Martin Ritchie >Assignee: Robbie Gemmell > Fix For: 0.6 > > > The JMX queueDelete method does not check the durablity of the queue so calls > delete on the store for transient queues. This results in a NOT_FOUND > exception being thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2092) Move system test configuration to the systest package
[ https://issues.apache.org/jira/browse/QPID-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2092. Resolution: Fixed > Move system test configuration to the systest package > - > > Key: QPID-2092 > URL: https://issues.apache.org/jira/browse/QPID-2092 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > Just to tidy things up a bit. > Move the test configuration files to the systest package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1760) Improve toString method for JMSMessage
[ https://issues.apache.org/jira/browse/QPID-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-1760. Resolution: Fixed Looks ok to me > Improve toString method for JMSMessage > -- > > Key: QPID-1760 > URL: https://issues.apache.org/jira/browse/QPID-1760 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.6 > > > Currently the toString method does not print any meaningful information for > Byte, Stream or Map message. > The AbstractJMSMethod is also not printing the replyTo (if available) and > also printing the properties in one line which makes it a bit unreadable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2244) AMQQueueMBean.viewMessages does not show 0-10 protocol MessageTransferMessage's
[ https://issues.apache.org/jira/browse/QPID-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2244. Resolution: Fixed Changes look ok with caveat that propertyFlags and clusterID not available on 0-10 messages > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's > > > Key: QPID-2244 > URL: https://issues.apache.org/jira/browse/QPID-2244 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Blocker > Fix For: 0.6 > > > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's, it can only show messages based on the AMQMessage > class used by lower ptorocol versions. As such a user will not see messages > on the queue if they are produced with a 0-10 client but will for a 0-8/0-9 > client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2244) AMQQueueMBean.viewMessages does not show 0-10 protocol MessageTransferMessage's
[ https://issues.apache.org/jira/browse/QPID-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790780#action_12790780 ] Marnie McCormack commented on QPID-2244: Comment from Robbie re the status of this JIRA, which I've actioned: Martin and I have both made some additions so the 0-10 messages now show up in the message list and have similar basic header output to the 0-8/0-9 messages, so it is no longer in a blocking position. A couple of the values reported previously (clusterID and propertyFlags) don't seem to exist/be exposed in the 0-10 code so they are just showing with empty values just now. With that, move 2244 to RTR? (done) > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's > > > Key: QPID-2244 > URL: https://issues.apache.org/jira/browse/QPID-2244 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Blocker > Fix For: 0.6 > > > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's, it can only show messages based on the AMQMessage > class used by lower ptorocol versions. As such a user will not see messages > on the queue if they are produced with a 0-10 client but will for a 0-8/0-9 > client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2244) AMQQueueMBean.viewMessages does not show 0-10 protocol MessageTransferMessage's
[ https://issues.apache.org/jira/browse/QPID-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2244: --- Status: Ready To Review (was: In Progress) > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's > > > Key: QPID-2244 > URL: https://issues.apache.org/jira/browse/QPID-2244 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Blocker > Fix For: 0.6 > > > AMQQueueMBean.viewMessages does not show 0-10 protocol > MessageTransferMessage's, it can only show messages based on the AMQMessage > class used by lower ptorocol versions. As such a user will not see messages > on the queue if they are produced with a 0-10 client but will for a 0-8/0-9 > client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: r890481 Changes to TCPConnector implementation
On Mon, 2009-12-14 at 20:13 -0500, Steve Huston wrote: > Hi Andrew, > > I'll respond in more depth tomorrow, but for now I'd just like to note > that I'm not proposing to add a new transport - I just want to stick a > shim between the existing transport and the aio, on Windows only. Maybe we are talking at cross purposes, I'm not sure, surely by definition adding a transport that was not previously supported is adding a new transport regardless of the way you do it. I think you are trying to argue that your strategy for adding this new ssl transport is low risk. I'm arguing 2 things: 1. I don't think I like your strategy, but I'm not 100% clear what it is exactly yet. The whole Connector layer is a shim layer so adding another shim seems to me to be likely to complicate things and hinder refactoring clean ups to merge the existing posix ssl and tcp transports into more maintainable code. 2. I'm planning to put out a release candidate at the end of the week and I don't want to destabilise existing well working code in the next few days. I'm sorry that windows ssl will not be in 0.6, but I'm very open to making the 0.7 release cycle very short if there are features that people want to release very soon. All that being said I'd be keen to see your proposed code for review before checkin. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2028) Broker test do not cleanup ApplicationRegistry that they create
[ https://issues.apache.org/jira/browse/QPID-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790752#action_12790752 ] Martin Ritchie commented on QPID-2028: -- Current trunk 'ant test' run doesn't highlight that ARs are not being cleaned up. Resoloving this issue. > Broker test do not cleanup ApplicationRegistry that they create > --- > > Key: QPID-2028 > URL: https://issues.apache.org/jira/browse/QPID-2028 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > Summmary: > The non-unit tests in the broker package that cause an ApplicationRegistry to > be created do not correctly remove this registry at the end of the test. This > is what causes the ApplicationRegistry errors at the end of the ant run. > Sharing ARs between tests will increase the likelyhood of cross contamination > of tests leading to spurious failures. > The tests should ensure that the correctly close any AR they create. > This is more relevant now as the new broker logging uses a ThreadLocal to > maintain the current logger and only through a correct clean up of all tests > can it be successfully tested in isolation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2028) Broker test do not cleanup ApplicationRegistry that they create
[ https://issues.apache.org/jira/browse/QPID-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie resolved QPID-2028. -- Resolution: Fixed Current trunk 'ant test' run suggest ARs are correctly being cleaned up. > Broker test do not cleanup ApplicationRegistry that they create > --- > > Key: QPID-2028 > URL: https://issues.apache.org/jira/browse/QPID-2028 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > Summmary: > The non-unit tests in the broker package that cause an ApplicationRegistry to > be created do not correctly remove this registry at the end of the test. This > is what causes the ApplicationRegistry errors at the end of the ant run. > Sharing ARs between tests will increase the likelyhood of cross contamination > of tests leading to spurious failures. > The tests should ensure that the correctly close any AR they create. > This is more relevant now as the new broker logging uses a ThreadLocal to > maintain the current logger and only through a correct clean up of all tests > can it be successfully tested in isolation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2242) JMS_QPID_DESTTYPE is not set making getJMSDestination unusable.
[ https://issues.apache.org/jira/browse/QPID-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2242: - Component/s: Java Common Java Client Affects Version/s: M3 M4 0.5 Fix Version/s: 0.6 > JMS_QPID_DESTTYPE is not set making getJMSDestination unusable. > --- > > Key: QPID-2242 > URL: https://issues.apache.org/jira/browse/QPID-2242 > Project: Qpid > Issue Type: Bug > Components: Java Client, Java Common >Affects Versions: M3, M4, 0.5 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > The problem is that Qpid M2.1 (and earlier) sets the JMS_QPID_DESTTYPE header > property before sending. > If you try and do that on a message that doesn't have the property set then > it will attempt to write it into the _encodedForm ByteBuffer if there is one. > In the scenario where you are receiving messages and then re-sending them not > creating new ones. The header has already been read so the buffer limit and > position are the same which means any write to the buffer will throw a > BufferOverflowException. In short the headers are Read Only. > I have tested with M2.1 After the merge to trunk for M3 the setting of this > property was removed. Which does mean that the JMS Destination is marked as > 'unknown' rather than 'direct' which means if you attempted to do > message.getJMSDestination() to send the message back in to the queue for > reprocessing it would fail. > Further investigations: > Understand why this setting was dropped after the Merge from M2.x to trunk. > This property is used to control the type of Destination that > message.getJMSDestination() returns. > Need to check M1 to see if it sets the value on sent Messages. > Also need to check how the 0-10 code path defines the JMSDestination() as it > too appears to never to have a value set and so will be an 'unknown' > destination. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2094) Allow System tests to run without -Dtest.output to ease in IDE debugging
[ https://issues.apache.org/jira/browse/QPID-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2094. Resolution: Fixed Looks fine to me > Allow System tests to run without -Dtest.output to ease in IDE debugging > > > Key: QPID-2094 > URL: https://issues.apache.org/jira/browse/QPID-2094 > Project: Qpid > Issue Type: Bug >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.6 Defect Clean Up
Feel free Marnie On Tue, Dec 15, 2009 at 12:00 PM, Martin Ritchie wrote: > Hi, > > I'd recommend descoping to a 'No Version' that way when we come to do > 0.7 release we don't bump everything in to 0.8. If people pick > something up to work on then they can move it in to the version they > are aiming to fix it by. > > Cheers > Martin > > 2009/12/15 Marnie McCormack : > > Just re-sending in case this hit people's JIRA filters last time. > > > > If you are actually working on something for 0.6 - please, please move it > to > > 'In progress' so I can see that, or suffer it being descoped in the > > interests of getting to the end of 0.6 (blockers aside). > > > > Marnie > > > > -- Forwarded message -- > > From: Marnie McCormack > > Date: Thu, Dec 10, 2009 at 3:48 PM > > Subject: 0.6 JIRA Clean Up > > To: dev@qpid.apache.org > > > > > > Be afraid - it's that time. > > > > I'll be taking a broad brush approach to non-critical/bloacker items > still > > marked as for 0.6 (99 at the moment) over the next few days. > > > > If you are still planning to get any item still sitting in an > unprogressed > > state into 0.6 please move it to 'In Progress' or face descoping into 0.7 > > :-) > > > > Shout if you object. > > > > Marnie > > > > > > -- > Martin Ritchie > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
[jira] Resolved: (QPID-2121) Allow QpidTestCase to set System Properties on external broker VMs.
[ https://issues.apache.org/jira/browse/QPID-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2121. Resolution: Fixed Remove random ; on line 197 > Allow QpidTestCase to set System Properties on external broker VMs. > --- > > Key: QPID-2121 > URL: https://issues.apache.org/jira/browse/QPID-2121 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Affects Versions: 0.5 >Reporter: Martin Ritchie >Assignee: Martin Ritchie >Priority: Minor > Fix For: 0.6 > > > Currently system properties can be set for the test VM via setSystemProperty. > Values set here are also currently copied to the external broker. However, > there are times when you want the test to have a custom system property but > not have that value copied to the broker. > One such time is in BrokerLoggingTest#testStartupDefaultLog4j. A custom > broker.ready value is needed and if copied to the broker it will be echo as > part of the command line and trigger the QTC to continue. > As solution is to provide two additional set*SystemProperty metdhosd : > setBrokerOnlySystemProperty and setTestOnlySystemProperty. > This allows the various VMs to be configured differently, whilst leaving the > functionality of setSystemProperty of copying the value to all VMs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.6 Defect Clean Up
Hi, I'd recommend descoping to a 'No Version' that way when we come to do 0.7 release we don't bump everything in to 0.8. If people pick something up to work on then they can move it in to the version they are aiming to fix it by. Cheers Martin 2009/12/15 Marnie McCormack : > Just re-sending in case this hit people's JIRA filters last time. > > If you are actually working on something for 0.6 - please, please move it to > 'In progress' so I can see that, or suffer it being descoped in the > interests of getting to the end of 0.6 (blockers aside). > > Marnie > > -- Forwarded message -- > From: Marnie McCormack > Date: Thu, Dec 10, 2009 at 3:48 PM > Subject: 0.6 JIRA Clean Up > To: dev@qpid.apache.org > > > Be afraid - it's that time. > > I'll be taking a broad brush approach to non-critical/bloacker items still > marked as for 0.6 (99 at the moment) over the next few days. > > If you are still planning to get any item still sitting in an unprogressed > state into 0.6 please move it to 'In Progress' or face descoping into 0.7 > :-) > > Shout if you object. > > Marnie > -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2091) Only virtualhosts defined in the virtualhost.xml file are initialised
[ https://issues.apache.org/jira/browse/QPID-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2091: --- Fix Version/s: (was: 0.6) 0.7 Moving out to 0.7, as per review comments needs some more work > Only virtualhosts defined in the virtualhost.xml file are initialised > - > > Key: QPID-2091 > URL: https://issues.apache.org/jira/browse/QPID-2091 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.7 > > > The problem is that we use the virtualhosts defined in the virtualhost.xml > file to control a loop for creating the virtualhosts. > If the virtualhost.xml file is not used in the configuration then no > virtualhosts are configured. > The problem in the ServerConfiguration class also means that any use of a > CombinedConfiguration cannot override settings in the virtualhost.xml file. > The fix to address the lack of virtualhosts is to copy the values from the > virtualhost.xml into the main config then use the main config as the source > for the configured virtualhosts. > This however, will still leave us with the problem of virtualhost.xml still > overriding any other configuration value. For now this is probably acceptable > as the work around is not to reference the virtualhost.xml in the config.xml > if you are using a Combined Configuration. If wish to have a virtualhost.xml > file then that can easily be included in the combined file and will opporate > as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.6 JIRA Queries - Please update your items ?
Sorry mail filters whisked this away to my JIRA folder 2009/12/14 Marnie McCormack : > Hi All, > > A few questions for 0/6 JIRAs > > Martin - QPID-2091 has a commit for a tactical? fix. Could you close this > JIRA out if this is the case, and create a new for the strategic change in > 0.7 (so 0.6 release notes can incude the work done). Or if I have the wrong > end of the stick, move this item to 0.7 lock, stock and whatnot pls ? Thx. Updated JIRA to 'Ready To Review', will raise a subsequent JIRA for fixing the other issue though as commented on JIRA think best course of action is to look to migrate to a new configuration format. > Martin - are there any uncommitted items for QPID-1907 No, all work on sub-JIRAs has been committed, QPID-2002 still needs review which is holding QPID-1907 open. > Robbie/Rob - QPID-2244 - is this a blocker for release ? > > Was cracking on tidying up but JIRA seems to be flaking out now,,so I'll > sign off and do some more tomorrow. > > Regards, > Marnie > -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2091) Only virtualhosts defined in the virtualhost.xml file are initialised
[ https://issues.apache.org/jira/browse/QPID-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2091: --- Status: Open (was: Ready To Review) Really not keen on working around a config that all our users are making use of. Should address the underlying issue and then revert the removal of virtualhosts.xml imho. > Only virtualhosts defined in the virtualhost.xml file are initialised > - > > Key: QPID-2091 > URL: https://issues.apache.org/jira/browse/QPID-2091 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > The problem is that we use the virtualhosts defined in the virtualhost.xml > file to control a loop for creating the virtualhosts. > If the virtualhost.xml file is not used in the configuration then no > virtualhosts are configured. > The problem in the ServerConfiguration class also means that any use of a > CombinedConfiguration cannot override settings in the virtualhost.xml file. > The fix to address the lack of virtualhosts is to copy the values from the > virtualhost.xml into the main config then use the main config as the source > for the configured virtualhosts. > This however, will still leave us with the problem of virtualhost.xml still > overriding any other configuration value. For now this is probably acceptable > as the work around is not to reference the virtualhost.xml in the config.xml > if you are using a Combined Configuration. If wish to have a virtualhost.xml > file then that can easily be included in the combined file and will opporate > as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2091) Only virtualhosts defined in the virtualhost.xml file are initialised
[ https://issues.apache.org/jira/browse/QPID-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790704#action_12790704 ] Martin Ritchie commented on QPID-2091: -- This issue has been addressed. Virtualhosts defined in the virtualhosts.xml are not the only ones initalised any more. I'll raise a JIRA for the fact that values configured in the virtualhost.xml will overwrite the main config.xml. Whilst sorting that out is a very small change we should be looking to migrate our config to a more manageable format. > Only virtualhosts defined in the virtualhost.xml file are initialised > - > > Key: QPID-2091 > URL: https://issues.apache.org/jira/browse/QPID-2091 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > The problem is that we use the virtualhosts defined in the virtualhost.xml > file to control a loop for creating the virtualhosts. > If the virtualhost.xml file is not used in the configuration then no > virtualhosts are configured. > The problem in the ServerConfiguration class also means that any use of a > CombinedConfiguration cannot override settings in the virtualhost.xml file. > The fix to address the lack of virtualhosts is to copy the values from the > virtualhost.xml into the main config then use the main config as the source > for the configured virtualhosts. > This however, will still leave us with the problem of virtualhost.xml still > overriding any other configuration value. For now this is probably acceptable > as the work around is not to reference the virtualhost.xml in the config.xml > if you are using a Combined Configuration. If wish to have a virtualhost.xml > file then that can easily be included in the combined file and will opporate > as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2115) enable QpidTestCase to clean up the broker between tests
[ https://issues.apache.org/jira/browse/QPID-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2115. Resolution: Fixed Changes look ok, more comments be good > enable QpidTestCase to clean up the broker between tests > > > Key: QPID-2115 > URL: https://issues.apache.org/jira/browse/QPID-2115 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Robbie Gemmell >Assignee: Martin Ritchie >Priority: Minor > Fix For: 0.6 > > > QpidTestCase makes use of the broker.clean property to clean up any broker > test artificats. However, this only occurs if a test fails at broker startup > and does not take place between tests. As a result, tests using persistent > stores can interact with each other, causing spurious results and increasing > test execution times due to store recovery overheads. A toggle should be > provided to enable executing the broker.clean command between individual > tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2091) Only virtualhosts defined in the virtualhost.xml file are initialised
[ https://issues.apache.org/jira/browse/QPID-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2091: - Status: Ready To Review (was: In Progress) > Only virtualhosts defined in the virtualhost.xml file are initialised > - > > Key: QPID-2091 > URL: https://issues.apache.org/jira/browse/QPID-2091 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > The problem is that we use the virtualhosts defined in the virtualhost.xml > file to control a loop for creating the virtualhosts. > If the virtualhost.xml file is not used in the configuration then no > virtualhosts are configured. > The problem in the ServerConfiguration class also means that any use of a > CombinedConfiguration cannot override settings in the virtualhost.xml file. > The fix to address the lack of virtualhosts is to copy the values from the > virtualhost.xml into the main config then use the main config as the source > for the configured virtualhosts. > This however, will still leave us with the problem of virtualhost.xml still > overriding any other configuration value. For now this is probably acceptable > as the work around is not to reference the virtualhost.xml in the config.xml > if you are using a Combined Configuration. If wish to have a virtualhost.xml > file then that can easily be included in the combined file and will opporate > as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2001) [Logging] Provide mechanism to provide fixed log messages
[
https://issues.apache.org/jira/browse/QPID-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790700#action_12790700
]
Martin Ritchie commented on QPID-2001:
--
Changes mereged to trunk at r886842 forgot QPID-2001 entry in log message:
http://svn.apache.org/viewvc?view=revision&revision=886842
> [Logging] Provide mechanism to provide fixed log messages
> -
>
> Key: QPID-2001
> URL: https://issues.apache.org/jira/browse/QPID-2001
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Martin Ritchie
>Assignee: Martin Ritchie
> Fix For: 0.6
>
> Attachments: qpid-2001-response.txt, QPID-2001-review.txt
>
>
> Summary:
> As highlighted in the Technical specification:
> http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
> The logging design calls for the ablity to peform something similar to:
> String message = BrokerLogMessages.BRK-1001(version, build);
> Producing:
> BRK-1001 : Startup : Version: 0.6 Build: 794277
> Where the actual LogMessage is parameterized :
> BRK-1001 = Startup : Version {0} Build: {1}
> This has many benefits:
> - it easy to locate where a particular log messasge is sued
> - it makes updating the log messages straight forward.
> - it makes localisation easy
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
0.6 Defect Clean Up
Just re-sending in case this hit people's JIRA filters last time. If you are actually working on something for 0.6 - please, please move it to 'In progress' so I can see that, or suffer it being descoped in the interests of getting to the end of 0.6 (blockers aside). Marnie -- Forwarded message -- From: Marnie McCormack Date: Thu, Dec 10, 2009 at 3:48 PM Subject: 0.6 JIRA Clean Up To: dev@qpid.apache.org Be afraid - it's that time. I'll be taking a broad brush approach to non-critical/bloacker items still marked as for 0.6 (99 at the moment) over the next few days. If you are still planning to get any item still sitting in an unprogressed state into 0.6 please move it to 'In Progress' or face descoping into 0.7 :-) Shout if you object. Marnie
[jira] Updated: (QPID-2139) Usability of log messages
[ https://issues.apache.org/jira/browse/QPID-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2139: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > Usability of log messages > - > > Key: QPID-2139 > URL: https://issues.apache.org/jira/browse/QPID-2139 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Jonathan Robie > Fix For: 0.7 > > > Our broker log messages are currently ad-hoc, difficult to grep or read, with > a bad signal/noise ratio. They could be improved as follows: > - Define log-level usage guidelines, document, and enforce > - Define user-relevant categories for logging, document, and enforce > - Design messages to be easily greppable > - Avoid logging redundant information. Log entry into a state / exit from a > state, instead of redundant entries saying what state you are in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2049) Examples don't allow use of SSL
[
https://issues.apache.org/jira/browse/QPID-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marnie McCormack updated QPID-2049:
---
Fix Version/s: (was: 0.6)
0.7
Moving items unlikely to be in 0.6 out to 0.7 (since not in progress)
> Examples don't allow use of SSL
> ---
>
> Key: QPID-2049
> URL: https://issues.apache.org/jira/browse/QPID-2049
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
>Reporter: Gordon Sim
>Priority: Minor
> Fix For: 0.7
>
>
> Need to apply change similar to following patch to all examples:
> Index: examples/direct/declare_queues.cpp
> ===
> --- examples/direct/declare_queues.cpp (revision 797423)
> +++ examples/direct/declare_queues.cpp (working copy)
> @@ -53,12 +53,14 @@
> int main(int argc, char** argv) {
> -const char* host = argc>1 ? argv[1] : "127.0.0.1";
> -int port = argc>2 ? atoi(argv[2]) : 5672;
> +ConnectionSettings settings;
> +if (argc>1) settings.host = argv[1];
> +if (argc>2) settings.port = atoi(argv[2]);
> +if (argc>3) settings.protocol = argv[3];
> Connection connection;
> try {
> - connection.open(host, port);
> + connection.open(settings);
>Session session = connection.newSession();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1832) Tests for using the following c++ broker features from JMS
[ https://issues.apache.org/jira/browse/QPID-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-1832: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > Tests for using the following c++ broker features from JMS > -- > > Key: QPID-1832 > URL: https://issues.apache.org/jira/browse/QPID-1832 > Project: Qpid > Issue Type: Test > Components: Java Tests >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.7 > > > It would be nice to have test cases using the JMS client for the following > c++ broker features. > * ring queues > * last value queues > * exchange sequencing > * use of the headers and xml exchanges > * federation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1935) FailoverTest and QueueBrowser*Test fail on persistent builds
[ https://issues.apache.org/jira/browse/QPID-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-1935: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > FailoverTest and QueueBrowser*Test fail on persistent builds > > > Key: QPID-1935 > URL: https://issues.apache.org/jira/browse/QPID-1935 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Affects Versions: 0.6 >Reporter: Aidan Skinner >Assignee: Aidan Skinner > Fix For: 0.7 > > > The failover and queuebrowser tests do weird things that cause them to fail > when run persistently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2084) 0-10 code path does not appear to throw exception on consume from non-existent queue
[
https://issues.apache.org/jira/browse/QPID-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marnie McCormack updated QPID-2084:
---
Fix Version/s: (was: 0.6)
0.7
Moving items unlikely to be in 0.6 out to 0.7 (since not in progress)
> 0-10 code path does not appear to throw exception on consume from
> non-existent queue
>
>
> Key: QPID-2084
> URL: https://issues.apache.org/jira/browse/QPID-2084
> Project: Qpid
> Issue Type: Bug
>Reporter: Martin Ritchie
> Fix For: 0.7
>
>
> Running the new DynamicQueueExchangeCreateTest, the test appears to throw the
> exception on close rather than the consume.
> ch=0 id=0 ExecutionException(errorCode=NOT_FOUND, commandId=2, classCode=7,
> commandCode=4, fieldIndex=0, description=not-found:
> Queue not found: DynamicQueueExchangeCreateTest-testQueueDeclare
> (qpid/broker/SessionAdapter.cpp:743), errorInfo={})
> org.apache.qpid.transport.SessionException: ch=0 id=0
> ExecutionException(errorCode=NOT_FOUND, commandId=2, classCode=7,
> commandCode=4, fieldIndex=0, description=not-found: Queue not found:
> DynamicQueueExchangeCreateTest-testQueueDeclare
> (qpid/broker/SessionAdapter.cpp:743), errorInfo={})
> at org.apache.qpid.transport.Session.sync(Session.java:701)
> at org.apache.qpid.transport.Session.sync(Session.java:674)
> at
> org.apache.qpid.client.AMQSession_0_10.sendClose(AMQSession_0_10.java:342)
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:667)
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:633)
> at
> org.apache.qpid.client.AMQConnection.closeAllSessions(AMQConnection.java:1113)
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:1008)
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:997)
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:981)
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:972)
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:967)
> at
> org.apache.qpid.test.utils.QpidTestCase.tearDown(QpidTestCase.java:875)
> at
> org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:224)
> at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:270)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2141) need consistent naming for broker entities
[ https://issues.apache.org/jira/browse/QPID-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2141: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > need consistent naming for broker entities > -- > > Key: QPID-2141 > URL: https://issues.apache.org/jira/browse/QPID-2141 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Jonathan Robie > Fix For: 0.7 > > > We need consistent naming for broker entity identities. > One reason this is important: the ability to name entities in log messages / > management tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2224) Repeated random failures for MINANetworkDriverTest
[ https://issues.apache.org/jira/browse/QPID-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2224: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > Repeated random failures for MINANetworkDriverTest > -- > > Key: QPID-2224 > URL: https://issues.apache.org/jira/browse/QPID-2224 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Rajith Attapattu >Assignee: Aidan Skinner >Priority: Minor > Fix For: 0.7 > > > The MINANetworkDriverTest has repeated random test failures for last month > and half or so. > IIRC there two tests that behaved this way. > I will capture the logs for each different failure and add as and when they > occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2225) FailoverBeforeConsumingRecoverTest failure with Java Broker
[ https://issues.apache.org/jira/browse/QPID-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2225: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > FailoverBeforeConsumingRecoverTest failure with Java Broker > --- > > Key: QPID-2225 > URL: https://issues.apache.org/jira/browse/QPID-2225 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Rajith Attapattu > Fix For: 0.7 > > Attachments: test-logs.tar.gz > > > The "FailoverBeforeConsumingRecoverTest" is failing when run against the in > vm broker. > logs attached. > Testcase: testRecoverResendsMsgs took 0.27 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgs(RecoverTest.java:125) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testRecoverResendsMsgsAckOnEarlier took 0.176 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgsAckOnEarlier(RecoverTest.java:142) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testAcknowledgePerConsumer took 0.194 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testAcknowledgePerConsumer(RecoverTest.java:198) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testRecoverInAutoAckListener took 31.154 sec >FAILED > null > junit.framework.AssertionFailedError >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverInAutoAckListener(RecoverTest.java:292) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > -- > Testsuite: org.apache.qpid.test.unit.ack.RecoverTest > Tests run: 4, Failures: 1, Errors: 3, Time elapsed: 31.652 sec > Testcase: testRecoverResendsMsgs took 0.161 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgs(RecoverTest.java:125) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testRecoverResendsMsgsAckOnEarlier took 0.161 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testRecoverResendsMsgsAckOnEarlier(RecoverTest.java:142) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:319) > Testcase: testAcknowledgePerConsumer took 0.161 sec >Caused an ERROR > Recovery was interrupted by fail-over. Recovery status is not known. > org.apache.qpid.client.JMSAMQException: Recovery was interrupted by > fail-over. Recovery status is not known. >at org.apache.qpid.client.AMQSession.recover(AMQSession.java:1530) >at > org.apache.qpid.test.unit.ack.RecoverTest.testAcknowledgePerConsumer(RecoverTest.java:198) >at > org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:256) >at org.
[jira] Updated: (QPID-2165) MINANetworkDriverTest fails to socket already in use
[ https://issues.apache.org/jira/browse/QPID-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2165: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > MINANetworkDriverTest fails to socket already in use > > > Key: QPID-2165 > URL: https://issues.apache.org/jira/browse/QPID-2165 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Affects Versions: 0.6 >Reporter: Aidan Skinner >Assignee: Aidan Skinner >Priority: Minor > Fix For: 0.7 > > > Mail from Rajith: > The above test fails occasionally. > It could be due to the port is already in use? perhaps caused by a > previous test not cleaning up properly? > Sorry I haven't had time to dig deeper, but hope the following will help. > Testcase: testBindOpen took 0.15 sec > Testcase: testBindOpenCloseOpen took 0.004 sec >Caused an ERROR > Could not bind to *:2323 > java.net.BindException: Could not bind to *:2323 >at > org.apache.qpid.transport.network.mina.MINANetworkDriver.bind(MINANetworkDriver.java:174) >at > org.apache.qpid.transport.network.mina.MINANetworkDriverTest.testBindOpenCloseOpen(MINANetworkDriverTest.java:108) > Testcase: testBindPortInUse took 0.008 sec >FAILED > First bind should not fail > junit.framework.AssertionFailedError: First bind should not fail >at > org.apache.qpid.transport.network.mina.MINANetworkDriverTest.testBindPortInUse(MINANetworkDriverTest.java:136) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1668) org.apache.qpid.server.queue.SimpleAMQQueueThreadPoolTest fails
[ https://issues.apache.org/jira/browse/QPID-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-1668: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > org.apache.qpid.server.queue.SimpleAMQQueueThreadPoolTest fails > --- > > Key: QPID-1668 > URL: https://issues.apache.org/jira/browse/QPID-1668 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Affects Versions: 0.6 >Reporter: Aidan Skinner > Fix For: 0.7 > > > When run as part of the test suite this fails with: > junit.framework.AssertionFailedError: References exist before start! > expected:<0> but was:<5> > at > org.apache.qpid.server.queue.SimpleAMQQueueThreadPoolTest.test(SimpleAMQQueueThreadPoolTest.java:39) > run on it's own it passes. Hurrah! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2144) Need consistent design / rationalized features across Python tools
[ https://issues.apache.org/jira/browse/QPID-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack updated QPID-2144: --- Fix Version/s: (was: 0.6) 0.7 Moving items unlikely to be in 0.6 out to 0.7 (since not in progress) > Need consistent design / rationalized features across Python tools > -- > > Key: QPID-2144 > URL: https://issues.apache.org/jira/browse/QPID-2144 > Project: Qpid > Issue Type: Improvement > Components: python tools >Reporter: Jonathan Robie > Fix For: 0.7 > > > The Python tools need to use similar design, and we need to consider how > functionality is distributed among the tools, so we have a rational set of > tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [C++] QPID-1984 - 0.6 Release Blocker ?
Thanks Gordon Marnie On Tue, Dec 15, 2009 at 11:17 AM, Gordon Sim wrote: > On 12/15/2009 10:02 AM, Marnie McCormack wrote: > >> Could QPID-1984 possibly be moved down from blocker status, raised/updated >> 14th July. Anyone progressing this one ? >> > > It looks like it has already been fixed so I have updated it accordingly. > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
[jira] Assigned: (QPID-1830) BytesMessage is unreadable
[ https://issues.apache.org/jira/browse/QPID-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack reassigned QPID-1830: -- Assignee: Aidan Skinner (was: Marnie McCormack) > BytesMessage is unreadable > -- > > Key: QPID-1830 > URL: https://issues.apache.org/jira/browse/QPID-1830 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6, 0.7 >Reporter: Aidan Skinner >Assignee: Aidan Skinner >Priority: Critical > Fix For: 0.6 > > > This can easily be seen running the interop coordinator: > 2009-04-28 14:24:38,377 INFO [main] distributedtesting.Coordinator > (Coordinator.java:285) - Found distributed test case: > org.apache.qpid.interop.testcases.InteropTestCase4P2PMessageSize > javax.jms.MessageNotReadableException: You need to call reset() to make the > message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > 2009-04-28 14:24:39,690 INFO [main] distributedtesting.Coordinator > (Coordinator.java:330) - javax.jms.MessageNotReadableException: You need to > call reset() to make the message readable > java.lang.RuntimeException: javax.jms.MessageNotReadableException: You need > to call reset() to make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:407) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > Caused by: javax.jms.MessageNotReadableException: You need to call reset() to > make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > ... 5 more > This works on the 0.5-release branch, so is presumably a recentish break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1830) BytesMessage is unreadable
[ https://issues.apache.org/jira/browse/QPID-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack reassigned QPID-1830: -- Assignee: Marnie McCormack (was: Aidan Skinner) > BytesMessage is unreadable > -- > > Key: QPID-1830 > URL: https://issues.apache.org/jira/browse/QPID-1830 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6, 0.7 >Reporter: Aidan Skinner >Assignee: Marnie McCormack >Priority: Critical > Fix For: 0.6 > > > This can easily be seen running the interop coordinator: > 2009-04-28 14:24:38,377 INFO [main] distributedtesting.Coordinator > (Coordinator.java:285) - Found distributed test case: > org.apache.qpid.interop.testcases.InteropTestCase4P2PMessageSize > javax.jms.MessageNotReadableException: You need to call reset() to make the > message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > 2009-04-28 14:24:39,690 INFO [main] distributedtesting.Coordinator > (Coordinator.java:330) - javax.jms.MessageNotReadableException: You need to > call reset() to make the message readable > java.lang.RuntimeException: javax.jms.MessageNotReadableException: You need > to call reset() to make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:407) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > Caused by: javax.jms.MessageNotReadableException: You need to call reset() to > make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > ... 5 more > This works on the 0.5-release branch, so is presumably a recentish break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1830) BytesMessage is unreadable
[ https://issues.apache.org/jira/browse/QPID-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack reassigned QPID-1830: -- Assignee: Aidan Skinner > BytesMessage is unreadable > -- > > Key: QPID-1830 > URL: https://issues.apache.org/jira/browse/QPID-1830 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6, 0.7 >Reporter: Aidan Skinner >Assignee: Aidan Skinner >Priority: Critical > Fix For: 0.6 > > > This can easily be seen running the interop coordinator: > 2009-04-28 14:24:38,377 INFO [main] distributedtesting.Coordinator > (Coordinator.java:285) - Found distributed test case: > org.apache.qpid.interop.testcases.InteropTestCase4P2PMessageSize > javax.jms.MessageNotReadableException: You need to call reset() to make the > message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > 2009-04-28 14:24:39,690 INFO [main] distributedtesting.Coordinator > (Coordinator.java:330) - javax.jms.MessageNotReadableException: You need to > call reset() to make the message readable > java.lang.RuntimeException: javax.jms.MessageNotReadableException: You need > to call reset() to make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:407) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > org.apache.qpid.test.utils.ConversationFactory$Conversation.send(ConversationFactory.java:263) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.start(Coordinator.java:366) > at > org.apache.qpid.test.framework.distributedtesting.Coordinator.main(Coordinator.java:315) > Caused by: javax.jms.MessageNotReadableException: You need to call reset() to > make the message readable > at > org.apache.qpid.client.message.AbstractJMSMessage.checkReadable(AbstractJMSMessage.java:433) > at > org.apache.qpid.client.message.AbstractBytesMessage.toBodyString(AbstractBytesMessage.java:89) > at > org.apache.qpid.client.message.AbstractJMSMessage.toString(AbstractJMSMessage.java:371) > ... 5 more > This works on the 0.5-release branch, so is presumably a recentish break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2041) failed update to the Base64MD5PasswordFilePrincipalDatabase on disk may go unnoticed, preventing broker restart
[ https://issues.apache.org/jira/browse/QPID-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnie McCormack resolved QPID-2041. Resolution: Fixed Reviewed changes, as per similar changes to use of random rather than tmp location for file writes during update. Looks fine to me. > failed update to the Base64MD5PasswordFilePrincipalDatabase on disk may go > unnoticed, preventing broker restart > --- > > Key: QPID-2041 > URL: https://issues.apache.org/jira/browse/QPID-2041 > Project: Qpid > Issue Type: Bug >Affects Versions: M3, M4, 0.5 >Reporter: Robbie Gemmell >Assignee: Martin Ritchie >Priority: Critical > Fix For: 0.6 > > > failed update to the MD5PasswordFilePrincipalDatabase on disk may go > unnoticed, preventing broker restart > Certain use of the File.renameTo() function is not accompanied by a check of > the boolean result, meaning a failed rename can leave the file in the wrong > location, but the cached nature of the Base64MD5PasswordFilePrincipalDatabase > masks the failure until another operation is attempted upon it that needs the > output of the previously failed update. This has been observed in a situation > where the OS Temp dir is on one (local) file system, and the broker > configuration is on another (remote NFS) filesystem, which caused the rename > to fail unnoticed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [C++] QPID-1984 - 0.6 Release Blocker ?
On 12/15/2009 10:02 AM, Marnie McCormack wrote: Could QPID-1984 possibly be moved down from blocker status, raised/updated 14th July. Anyone progressing this one ? It looks like it has already been fixed so I have updated it accordingly. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2275) Time based roll over with DatePattern can result in log loss.
[ https://issues.apache.org/jira/browse/QPID-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie reassigned QPID-2275: Assignee: Martin Ritchie > Time based roll over with DatePattern can result in log loss. > - > > Key: QPID-2275 > URL: https://issues.apache.org/jira/browse/QPID-2275 > Project: Qpid > Issue Type: Sub-task >Affects Versions: M1, M2, M2.1, M3, M4 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.6 > > > When the log file rolls over it will be named according to DatePattern, it > will also however rollover based on that DatePattern. So if the log fills its > max size within that DatePattern the old backup file will be overwritten. > FIX: a .n value should be appended to the file so that we can have log files > with DatePattern '' resulting in log files 2009.0, 2009.1, 2009.2, ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1984) Poller assertion when running reliable_replication_test
[ https://issues.apache.org/jira/browse/QPID-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-1984. -- Resolution: Fixed Test renabled by r802993 with no further occurrences, so assume fixed. > Poller assertion when running reliable_replication_test > --- > > Key: QPID-1984 > URL: https://issues.apache.org/jira/browse/QPID-1984 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.6 > > > The reliable_replication_test has started failing (run under make check-long) > due to the source broker crashing with the following assertion: > Core was generated by `/home/gordon/qpid/cpp/src/.libs/lt-qpidd --daemon > --port 0 --no-data-dir --no-m'. > Program terminated with signal 6, Aborted. > [New process 14736] > [New process 14739] > [New process 14738] > [New process 14737] > [New process 14735] > [New process 14734] > [New process 14733] > [New process 14732] > #0 0x003c52e30215 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x003c52e30215 in raise () from /lib64/libc.so.6 > #1 0x003c52e31cc0 in abort () from /lib64/libc.so.6 > #2 0x003c52e29696 in __assert_fail () from /lib64/libc.so.6 > #3 0x2ad43a236ebe in qpid::sys::DispatchHandle::processEvent ( > this=0x104f50b8, type=qpid::sys::Poller::DISCONNECTED) > at qpid/sys/DispatchHandle.cpp:260 > #4 0x2ad43a1ecb98 in qpid::sys::Poller::run (this=0x104e8770) > at ./qpid/sys/Poller.h:123 > #5 0x2ad43a1e394a in runRunnable (p=0x398c) > at qpid/sys/posix/Thread.cpp:35 > #6 0x003c53a06367 in start_thread () from /lib64/libpthread.so.0 > #7 0x003c52ed30ad in clone () from /lib64/libc.so.6 > (gdb) frame 3 > #3 0x2ad43a236ebe in qpid::sys::DispatchHandle::processEvent ( > this=0x104f50b8, type=qpid::sys::Poller::DISCONNECTED) > at qpid/sys/DispatchHandle.cpp:260 > 260 assert(state!=CALLING); > (gdb) print state > $1 = qpid::sys::DispatchHandle::CALLING > (gdb) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2275) Time based roll over with DatePattern can result in log loss.
Time based roll over with DatePattern can result in log loss. - Key: QPID-2275 URL: https://issues.apache.org/jira/browse/QPID-2275 Project: Qpid Issue Type: Sub-task Affects Versions: M4, M3, M2.1, M2, M1 Reporter: Martin Ritchie Fix For: 0.6 When the log file rolls over it will be named according to DatePattern, it will also however rollover based on that DatePattern. So if the log fills its max size within that DatePattern the old backup file will be overwritten. FIX: a .n value should be appended to the file so that we can have log files with DatePattern '' resulting in log files 2009.0, 2009.1, 2009.2, ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2274) Async compression will result in log file deletion when used in conjunction with staticFileName
Async compression will result in log file deletion when used in conjunction with staticFileName --- Key: QPID-2274 URL: https://issues.apache.org/jira/browse/QPID-2274 Project: Qpid Issue Type: Sub-task Affects Versions: 0.5, M4, M3, M2.1, M2, M1 Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.6 Fix for this is to roll the log file first then compress it as normal. This allows the log file to be deleted and it won't impact the new log messages going in to the static log file name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[C++] QPID-1984 - 0.6 Release Blocker ?
Could QPID-1984 possibly be moved down from blocker status, raised/updated 14th July. Anyone progressing this one ? I think all of the other 5 blocker JIRAs for 0.6 are being worked on/should be blockers. Thanks, Marnie
Re: [java] Adding support for the new address format in the JMS client
Martin Ritchie wrote:
Ok, I must be in need of a break as I don't see why we can't
automatically detect and parse the formats.
We are talking about the difficulty that the JNDI destination tag will
be able to be more than one format right?
Old style:
destination.direct = direct://amq.direct//directQueue
New Style:
my-destination; {create: always, node-properties: {type: special}}
as far as I can see the two would be quite easy to distinguish.
Old is
STRING://STRING/...
New
is
STRING;...
Sorry If I'm clearly not following what is going on but could someone
explain where the difficulty in detecting the difference between the
two formats lies?
The string "direct:" is a valid node name, and the string
"/amq.direct//directQueue" is a valid subject. Putting them together
with a slash in between (name/subject) results in:
direct://amq.direct//directQueue
--Rafael
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1989) Credit window not automatically handled for unaquired subscription mode
[ https://issues.apache.org/jira/browse/QPID-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated QPID-1989: - Fix Version/s: (was: 0.6) > Credit window not automatically handled for unaquired subscription mode > --- > > Key: QPID-1989 > URL: https://issues.apache.org/jira/browse/QPID-1989 > Project: Qpid > Issue Type: Improvement > Components: C++ Client >Affects Versions: 0.5 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Minor > > If you have a subscription using ACQUIRE_MODE_NOT_ACQUIRED in conjunction > with a credit window (e.g. FlowControl::messageWindow(1)), then even with > autoAck set there is no automatic completion information sent to the broker > which means that the credit window is not moved forward and messages stop > getting delievered when the window gets used up. > This can be worked around easily enough by calling Session::sendCompleted() > (in the default COMPLETE_ON_DELIVERY mode the completion is marked, just not > sent to the broker). > However it would be more intuitive and convenient to handle this case by > sending completion at a frequency dictated by the autoAck value even if not > sending an accept (due to messages not being acquired). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2089) Messages delivered with acquire mode NOT_ACQUIRED and accept mode NONE are not correctly dequeued on acquisition
[ https://issues.apache.org/jira/browse/QPID-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-2089. -- Resolution: Fixed Fixed by r890721. > Messages delivered with acquire mode NOT_ACQUIRED and accept mode NONE are > not correctly dequeued on acquisition > > > Key: QPID-2089 > URL: https://issues.apache.org/jira/browse/QPID-2089 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.6 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2120) [race condition] asynchronous delivery and message rejection can result in out of order message deilvery
[ https://issues.apache.org/jira/browse/QPID-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790633#action_12790633 ] Rob Godfrey commented on QPID-2120: --- Code changes look ok - but we should check in perf tests whether the renaming of threads causes any issues... Previously I have seen in JProfiler that changing the thread name seems inordinately expensive :-( > [race condition] asynchronous delivery and message rejection can result in > out of order message deilvery > > > Key: QPID-2120 > URL: https://issues.apache.org/jira/browse/QPID-2120 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Martin Ritchie >Assignee: Rob Godfrey >Priority: Blocker > Fix For: 0.6 > > > The recent fixes for rollback QPID-2116 and QPID-1871 highlighted a race > condition in the broker. > When messages are rejected asynchronous delivery is started to see if any > current consumer wants the message. The 0-8 java client rejects messasges in > the following order: Prefetch then Delivered. As a result the > RollbackOrderTest#testOnMessage that receives one message then rolls back can > receive the second message ahead of the first message. > This was possible because we retrieved the node (getLastSeenNode) then later > checked if we were suspended. So with a suitable sleep in the client between > rollback and the restarting of the Channel Flow state (=true) the problem can > be seen to vanish. What was occuring was the async process retreived the last > seen (message 2) the last Reject is processed releasing Message 1. The Async > process is still attempting delivery of Message 2 when the Flow=true arrives > and so it can deliver Messasge 2. > The fix is to ensure that a suspended client cannot enter a path where it > could deliver a message. > This is safe as all Rejects will be full processed before the Flow=true is > sent so any process attempting to getLastSeenNode() must do so AFTER a > sub.isSuspended() check. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS client
Martin Ritchie wrote: Your right I probably did but also ment that if you want a Queue Object then JNDI InitialContext gives that to you. Currently if you actually want the queue to be created on the broker in a pure JMS way then createConsumer(..) is the only way to go. I think we need to support createQueue()/createTopic() for a number of reasons. First, it is part of the JMS specification, so I don't think we really have a choice. Second, there are existing usages, and I wouldn't want to discourage people from using the new format by saying it's not supported directly via createQueue()/createTopic(). Third, while the JMS specification does warn that the value passed in is vendor specific, its arguable that we don't actually care if a user wants to write code that is specific to a qpid client. Finally, the actual issue with using it is that destinations are vendor specific configuration and if you're trying to remain vendor neutral then you shouldn't hardcode vendor specific configuration into your applications, however I think there are completely reasonable usages that don't hardcode configuration, e.g. passing a specification in from the command line wouldn't make your code at all vendor specific. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2120) [race condition] asynchronous delivery and message rejection can result in out of order message deilvery
[ https://issues.apache.org/jira/browse/QPID-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved QPID-2120. --- Resolution: Fixed > [race condition] asynchronous delivery and message rejection can result in > out of order message deilvery > > > Key: QPID-2120 > URL: https://issues.apache.org/jira/browse/QPID-2120 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Martin Ritchie >Assignee: Rob Godfrey >Priority: Blocker > Fix For: 0.6 > > > The recent fixes for rollback QPID-2116 and QPID-1871 highlighted a race > condition in the broker. > When messages are rejected asynchronous delivery is started to see if any > current consumer wants the message. The 0-8 java client rejects messasges in > the following order: Prefetch then Delivered. As a result the > RollbackOrderTest#testOnMessage that receives one message then rolls back can > receive the second message ahead of the first message. > This was possible because we retrieved the node (getLastSeenNode) then later > checked if we were suspended. So with a suitable sleep in the client between > rollback and the restarting of the Channel Flow state (=true) the problem can > be seen to vanish. What was occuring was the async process retreived the last > seen (message 2) the last Reject is processed releasing Message 1. The Async > process is still attempting delivery of Message 2 when the Flow=true arrives > and so it can deliver Messasge 2. > The fix is to ensure that a suspended client cannot enter a path where it > could deliver a message. > This is safe as all Rejects will be full processed before the Flow=true is > sent so any process attempting to getLastSeenNode() must do so AFTER a > sub.isSuspended() check. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS client
2009/12/15 Rafael Schloming :
> Martin Ritchie wrote:
>>
>> 2009/12/15 Gordon Sim :
>>>
>>> On 12/15/2009 08:46 AM, Rafael Schloming wrote:
Gordon Sim wrote:
>
> On 12/15/2009 08:07 AM, Rafael Schloming wrote:
>>
>> Gordon Sim wrote:
>>>
>>> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie
wrote:
> What ever we do new JNDI, prefixing (which I find a tad strange) we
> need to support both formats simultaneously in a single file to
> allow
> users to migrate.
Mixing formats in one file seems unlikely. Wouldn't users change all
the urls in their file at once?
>>>
>>> That would be my view also.
>>>
Using different context factories for the parsing seems like the
best
solution to me. It does mean that users have to change code as well
as
configuration when switching over.
>>>
>>> I think they would only need to change code if they were passing
>>> binding urls to createQueue()/createTopic(). If they were only
>>> passing
>>> straight queue names (or topic names) then I don't think any change
>>> should be necessary to their code. Unless of course I am missing
>>> something?
>>
>> The semantics of createQueue("foo") depend on whether "foo" is
>> interpreted as an address or not. Under the current semantics this
>> would
>> automatically declare the queue on the server. If interpreted as an
>> address, you would need to supply "foo; {create: always, assert:
>> always}" in order to get equivalent semantics.
>
> Good point. However as long as users get the same semantics if they
> use the same config file from before (i.e. the old/existing context
> factory), and as long as we document this subtle shift then I think
> its acceptable to have any use of createQueue()/createTopic() revised
> when switching over to the new context factory. (Where JNDI is not
> used, a flag on the connection that determines whether the value
> passed in should be treated as a binding url or an address would work).
Are you suggesting that createQueue()/createTopic() behavior would
somehow be modified by setting the jndi context factory?
>>
>> I don't think this is something we should be doing. If users want to
>> load a JNDI value for createQueue then there are already mechanism for
>> doing that which should be used:
>>
>> createQueue((Queue)initialContext.lookup("foo"));
>
> Unless I'm missing something, there is no createQueue() that takes a Queue.
> Did you mean createConsumer((Queue)...)?
Your right I probably did but also ment that if you want a Queue
Object then JNDI InitialContext gives that to you. Currently if you
actually want the queue to be created on the broker in a pure JMS way
then createConsumer(..) is the only way to go.
Martin
> --Rafael
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>
--
Martin Ritchie
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS client
Martin Ritchie wrote:
2009/12/15 Gordon Sim :
On 12/15/2009 08:46 AM, Rafael Schloming wrote:
Gordon Sim wrote:
On 12/15/2009 08:07 AM, Rafael Schloming wrote:
Gordon Sim wrote:
On 12/15/2009 12:03 AM, Aidan Skinner wrote:
On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie
wrote:
What ever we do new JNDI, prefixing (which I find a tad strange) we
need to support both formats simultaneously in a single file to allow
users to migrate.
Mixing formats in one file seems unlikely. Wouldn't users change all
the urls in their file at once?
That would be my view also.
Using different context factories for the parsing seems like the best
solution to me. It does mean that users have to change code as well as
configuration when switching over.
I think they would only need to change code if they were passing
binding urls to createQueue()/createTopic(). If they were only passing
straight queue names (or topic names) then I don't think any change
should be necessary to their code. Unless of course I am missing
something?
The semantics of createQueue("foo") depend on whether "foo" is
interpreted as an address or not. Under the current semantics this would
automatically declare the queue on the server. If interpreted as an
address, you would need to supply "foo; {create: always, assert:
always}" in order to get equivalent semantics.
Good point. However as long as users get the same semantics if they
use the same config file from before (i.e. the old/existing context
factory), and as long as we document this subtle shift then I think
its acceptable to have any use of createQueue()/createTopic() revised
when switching over to the new context factory. (Where JNDI is not
used, a flag on the connection that determines whether the value
passed in should be treated as a binding url or an address would work).
Are you suggesting that createQueue()/createTopic() behavior would
somehow be modified by setting the jndi context factory?
I don't think this is something we should be doing. If users want to
load a JNDI value for createQueue then there are already mechanism for
doing that which should be used:
createQueue((Queue)initialContext.lookup("foo"));
Unless I'm missing something, there is no createQueue() that takes a
Queue. Did you mean createConsumer((Queue)...)?
--Rafael
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS client
2009/12/11 Rafael Schloming :
> Martin Ritchie wrote:
>>
>> 2009/12/10 Rafael Schloming :
>>>
>>> Gordon Sim wrote:
On 11/25/2009 11:06 PM, Rafael Schloming wrote:
>
> One question I have is about how we'll provide access to alternate
> syntaxes via jndi configuration and the JMS API (i.e.
> createQueue(...)/createTopic(...)). I can think of a few options, e.g.
> switching between syntaxes using a system/connection property. Or maybe
> having some sort of meta-syntax that that would permit usage of the two
> syntaxes side by side, e.g. "OLD: ...", "NEW: ...", or possibly some
> combination of the two approaches.
In the case of jndi configuration, what about having a different context
factory to do the parsing? I.e. in jndi configuration files using the
new
syntax you would specify something other than the existing
org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way
existing
configuration will work as before with no changes, and a new format can
be
parsed without any need to worry about the older format.
That doesn't deal with strings passed to createQueue()/createTopic() of
course. Perhaps there a specific 'factory' can be associated with a
connection, configured via a connection option? Where a file backed jndi
configuration is used the two different context factories could then set
different defaults for this meaning again that old config would be
unaffected and new config could ignore the old config entirely also.
Just a suggestion...
>>>
>>> I've been thinking we should just do something like:
>>>
>>> "ADDR: ..." gets parsed as an address (after removing the ADDR:)
>>> "BURL: ..." gets parsed as a binding url (after removing the BURL:)
>>>
>>> and anything not starting with ADDR: or BURL: gets parsed as one or the
>>> other according to some default that is configurable at the connection,
>>> context factory, and JVM levels.
>>>
>>> --Rafael
>>
>> Hi Rafi, do you have some examples of your grammar, my cold filled
>> head still doesn't follow why you have to start prefixing things.
>>
>> What ever we do new JNDI, prefixing (which I find a tad strange)
>> wedestination.direct = direct://amq.direct//directQueue
>> need to support both formats simultaneously in a single file to allow
>> users to migrate.
>
> If you want to support both formats simultaneously in a single file, then
> the only practical way I can think of to do that is with some sort of meta
> syntax akin to prefixing. You need some way to clearly and unambiguously
> figure out which parser to invoke, both for the sake of the implementation
> and for the sake of the people reading the file and trying to interpret the
> content.
>
> Please refer to the attached file for an updated the grammar description
> with some examples.
>
> --Rafael
>
>
> Tokens:
>
> LBRACE: r"\{"
> RBRACE: r"\}"
> COLON: r":"
>SEMI: r";"
> SLASH: r"/"
> COMMA: r","
> NUMBER: r'[+-]?[0-9]*\.?[0-9]+'
> ID: r'[a-zA-Z_](?:[a-zA-Z0-9_-]*[a-zA-Z0-9_])?'
> STRING: r(?:[^\\"]|\\.)*"|'(?:[^\\']|\\.)*'"""
> ESC:
> r"\\[^ux]|\\x[0-9a-fA-F][0-9a-fA-F]|\\u[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]"
> SYM: r"[@$^!+-]"
> WSPACE: r"[ \n\r\t]+"
> EOF:
>
> Grammar:
>
> address = name [ "/" subject ] [ ";" options ]
> name = ( part | quoted )+
> subject = ( part | quoted | "/" )*
> quoted = STRING / ESC
> part = LBRACE / RBRACE / COLON / COMMA / NUMBER / ID / SYM
> options = map
> map = "{" ( keyval ( "," keyval )* )? "}"
> keyval = ID ":" value
>value = NUMBER / STRING / ID / map / list
> list = "[" ( value ( "," value )* )? "]"
>
> Semantics:
>
> An address identifies a source or target for messages. In its
> simplest form this is just a name. In general a target address may
> also be used as a source address, however not all source addresses
> may be used as a target, e.g. a source might additionally have some
> filtering criteria that would not be present in a target.
>
> A subject may optionally be specified along with the name. When an
> address is used as a target, any subject specified in the address is
> used as the default subject of outgoing messages for that target.
> When an address is used as a source, any subject specified in the
> address is pattern matched against the subject of available messages
> as a filter for incoming messages from that source.
>
> The options map contains additional information about the address
> including:
>
>- policies for automatically creating, and deleting the node to
> which an address refers
>
>- policies for asserting facts about the node to which an address
> refers
>
>- extension points that can be used for sender/receiver
> configuration
>
> Mapping to 0-10 semantics:
>
> The name is resolved to either an exchange or a queue by querying
> the broker.
>
> The subject is set a
