Re: RFC: Does a jboss deployer go into the qpid source tree
On Wed, Jun 24, 2009 at 3:51 AM, Bryan Kearney bkear...@redhat.com wrote: I would be fine with that.. it would require having the jboss code to do the build, but as long as it is optional I would think it would be ok. How about putting it in qpid/java/contrib/containers/jboss ? - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire
[jira] Created: (QPID-1941) moved messages remain listed on original queue when viewing messages using JMX, but are not actually considered to still be on the queue
moved messages remain listed on original queue when viewing messages using JMX, but are not actually considered to still be on the queue Key: QPID-1941 URL: https://issues.apache.org/jira/browse/QPID-1941 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Robbie Gemmell Fix For: 0.6 When moving messages from one queue to another using the JMX interfaces, the messages moved remain listed in the viewMessage(from, to) results of the original queue, despite the message count being decremented and the deleteFromTop() and clearQueue() methods not acting on them as they are actually no longer considered part of the queue. As such, someone attempting to 'delete from top' may not be deleting the message they are expecting, if it has previously been moved. Steps to reproduce: Start broker. Start JMS Direct Consumer example. Stop JMS Direct Consumer example. Start JMS Direct Producer example, resulting in 11 messages being left on the queue 'message_queue' on the 'test' virtualhost. Using JMX (via RCP management console, or JConsole), view messages 1 to 11 on 'message' queue, which will return 11 messages as expected. Now move messages 1 to 5 to queue 'ping'. The attributes for 'message_queue' now indicate it contains 6 messages, and 'ping' contains 5, as expected. However, viewing messages 1 to 11 on 'message_queue' again returns all 11 messages when it should only return messages with AMQ ID 6 to 11. Using the DeleteFromTop operation deletes message with AMQ ID 6, which can be verified by viewing messages 1 to 11 and discovering 6 is no longer present. Clearing 'message_queue' at this point removes messages with AMQ ID 7-11 as would normally be expected. However, viewing messages 1 to 11 on 'message_queue' again returns messages with AMQ ID 1 to 5 which it should not. -- 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-1941) moved messages remain listed on original queue when viewing messages using JMX, but are not actually considered to still be on the queue
[ https://issues.apache.org/jira/browse/QPID-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-1941: - Description: Using trunk r787701 When moving messages from one queue to another using the JMX interfaces, the messages moved remain listed in the viewMessage(from, to) results of the original queue, despite the message count being decremented and the deleteFromTop() and clearQueue() methods not acting on them as they are actually no longer considered part of the queue. As such, someone attempting to 'delete from top' may not be deleting the message they are expecting, if it has previously been moved. Steps to reproduce: Start broker. Start JMS Direct Consumer example. Stop JMS Direct Consumer example. Start JMS Direct Producer example, resulting in 11 messages being left on the queue 'message_queue' on the 'test' virtualhost. Using JMX (via RCP management console, or JConsole), view messages 1 to 11 on 'message' queue, which will return 11 messages as expected. Now move messages 1 to 5 to queue 'ping'. The attributes for 'message_queue' now indicate it contains 6 messages, and 'ping' contains 5, as expected. However, viewing messages 1 to 11 on 'message_queue' again returns all 11 messages when it should only return messages with AMQ ID 6 to 11. Using the DeleteFromTop operation deletes message with AMQ ID 6, which can be verified by viewing messages 1 to 11 and discovering 6 is no longer present. Clearing 'message_queue' at this point removes messages with AMQ ID 7-11 as would normally be expected. However, viewing messages 1 to 11 on 'message_queue' again returns messages with AMQ ID 1 to 5 which it should not. was: When moving messages from one queue to another using the JMX interfaces, the messages moved remain listed in the viewMessage(from, to) results of the original queue, despite the message count being decremented and the deleteFromTop() and clearQueue() methods not acting on them as they are actually no longer considered part of the queue. As such, someone attempting to 'delete from top' may not be deleting the message they are expecting, if it has previously been moved. Steps to reproduce: Start broker. Start JMS Direct Consumer example. Stop JMS Direct Consumer example. Start JMS Direct Producer example, resulting in 11 messages being left on the queue 'message_queue' on the 'test' virtualhost. Using JMX (via RCP management console, or JConsole), view messages 1 to 11 on 'message' queue, which will return 11 messages as expected. Now move messages 1 to 5 to queue 'ping'. The attributes for 'message_queue' now indicate it contains 6 messages, and 'ping' contains 5, as expected. However, viewing messages 1 to 11 on 'message_queue' again returns all 11 messages when it should only return messages with AMQ ID 6 to 11. Using the DeleteFromTop operation deletes message with AMQ ID 6, which can be verified by viewing messages 1 to 11 and discovering 6 is no longer present. Clearing 'message_queue' at this point removes messages with AMQ ID 7-11 as would normally be expected. However, viewing messages 1 to 11 on 'message_queue' again returns messages with AMQ ID 1 to 5 which it should not. moved messages remain listed on original queue when viewing messages using JMX, but are not actually considered to still be on the queue Key: QPID-1941 URL: https://issues.apache.org/jira/browse/QPID-1941 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Robbie Gemmell Fix For: 0.6 Using trunk r787701 When moving messages from one queue to another using the JMX interfaces, the messages moved remain listed in the viewMessage(from, to) results of the original queue, despite the message count being decremented and the deleteFromTop() and clearQueue() methods not acting on them as they are actually no longer considered part of the queue. As such, someone attempting to 'delete from top' may not be deleting the message they are expecting, if it has previously been moved. Steps to reproduce: Start broker. Start JMS Direct Consumer example. Stop JMS Direct Consumer example. Start JMS Direct Producer example, resulting in 11 messages being left on the queue 'message_queue' on the 'test' virtualhost. Using JMX (via RCP management console, or JConsole), view messages 1 to 11 on 'message' queue, which will return 11 messages as expected. Now move messages 1 to 5 to queue 'ping'. The attributes for 'message_queue' now indicate it contains 6 messages, and 'ping' contains 5, as expected. However, viewing messages 1 to 11 on 'message_queue' again returns all 11 messages when it should only return messages with
[jira] Updated: (QPID-1941) moved messages remain listed on original queue when viewing messages using JMX, but are not actually considered to still be on the queue
[ https://issues.apache.org/jira/browse/QPID-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-1941: - Description: Using trunk r787701 When moving messages from one queue to another using the JMX interfaces, the messages moved remain listed in the viewMessage(from, to) results of the original queue, despite the message count being decremented and the deleteFromTop() and clearQueue() methods not acting on them as they are actually no longer considered part of the queue. As such, someone attempting to 'delete from top' may not be deleting the message they are expecting, if it has previously been moved. Steps to reproduce: Start broker. Start JMS Direct Consumer example. Stop JMS Direct Consumer example. Start JMS Direct Producer example, resulting in 11 messages being left on the queue 'message_queue' on the 'test' virtualhost. Using JMX (via RCP management console, or JConsole), view messages 1 to 11 on 'message_queue', which will return 11 messages as expected. Now move messages 1 to 5 to queue 'ping'. The attributes for 'message_queue' now indicate it contains 6 messages, and 'ping' contains 5, as expected. However, viewing messages 1 to 11 on 'message_queue' again returns all 11 messages when it should only return messages with AMQ ID 6 to 11. Using the DeleteFromTop operation deletes message with AMQ ID 6, which can be verified by viewing messages 1 to 11 and discovering 6 is no longer present. Clearing 'message_queue' at this point removes messages with AMQ ID 7-11 as would normally be expected. However, viewing messages 1 to 11 on 'message_queue' again returns messages with AMQ ID 1 to 5 which it should not. was: Using trunk r787701 When moving messages from one queue to another using the JMX interfaces, the messages moved remain listed in the viewMessage(from, to) results of the original queue, despite the message count being decremented and the deleteFromTop() and clearQueue() methods not acting on them as they are actually no longer considered part of the queue. As such, someone attempting to 'delete from top' may not be deleting the message they are expecting, if it has previously been moved. Steps to reproduce: Start broker. Start JMS Direct Consumer example. Stop JMS Direct Consumer example. Start JMS Direct Producer example, resulting in 11 messages being left on the queue 'message_queue' on the 'test' virtualhost. Using JMX (via RCP management console, or JConsole), view messages 1 to 11 on 'message' queue, which will return 11 messages as expected. Now move messages 1 to 5 to queue 'ping'. The attributes for 'message_queue' now indicate it contains 6 messages, and 'ping' contains 5, as expected. However, viewing messages 1 to 11 on 'message_queue' again returns all 11 messages when it should only return messages with AMQ ID 6 to 11. Using the DeleteFromTop operation deletes message with AMQ ID 6, which can be verified by viewing messages 1 to 11 and discovering 6 is no longer present. Clearing 'message_queue' at this point removes messages with AMQ ID 7-11 as would normally be expected. However, viewing messages 1 to 11 on 'message_queue' again returns messages with AMQ ID 1 to 5 which it should not. moved messages remain listed on original queue when viewing messages using JMX, but are not actually considered to still be on the queue Key: QPID-1941 URL: https://issues.apache.org/jira/browse/QPID-1941 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Robbie Gemmell Fix For: 0.6 Using trunk r787701 When moving messages from one queue to another using the JMX interfaces, the messages moved remain listed in the viewMessage(from, to) results of the original queue, despite the message count being decremented and the deleteFromTop() and clearQueue() methods not acting on them as they are actually no longer considered part of the queue. As such, someone attempting to 'delete from top' may not be deleting the message they are expecting, if it has previously been moved. Steps to reproduce: Start broker. Start JMS Direct Consumer example. Stop JMS Direct Consumer example. Start JMS Direct Producer example, resulting in 11 messages being left on the queue 'message_queue' on the 'test' virtualhost. Using JMX (via RCP management console, or JConsole), view messages 1 to 11 on 'message_queue', which will return 11 messages as expected. Now move messages 1 to 5 to queue 'ping'. The attributes for 'message_queue' now indicate it contains 6 messages, and 'ping' contains 5, as expected. However, viewing messages 1 to 11 on 'message_queue' again returns all 11 messages when it should only
[jira] Created: (QPID-1944) create a new view for the Connection mbeans
create a new view for the Connection mbeans --- Key: QPID-1944 URL: https://issues.apache.org/jira/browse/QPID-1944 Project: Qpid Issue Type: Sub-task Components: Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Robbie Gemmell -- 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-1942) create a new queue / exchange / connection selection view
create a new queue / exchange / connection selection view - Key: QPID-1942 URL: https://issues.apache.org/jira/browse/QPID-1942 Project: Qpid Issue Type: Sub-task Components: Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Robbie Gemmell create a new queue / exchange / connection selection view, allowing users to directly open queues etc without adding them to the navigation tree first, and showing any additional attribute information in a more obvious manner, eg in a table. -- 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-1943) create a new view for the Exchange mbeans
create a new view for the Exchange mbeans - Key: QPID-1943 URL: https://issues.apache.org/jira/browse/QPID-1943 Project: Qpid Issue Type: Sub-task Components: Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Robbie Gemmell -- 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-1945) create a new view for the VirtualHostManager mbeans
create a new view for the VirtualHostManager mbeans --- Key: QPID-1945 URL: https://issues.apache.org/jira/browse/QPID-1945 Project: Qpid Issue Type: Sub-task Components: Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Robbie Gemmell -- 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-1946) add an mbean to present system information, including API versioning for the JMX interface
add an mbean to present system information, including API versioning for the JMX interface -- Key: QPID-1946 URL: https://issues.apache.org/jira/browse/QPID-1946 Project: Qpid Issue Type: Sub-task Components: Java Broker, Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Robbie Gemmell -- 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-1947) enable automated update to negate need for users to manually refresh the data
enable automated update to negate need for users to manually refresh the data - Key: QPID-1947 URL: https://issues.apache.org/jira/browse/QPID-1947 Project: Qpid Issue Type: Sub-task Components: Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Robbie Gemmell -- 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: [GSoC] Queue MBean viewMessages + viewMessageContent operations
On Tue, Jun 23, 2009 at 8:07 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote: That's what I was thinking after I realised how it was actually doing things, though you might struggle to understand that from my first email as I noticed that there are a few key words missing while I was deleting it to send this...(which took a while on the phone:p) Given that there isn't, AFAIK, any inherent limitation in the broker on max queue size I'm a little hesitant to pass up this opportunity to fix it properly and use Long. Other bits of the API are equally short sighted, but at the end of the day SimpleQueueEntryList is your classic linked list which can scale beyond 2^31. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire
Re: [GSoC] JMX MC UI progress update / initial implementation work / request for thoughts
On Tue, Jun 23, 2009 at 12:19 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote: I have put up my progress in in a branch at /branches/jmx_mc_gsoc09 ( https://svn.apache.org/repos/asf/qpid/branches/jmx_mc_gsoc09). This includes initial versions for some areas of the new UI, namely: UserMangement, LoggingManagement, and the view for individual Queue's. Nice. :) There is still some layout work to do on it, and as yet the result of operations is not explicitly reported (but in several cases, is immediately visible), mainly because i havent decided on the format: the traditional info/error dialog with ok button works, but a status bar report area might be a less intrusive/clicky solution. I like the status bar approach and visible updates. I'd only raise a dialouge if there's been an error. It's probably worth documenting UI conventions as you go so that it remains consistent. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire
Re: [GSoC] Queue MBean viewMessages + viewMessageContent operations
Ok, ill add it to the end of the todo list. It needs changes to the queue and mbean methods to work, and the API versioning to put it in the console. Also, upon inspection the resultant TabularData sets also appear to only hold 2^31 messages, so short of implementing a Qpid specific list and requiring JConsole etc users make that class available to use the results, viewMessages(from, to) would still need be limited to viewing at most 2^31 at a time...just any 2^31 instead of the first 2^31 as at present. 2009/6/24 Aidan Skinner aidan.skin...@gmail.com On Tue, Jun 23, 2009 at 8:07 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: That's what I was thinking after I realised how it was actually doing things, though you might struggle to understand that from my first email as I noticed that there are a few key words missing while I was deleting it to send this...(which took a while on the phone:p) Given that there isn't, AFAIK, any inherent limitation in the broker on max queue size I'm a little hesitant to pass up this opportunity to fix it properly and use Long. Other bits of the API are equally short sighted, but at the end of the day SimpleQueueEntryList is your classic linked list which can scale beyond 2^31. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire
Re: [GSoC] Queue MBean viewMessages + viewMessageContent operations
On Wed, Jun 24, 2009 at 11:24 AM, Robbie Gemmellrobbie.gemm...@gmail.com wrote: requiring JConsole etc users make that class available to use the results, viewMessages(from, to) would still need be limited to viewing at most 2^31 at a time...just any 2^31 instead of the first 2^31 as at present. Cool, that's much better - they can get to the end of the queue if they need too. - 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
Re: [GSoC] JMX MC UI progress update / initial implementation work / request for thoughts
2009/6/24 Aidan Skinner aidan.skin...@gmail.com There is still some layout work to do on it, and as yet the result of operations is not explicitly reported (but in several cases, is immediately visible), mainly because i havent decided on the format: the traditional info/error dialog with ok button works, but a status bar report area might be a less intrusive/clicky solution. I like the status bar approach and visible updates. I'd only raise a dialouge if there's been an error. It's probably worth documenting UI conventions as you go so that it remains consistent. Will do, its fairly simple so far though: Most 'viewing' operations are performed implicitly in the UI to present the initial info, eg loggers, user, message lists, which are sortable. Additional operations are grouped according to relevance, either linked to the tables or seperately. If there is only one operation on a set of presented data, users can either use the provided button or double click an entry in the table. If there are multiple operations on presented data, only the buttons will initiate the invocation. Any operation that modify visible data cause all the currently presented data to be updated following execution. So far, the only operations that doesnt apply for are 'View Selected Message' after selecting a message in the table, and 'Set Password' for a selected user password. Also, once implemented, all presented info will be updated automatically at a desired interval regardless of additional method invocation. All non-viewing operations present an ok/cancel opportunity, whether there is need to request input(which it does at the time) or not. Robbie
[jira] Updated: (QPID-1948) Chnages to the java consle as a result of a code generated front end.
[ https://issues.apache.org/jira/browse/QPID-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Kearney updated QPID-1948: Attachment: codeGen.patch Run from the qpid directory. Chnages to the java consle as a result of a code generated front end. - Key: QPID-1948 URL: https://issues.apache.org/jira/browse/QPID-1948 Project: Qpid Issue Type: Improvement Reporter: Bryan Kearney Attachments: codeGen.patch Changes for code generation. This includes a method which still had csharp formatting, and some bug fixes in the parsing of classkeys. Even a new test class is added! -- 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-1948) Chnages to the java consle as a result of a code generated front end.
Chnages to the java consle as a result of a code generated front end. - Key: QPID-1948 URL: https://issues.apache.org/jira/browse/QPID-1948 Project: Qpid Issue Type: Improvement Reporter: Bryan Kearney Attachments: codeGen.patch Changes for code generation. This includes a method which still had csharp formatting, and some bug fixes in the parsing of classkeys. Even a new test class is added! -- 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-1948) Chnages to the java consle as a result of a code generated front end.
[ https://issues.apache.org/jira/browse/QPID-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-1948: -- Assignee: Ted Ross Chnages to the java consle as a result of a code generated front end. - Key: QPID-1948 URL: https://issues.apache.org/jira/browse/QPID-1948 Project: Qpid Issue Type: Improvement Reporter: Bryan Kearney Assignee: Ted Ross Attachments: codeGen.patch Changes for code generation. This includes a method which still had csharp formatting, and some bug fixes in the parsing of classkeys. Even a new test class is added! -- 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: RFC: Does a jboss deployer go into the qpid source tree
Bryan, If JBoss code is needed for building then it might be an issue as JBoss is using LGPL. Any libraries that are checked into the lib dir in the project has to have a compatible license. An alternative would be to use some form of abstraction with reflection. This prevents the need for having JBoss libraries at compile time. I used a similar strategy to support Realtime Java constructs. Regards, Rajith On Tue, Jun 23, 2009 at 10:51 PM, Bryan Kearneybkear...@redhat.com wrote: Carl Trieloff wrote: I expect people might create deployers for other containers like spring, websphere etc. So I would think we create a directory for each as they are created under the Java directory, and make it optional to build them my 2 cents Carl. I would be fine with that.. it would require having the jboss code to do the build, but as long as it is optional I would think it would be ok. -- bk - 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
RFC: Maven and the Java Build
I am looking for the comments from the Java developers. I have been working on some QMF bits, and I am interested in having maven artifacts for consuming the clients bits. In speaking with some of the developers, there is a strong desire to not move the build system to maven given the issues with the tool, and the impact it would have on build system. So.. I would like to solicit thoughts from folks. 1) Do you have a desire/need for maven artifacts for the Java bits? If so, which java bits? 2) Have you seen good examples of how to manage pom files as well as dependencies in the ant or standard build system. One bug was put forward with an attempt to do this: https://issues.apache.org/jira/browse/QPID-1916 but this suffers from being very non-DRY. Dependencies are done both in the pom file and the build.deps file. My hope is that answers to (2) can provide a better way to resolve this issue. Thanks! -- bk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: RFC: Does a jboss deployer go into the qpid source tree
Rajith Attapattu wrote: Bryan, If JBoss code is needed for building then it might be an issue as JBoss is using LGPL. Any libraries that are checked into the lib dir in the project has to have a compatible license. An alternative would be to use some form of abstraction with reflection. This prevents the need for having JBoss libraries at compile time. I used a similar strategy to support Realtime Java constructs. Regards, Rajith Rajith: Thanks for the feedback. I was assuming a model where to build the contrib stuff the developer would need to download additional bits. Would that alleviate the issue? Or just add new issues? -- bk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: RFC: Maven and the Java Build
On Wed, Jun 24, 2009 at 3:28 PM, Bryan Kearneybkear...@redhat.com wrote: So.. I would like to solicit thoughts from folks. 1) Do you have a desire/need for maven artifacts for the Java bits? If so, which java bits? 2) Have you seen good examples of how to manage pom files as well as dependencies in the ant or standard build system. I've been looking into using ivy to manage or deps for this purpouse. It can produce proper poms automagically, which is quite neat. The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. - 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
Re: RFC: Maven and the Java Build
Aidan Skinner wrote: On Wed, Jun 24, 2009 at 3:28 PM, Bryan Kearneybkear...@redhat.com wrote: So.. I would like to solicit thoughts from folks. 1) Do you have a desire/need for maven artifacts for the Java bits? If so, which java bits? 2) Have you seen good examples of how to manage pom files as well as dependencies in the ant or standard build system. I've been looking into using ivy to manage or deps for this purpouse. It can produce proper poms automagically, which is quite neat. I have not used it, but I have heard good things about it. The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. Why is it bad to use the maven repos instead of copying things from java/lib? -- bk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: RFC: Maven and the Java Build
On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearneybkear...@redhat.com wrote: The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. Why is it bad to use the maven repos instead of copying things from java/lib? It makes reproducible builds hard/impossible and doesn't play well with package systems. - 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
Re: svn commit: r774899 - in /qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid: client/AMQConnection.java jms/failover/FailoverRoundRobinServers.java jms/failover/FailoverSingleServer.java
Hi Rajith,
Why did you set the default retries to 0 as well as starting the
_currentRetries from 0? I thought the original problem was that it
would always try twice with this commit we effectively reduced the
retries by 2. Do you have time to write a test to ensure that
FailoverSingleServer only retires once not twice :)
/** The default number of times to rety a conection to this server */
-public static final int DEFAULT_SERVER_RETRIES = 1;
+public static final int DEFAULT_SERVER_RETRIES = 0;
This commit has resulted in the SingleServerFailover not working.
When I make my connection failover I get :
main 2009-06-24 16:21:45,105 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Session closed called with
failover state currently FailoverState: NOT STARTED
main 2009-06-24 16:21:45,105 DEBUG [apache.qpid.jms.FailoverPolicy]
All failover methods exhausted
main 2009-06-24 16:21:45,106 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Failover not allowed by
policy.
main 2009-06-24 16:21:45,106 DEBUG [apache.qpid.jms.FailoverPolicy]
All failover methods exhausted
main 2009-06-24 16:21:45,106 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Failover Policy:
Failover not allowed
Failover policy methods
Single Server:
Max Retries:0
Current Retry:0
tcp://localhost:5672
As the current retry is 0 and the Max is 0 then failover doesn't occur.
Am I missing something?
Cheers
Martin
2009/5/14 raj...@apache.org:
Author: rajith
Date: Thu May 14 19:50:23 2009
New Revision: 774899
URL: http://svn.apache.org/viewvc?rev=774899view=rev
Log:
This is a fix for QPID-1859
For FailoverSingleServer the default for retries is set to 0 and the
current_retries start from 0 instead of -1.
For FailoverRoundRobinServers the current_broker_index now starts from 0
instead of -1.
The AMQConnection now uses the getCurrentBrokerDetails() instead of the
getNextBrokerDetails() to get the initial broker to connect.
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverSingleServer.java
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java?rev=774899r1=774898r2=774899view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
Thu May 14 19:50:23 2009
@@ -455,7 +455,7 @@
}
_failoverPolicy = new FailoverPolicy(connectionURL, this);
-BrokerDetails brokerDetails = _failoverPolicy.getNextBrokerDetails();
+BrokerDetails brokerDetails =
_failoverPolicy.getCurrentBrokerDetails();
if (brokerDetails.getTransport().equals(BrokerDetails.VM))
{
_delegate = new AMQConnectionDelegate_8_0(this);
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java?rev=774899r1=774898r2=774899view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
Thu May 14 19:50:23 2009
@@ -35,19 +35,19 @@
public static final int DEFAULT_SERVER_RETRIES = 0;
/** The index into the hostDetails array of the broker to which we are
connected */
-private int _currentBrokerIndex = -1;
+private int _currentBrokerIndex = 0;
/** The number of times to retry connecting for each server */
private int _serverRetries;
/** The current number of retry attempts made */
-private int _currentServerRetry;
+private int _currentServerRetry = 0;
/** The number of times to cycle through the servers */
private int _cycleRetries;
/** The current number of cycles performed. */
-private int _currentCycleRetries;
+private int _currentCycleRetries = 0;
/** Array of BrokerDetail used to make connections. */
protected ConnectionURL _connectionDetails;
@@ -62,7 +62,7 @@
_connectionDetails = connectionDetails;
// There is no current broker at startup so set it to -1.
-_currentBrokerIndex = -1;
+_currentBrokerIndex = 0;
String cycleRetries =
[jira] Created: (QPID-1949) Client does not ensure connection is closed before attempting failover
Client does not ensure connection is closed before attempting failover -- Key: QPID-1949 URL: https://issues.apache.org/jira/browse/QPID-1949 Project: Qpid Issue Type: Bug Affects Versions: M4, 0.5 Reporter: Martin Ritchie * Summary: * A user has reported message loss from their application. On bouncing of * the broker the 'lost' messages are delivered to the broker. * * Note: * The client was using Spring so that may influence the situation. * * Issue: * The log files show 7 instances of the following which result in 7 * missing messages. * * The client log files show: * * The broker log file show: * * * 7 missing messages have delivery tags 5-11. Which says that they are * sequentially the next message from the broker. * * The only way for the 'without a handler' log to occur is if the consumer * has been removed from the look up table of the dispatcher. * And the only way for the 'null message' log to occur on the broker is is * if the message does not exist in the unacked-map * * The consumer is only removed from the list during session * closure and failover. * * If the session was closed then the broker would requeue the unacked * messages so the potential exists to have an empty map but the broker * will not send a message out after the unacked map has been cleared. * * When failover occurs the _consumer map is cleared and the consumers are * resubscribed. This is down without first stopping any existing * dispatcher so there exists the potential to receive a message after * the _consumer map has been cleared which is how the 'without a handler' * log statement occurs. * * Scenario: * * Looking over logs the sequence that best fits the events is as follows: * - Something causes Mina to be delayed causing the WriteTimoutException. * - This exception is recevied by AMQProtocolHandler#exceptionCaught * - As the WriteTimeoutException is an IOException this will cause * sessionClosed to be called to start failover. * + This is potentially the issues here. All IOExceptions are treated * as connection failure events. * - Failover Runs * + Failover assumes that the previous connection has been closed. * + Failover binds the existing objects (AMQConnection/Session) to the * new connection objects. * - Everything is reported as being successfully failed over. * However, what is neglected is that the original connection has not * been closed. * + So what occurs is that the broker sends a message to the consumer on * the original connection, as it was not notified of the client * failing over. * As the client failover reuses the original AMQSession and Dispatcher * the new messages the broker sends to the old consumer arrives at the * client and is processed by the same AMQSession and Dispatcher. * However, as the failover process cleared the _consumer map and * resubscribe the consumers the Dispatcher does not recognise the * delivery tag and so logs the 'without a handler' message. * - The Dispatcher then attempts to reject the message, however, * + The AMQSession/Dispatcher pair have been swapped to using a new Mina * ProtocolSession as part of the failover process so the reject is * sent down the second connection. The broker receives the Reject * request but as the Message was sent on a different connection the * unacknowledgemap is empty and a 'message is null' log message * produced. * * Test Strategy: * * It should be easy to demonstrate if we can send an IOException to * AMQProtocolHandler#exceptionCaught and then try sending a message. -- 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++: client request memory leak on windows
Hi,
I'm experiencing a memory leak when using the client library on Windows (0.5 release) when
sending a single request. From what debugging I've done so far it looks like the The AsynchIO object
used by the TCPConnector is not being deleted. When the connection is being closed
aio-queueForDeletion() is called from TCPConnector::closeInternal().. However in
AsynchIO::queueForDeletion() aio.opsInProgress 0 so the 'delete this' branch is not done. There
are no more queueForDeletion() calls made on the aio object (after opsInProgress is 0) and so it
never gets deleted. The ConnectionImpl object involved is not cleaned up either, the shared_ptr to
it has a non-zero ref count but I'm guessing it's related to the AsynchIO object not being cleaned up.
There used to be some code in AsynchIO::completion() that seems like it would do the necessary
delete. It was removed with code changes in https://issues.apache.org/jira/browse/QPID-1550
The extra handling in completion() was as follows..
-// Lock released; ok to delete if all is done.
-if (opsInProgress == 0 queuedDelete)
-delete this;
Should that code be re-introduced (I don't know the history nor the 'big picture'), or could this be
due to my usage ? My reproduction code is as follows.. The CRT memory leak report gets printed when
the test program exits, that's what lead me to aio allocation that isn't being freed.
#define _CRTDBG_MAP_ALLOC
#include cstdlib
#include crtdbg.h
#include qpid/client/Connection.h
#include qpid/client/Session.h
#include qpid/client/Message.h
#include qpid/client/SubscriptionManager.h
#include qpid/sys/Time.h
#include iostream
using namespace qpid::client;
using namespace qpid::framing;
using qpid::sys::TIME_SEC;
int main(int argc, char **argv)
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG | _CRTDBG_MODE_WNDW);
Connection connection;
Message response;
try
{
//qpid::TcpAddress::DEFAULT_PORT
connection.open(10.39.170.224);
Session session = connection.newSession();
// Create a response queue using the client's session id as the name of
// the response queue
string responseQueue = x.client + session.getId().getName();
// Use the name of the response queue as the routing key as well
session.queueDeclare(arg::queue=responseQueue);
session.exchangeBind(arg::exchange=amq.direct,
arg::queue=responseQueue, arg::bindingKey=responseQueue);
// Setup a message using our response queue so the
// the service knows where to route response messages.
Message req;
DeliveryProperties deliveryProps = req.getDeliveryProperties();
deliveryProps.setRoutingKey(x.request);
MessageProperties messageProps = req.getMessageProperties();
messageProps.setReplyTo(ReplyTo(amq.direct, responseQueue));
session.messageTransfer(arg::content=req, arg::destination=amq.direct,
arg::acceptMode=0);
// Create a listener for the response queue and listen for response
messages.
SubscriptionManager subsManager(session);
if(!subsManager.get(response, responseQueue, TIME_SEC))
std::cout Timed out waiting for a response std::endl;
}
catch(const std::exception error)
{
std::cout exception thrown.. std::endl
error.what() std::endl;
}
return 0;
}
- David
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1950) During failover clients can cause NPE to occur on the broker.
During failover clients can cause NPE to occur on the broker. - Key: QPID-1950 URL: https://issues.apache.org/jira/browse/QPID-1950 Project: Qpid Issue Type: Bug Components: Java Broker, Java Client Affects Versions: M4, 0.5 Reporter: Martin Ritchie Summary: During failover NPEs have been seen from the ChannelOpenHandler as the virtualHost has not yet been set on the session. The Java client should not be able to cause this sort of problem. This was discovered whilst testing another issue wifh failover. QPID-1949 The race condition can be seen by editing the test case (as attached) so that it attempts to continue to use the connection after failover. The attached log shows one instance where the NPE occured. -- 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-1949) Client does not ensure connection is closed before attempting failover
[ https://issues.apache.org/jira/browse/QPID-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1949: - Component/s: Java Broker Client does not ensure connection is closed before attempting failover -- Key: QPID-1949 URL: https://issues.apache.org/jira/browse/QPID-1949 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: M4, 0.5 Reporter: Martin Ritchie * Summary: * A user has reported message loss from their application. On bouncing of * the broker the 'lost' messages are delivered to the broker. * * Note: * The client was using Spring so that may influence the situation. * * Issue: * The log files show 7 instances of the following which result in 7 * missing messages. * * The client log files show: * * The broker log file show: * * * 7 missing messages have delivery tags 5-11. Which says that they are * sequentially the next message from the broker. * * The only way for the 'without a handler' log to occur is if the consumer * has been removed from the look up table of the dispatcher. * And the only way for the 'null message' log to occur on the broker is is * if the message does not exist in the unacked-map * * The consumer is only removed from the list during session * closure and failover. * * If the session was closed then the broker would requeue the unacked * messages so the potential exists to have an empty map but the broker * will not send a message out after the unacked map has been cleared. * * When failover occurs the _consumer map is cleared and the consumers are * resubscribed. This is down without first stopping any existing * dispatcher so there exists the potential to receive a message after * the _consumer map has been cleared which is how the 'without a handler' * log statement occurs. * * Scenario: * * Looking over logs the sequence that best fits the events is as follows: * - Something causes Mina to be delayed causing the WriteTimoutException. * - This exception is recevied by AMQProtocolHandler#exceptionCaught * - As the WriteTimeoutException is an IOException this will cause * sessionClosed to be called to start failover. * + This is potentially the issues here. All IOExceptions are treated * as connection failure events. * - Failover Runs * + Failover assumes that the previous connection has been closed. * + Failover binds the existing objects (AMQConnection/Session) to the * new connection objects. * - Everything is reported as being successfully failed over. * However, what is neglected is that the original connection has not * been closed. * + So what occurs is that the broker sends a message to the consumer on * the original connection, as it was not notified of the client * failing over. * As the client failover reuses the original AMQSession and Dispatcher * the new messages the broker sends to the old consumer arrives at the * client and is processed by the same AMQSession and Dispatcher. * However, as the failover process cleared the _consumer map and * resubscribe the consumers the Dispatcher does not recognise the * delivery tag and so logs the 'without a handler' message. * - The Dispatcher then attempts to reject the message, however, * + The AMQSession/Dispatcher pair have been swapped to using a new Mina * ProtocolSession as part of the failover process so the reject is * sent down the second connection. The broker receives the Reject * request but as the Message was sent on a different connection the * unacknowledgemap is empty and a 'message is null' log message * produced. * * Test Strategy: * * It should be easy to demonstrate if we can send an IOException to * AMQProtocolHandler#exceptionCaught and then try sending a message. -- 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-1950) During failover clients can cause NPE to occur on the broker.
[ https://issues.apache.org/jira/browse/QPID-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1950: - Attachment: QPID-1950.log During failover clients can cause NPE to occur on the broker. - Key: QPID-1950 URL: https://issues.apache.org/jira/browse/QPID-1950 Project: Qpid Issue Type: Bug Components: Java Broker, Java Client Affects Versions: M4, 0.5 Reporter: Martin Ritchie Attachments: QPID-1950.log Summary: During failover NPEs have been seen from the ChannelOpenHandler as the virtualHost has not yet been set on the session. The Java client should not be able to cause this sort of problem. This was discovered whilst testing another issue wifh failover. QPID-1949 The race condition can be seen by editing the test case (as attached) so that it attempts to continue to use the connection after failover. The attached log shows one instance where the NPE occured. -- 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: svn commit: r774899 - in /qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid: client/AMQConnection.java jms/failover/FailoverRoundRobinServers.java jms/failover/FailoverSingleServer.java
Martin,
When we discussed this issue we agreed that by default the
SingleFailoverMethod should not retry at all.
So in order to make the initial connection attempt work, we made
AMQConnection use getCurrentBrokerDetails() instead of the
getNextBrokerDetails() to get the initial broker to connect.
Regards,
Rajith
On Wed, Jun 24, 2009 at 11:27 AM, Martin Ritchieritch...@apache.org wrote:
Hi Rajith,
Why did you set the default retries to 0 as well as starting the
_currentRetries from 0? I thought the original problem was that it
would always try twice with this commit we effectively reduced the
retries by 2. Do you have time to write a test to ensure that
FailoverSingleServer only retires once not twice :)
/** The default number of times to rety a conection to this server */
-public static final int DEFAULT_SERVER_RETRIES = 1;
+public static final int DEFAULT_SERVER_RETRIES = 0;
This commit has resulted in the SingleServerFailover not working.
When I make my connection failover I get :
main 2009-06-24 16:21:45,105 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Session closed called with
failover state currently FailoverState: NOT STARTED
main 2009-06-24 16:21:45,105 DEBUG [apache.qpid.jms.FailoverPolicy]
All failover methods exhausted
main 2009-06-24 16:21:45,106 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Failover not allowed by
policy.
main 2009-06-24 16:21:45,106 DEBUG [apache.qpid.jms.FailoverPolicy]
All failover methods exhausted
main 2009-06-24 16:21:45,106 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Failover Policy:
Failover not allowed
Failover policy methods
Single Server:
Max Retries:0
Current Retry:0
tcp://localhost:5672
As the current retry is 0 and the Max is 0 then failover doesn't occur.
Am I missing something?
Cheers
Martin
2009/5/14 raj...@apache.org:
Author: rajith
Date: Thu May 14 19:50:23 2009
New Revision: 774899
URL: http://svn.apache.org/viewvc?rev=774899view=rev
Log:
This is a fix for QPID-1859
For FailoverSingleServer the default for retries is set to 0 and the
current_retries start from 0 instead of -1.
For FailoverRoundRobinServers the current_broker_index now starts from 0
instead of -1.
The AMQConnection now uses the getCurrentBrokerDetails() instead of the
getNextBrokerDetails() to get the initial broker to connect.
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverSingleServer.java
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java?rev=774899r1=774898r2=774899view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
Thu May 14 19:50:23 2009
@@ -455,7 +455,7 @@
}
_failoverPolicy = new FailoverPolicy(connectionURL, this);
-BrokerDetails brokerDetails =
_failoverPolicy.getNextBrokerDetails();
+BrokerDetails brokerDetails =
_failoverPolicy.getCurrentBrokerDetails();
if (brokerDetails.getTransport().equals(BrokerDetails.VM))
{
_delegate = new AMQConnectionDelegate_8_0(this);
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java?rev=774899r1=774898r2=774899view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
Thu May 14 19:50:23 2009
@@ -35,19 +35,19 @@
public static final int DEFAULT_SERVER_RETRIES = 0;
/** The index into the hostDetails array of the broker to which we are
connected */
-private int _currentBrokerIndex = -1;
+private int _currentBrokerIndex = 0;
/** The number of times to retry connecting for each server */
private int _serverRetries;
/** The current number of retry attempts made */
-private int _currentServerRetry;
+private int _currentServerRetry = 0;
/** The number of times to cycle through the servers */
private int _cycleRetries;
/** The current number of cycles performed. */
-private int _currentCycleRetries;
+private int
[jira] Updated: (QPID-1781) Add an ant target to run interop tests
[ https://issues.apache.org/jira/browse/QPID-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-1781: --- Status: Ready To Review (was: In Progress) Add an ant target to run interop tests -- Key: QPID-1781 URL: https://issues.apache.org/jira/browse/QPID-1781 Project: Qpid Issue Type: Improvement Components: Ant Build System Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.6 Need to add an ant target to run the java examples against c++ and python clients using the c++ broker. As a first step this should run the verify_all script. -- 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: svn commit: r774899 - in /qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid: client/AMQConnection.java jms/failover/FailoverRoundRobinServers.java jms/failover/FailoverSingleServer.java
I'd have to question what the point of the class is then as it is it
is basically a much more complicated version of 'NoFailover'.
It should at least allow failover to occur once. If not once per
successfull connection
Martin
2009/6/24 Rajith Attapattu rajit...@gmail.com:
Martin,
When we discussed this issue we agreed that by default the
SingleFailoverMethod should not retry at all.
So in order to make the initial connection attempt work, we made
AMQConnection use getCurrentBrokerDetails() instead of the
getNextBrokerDetails() to get the initial broker to connect.
Regards,
Rajith
On Wed, Jun 24, 2009 at 11:27 AM, Martin Ritchieritch...@apache.org wrote:
Hi Rajith,
Why did you set the default retries to 0 as well as starting the
_currentRetries from 0? I thought the original problem was that it
would always try twice with this commit we effectively reduced the
retries by 2. Do you have time to write a test to ensure that
FailoverSingleServer only retires once not twice :)
/** The default number of times to rety a conection to this server */
-public static final int DEFAULT_SERVER_RETRIES = 1;
+public static final int DEFAULT_SERVER_RETRIES = 0;
This commit has resulted in the SingleServerFailover not working.
When I make my connection failover I get :
main 2009-06-24 16:21:45,105 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Session closed called with
failover state currently FailoverState: NOT STARTED
main 2009-06-24 16:21:45,105 DEBUG [apache.qpid.jms.FailoverPolicy]
All failover methods exhausted
main 2009-06-24 16:21:45,106 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Failover not allowed by
policy.
main 2009-06-24 16:21:45,106 DEBUG [apache.qpid.jms.FailoverPolicy]
All failover methods exhausted
main 2009-06-24 16:21:45,106 DEBUG
[qpid.client.protocol.AMQProtocolHandler] Failover Policy:
Failover not allowed
Failover policy methods
Single Server:
Max Retries:0
Current Retry:0
tcp://localhost:5672
As the current retry is 0 and the Max is 0 then failover doesn't occur.
Am I missing something?
Cheers
Martin
2009/5/14 raj...@apache.org:
Author: rajith
Date: Thu May 14 19:50:23 2009
New Revision: 774899
URL: http://svn.apache.org/viewvc?rev=774899view=rev
Log:
This is a fix for QPID-1859
For FailoverSingleServer the default for retries is set to 0 and the
current_retries start from 0 instead of -1.
For FailoverRoundRobinServers the current_broker_index now starts from 0
instead of -1.
The AMQConnection now uses the getCurrentBrokerDetails() instead of the
getNextBrokerDetails() to get the initial broker to connect.
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverSingleServer.java
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java?rev=774899r1=774898r2=774899view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
Thu May 14 19:50:23 2009
@@ -455,7 +455,7 @@
}
_failoverPolicy = new FailoverPolicy(connectionURL, this);
-BrokerDetails brokerDetails =
_failoverPolicy.getNextBrokerDetails();
+BrokerDetails brokerDetails =
_failoverPolicy.getCurrentBrokerDetails();
if (brokerDetails.getTransport().equals(BrokerDetails.VM))
{
_delegate = new AMQConnectionDelegate_8_0(this);
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java?rev=774899r1=774898r2=774899view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/failover/FailoverRoundRobinServers.java
Thu May 14 19:50:23 2009
@@ -35,19 +35,19 @@
public static final int DEFAULT_SERVER_RETRIES = 0;
/** The index into the hostDetails array of the broker to which we are
connected */
-private int _currentBrokerIndex = -1;
+private int _currentBrokerIndex = 0;
/** The number of times to retry connecting for each server */
private int _serverRetries;
/** The current number of retry attempts made */
-private int
Re: RFC: Maven and the Java Build
Aidan Skinner wrote: On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearneybkear...@redhat.com wrote: The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. Why is it bad to use the maven repos instead of copying things from java/lib? It makes reproducible builds hard/impossible and doesn't play well with package systems. I have not seen the former issue.. but I will trust you on it. On the latter (package systems) using maven repos seems no worse then what is being done now. -- bk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1949) Client does not ensure connection is closed before attempting failover
[ https://issues.apache.org/jira/browse/QPID-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1949: - Attachment: MessageDisappearWithIOExceptionTest.java Client does not ensure connection is closed before attempting failover -- Key: QPID-1949 URL: https://issues.apache.org/jira/browse/QPID-1949 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: M4, 0.5 Reporter: Martin Ritchie Attachments: MessageDisappearWithIOExceptionTest.java * Summary: * A user has reported message loss from their application. On bouncing of * the broker the 'lost' messages are delivered to the broker. * * Note: * The client was using Spring so that may influence the situation. * * Issue: * The log files show 7 instances of the following which result in 7 * missing messages. * * The client log files show: * * The broker log file show: * * * 7 missing messages have delivery tags 5-11. Which says that they are * sequentially the next message from the broker. * * The only way for the 'without a handler' log to occur is if the consumer * has been removed from the look up table of the dispatcher. * And the only way for the 'null message' log to occur on the broker is is * if the message does not exist in the unacked-map * * The consumer is only removed from the list during session * closure and failover. * * If the session was closed then the broker would requeue the unacked * messages so the potential exists to have an empty map but the broker * will not send a message out after the unacked map has been cleared. * * When failover occurs the _consumer map is cleared and the consumers are * resubscribed. This is down without first stopping any existing * dispatcher so there exists the potential to receive a message after * the _consumer map has been cleared which is how the 'without a handler' * log statement occurs. * * Scenario: * * Looking over logs the sequence that best fits the events is as follows: * - Something causes Mina to be delayed causing the WriteTimoutException. * - This exception is recevied by AMQProtocolHandler#exceptionCaught * - As the WriteTimeoutException is an IOException this will cause * sessionClosed to be called to start failover. * + This is potentially the issues here. All IOExceptions are treated * as connection failure events. * - Failover Runs * + Failover assumes that the previous connection has been closed. * + Failover binds the existing objects (AMQConnection/Session) to the * new connection objects. * - Everything is reported as being successfully failed over. * However, what is neglected is that the original connection has not * been closed. * + So what occurs is that the broker sends a message to the consumer on * the original connection, as it was not notified of the client * failing over. * As the client failover reuses the original AMQSession and Dispatcher * the new messages the broker sends to the old consumer arrives at the * client and is processed by the same AMQSession and Dispatcher. * However, as the failover process cleared the _consumer map and * resubscribe the consumers the Dispatcher does not recognise the * delivery tag and so logs the 'without a handler' message. * - The Dispatcher then attempts to reject the message, however, * + The AMQSession/Dispatcher pair have been swapped to using a new Mina * ProtocolSession as part of the failover process so the reject is * sent down the second connection. The broker receives the Reject * request but as the Message was sent on a different connection the * unacknowledgemap is empty and a 'message is null' log message * produced. * * Test Strategy: * * It should be easy to demonstrate if we can send an IOException to * AMQProtocolHandler#exceptionCaught and then try sending a message. -- 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-1950) During failover clients can cause NPE to occur on the broker.
[ https://issues.apache.org/jira/browse/QPID-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1950: - Attachment: MessageDisappearWithIOExceptionTest.java This is a modified version of the test case on QPID-1949 which will on occasion highlight the NPE. During failover clients can cause NPE to occur on the broker. - Key: QPID-1950 URL: https://issues.apache.org/jira/browse/QPID-1950 Project: Qpid Issue Type: Bug Components: Java Broker, Java Client Affects Versions: M4, 0.5 Reporter: Martin Ritchie Attachments: MessageDisappearWithIOExceptionTest.java, QPID-1950.log Summary: During failover NPEs have been seen from the ChannelOpenHandler as the virtualHost has not yet been set on the session. The Java client should not be able to cause this sort of problem. This was discovered whilst testing another issue wifh failover. QPID-1949 The race condition can be seen by editing the test case (as attached) so that it attempts to continue to use the connection after failover. The attached log shows one instance where the NPE occured. -- 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: RFC: Does a jboss deployer go into the qpid source tree
Bryan, Sorry I don't know enough about the legal side to say if this is ok or not. It might be a good idea to ask the apache legal folks. Regards, Rajith On Wed, Jun 24, 2009 at 10:30 AM, Bryan Kearneybkear...@redhat.com wrote: Rajith Attapattu wrote: Bryan, If JBoss code is needed for building then it might be an issue as JBoss is using LGPL. Any libraries that are checked into the lib dir in the project has to have a compatible license. An alternative would be to use some form of abstraction with reflection. This prevents the need for having JBoss libraries at compile time. I used a similar strategy to support Realtime Java constructs. Regards, Rajith Rajith: Thanks for the feedback. I was assuming a model where to build the contrib stuff the developer would need to download additional bits. Would that alleviate the issue? Or just add new issues? -- bk - 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
Re: RFC: Maven and the Java Build
Bryan Kearney wrote: Aidan Skinner wrote: On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearneybkear...@redhat.com wrote: The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. Why is it bad to use the maven repos instead of copying things from java/lib? It makes reproducible builds hard/impossible and doesn't play well with package systems. I have not seen the former issue.. but I will trust you on it. On the latter (package systems) using maven repos seems no worse then what is being done now. The issue with using maven repos is that if you happen to use svn to rollback to a version where we were using maven, the build will most likely fail because it is dependent on a set of external maven repos that are no longer in sync with the needs of that particular revision. The nice thing about the way it is now, is that I can do an svn update -rfoo and rollback to any given version with the current build system and be fairly certain that the build will function because the only dependency stored outside of svn is ant, and that has a fairly small and stable footprint. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: RFC: Maven and the Java Build
Rafael Schloming wrote: Bryan Kearney wrote: Aidan Skinner wrote: On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearneybkear...@redhat.com wrote: The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. Why is it bad to use the maven repos instead of copying things from java/lib? It makes reproducible builds hard/impossible and doesn't play well with package systems. I have not seen the former issue.. but I will trust you on it. On the latter (package systems) using maven repos seems no worse then what is being done now. The issue with using maven repos is that if you happen to use svn to rollback to a version where we were using maven, the build will most likely fail because it is dependent on a set of external maven repos that are no longer in sync with the needs of that particular revision. sorry to be dense.. if I am using version 2.2 of a libarary, and then rollback to version 2.1...how does that cause an issue with the build? -- bk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1951) Need wrappers for Posix types declared in Windows portability layer
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: Improvement Components: C++ Client Environment: Windows C++ Reporter: Pete MacKinnon Priority: Minor 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
Re: RFC: Maven and the Java Build
Bryan Kearney wrote: Rafael Schloming wrote: Bryan Kearney wrote: Aidan Skinner wrote: On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearneybkear...@redhat.com wrote: The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. Why is it bad to use the maven repos instead of copying things from java/lib? It makes reproducible builds hard/impossible and doesn't play well with package systems. I have not seen the former issue.. but I will trust you on it. On the latter (package systems) using maven repos seems no worse then what is being done now. The issue with using maven repos is that if you happen to use svn to rollback to a version where we were using maven, the build will most likely fail because it is dependent on a set of external maven repos that are no longer in sync with the needs of that particular revision. sorry to be dense.. if I am using version 2.2 of a libarary, and then rollback to version 2.1...how does that cause an issue with the build? If I try to build an older version of qpid that requires version 2.1, and the maven repo only has version 2.2 then one of two things will happen depending on how the pom is configured. If I specify that revision 2.1 is required in the pom file then the build will break because version 2.1 of the library is no longer available. If I don't specify this, then maven will attempt to build against version 2.2 which may fail due to incompatibilities, and even if it succeeds, it won't be the same bits I would have gotten had I built against version 2.1. With ant we have all the dependencies stored in svn, so if I roll back to an older version of qpid and do a rebuild, then I know I'll get exactly the same bits I would have gotten had I done a build when that version was current. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: RFC: Maven and the Java Build
Rafael Schloming wrote: Bryan Kearney wrote: Rafael Schloming wrote: Bryan Kearney wrote: Aidan Skinner wrote: On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearneybkear...@redhat.com wrote: The main issue is that for dep resolution it still needs something looks like a maven repo, not like /usr/java. I think a new resolver wouldn't be very hard to write, but I haven't found the cycles for it yet. Why is it bad to use the maven repos instead of copying things from java/lib? It makes reproducible builds hard/impossible and doesn't play well with package systems. I have not seen the former issue.. but I will trust you on it. On the latter (package systems) using maven repos seems no worse then what is being done now. The issue with using maven repos is that if you happen to use svn to rollback to a version where we were using maven, the build will most likely fail because it is dependent on a set of external maven repos that are no longer in sync with the needs of that particular revision. sorry to be dense.. if I am using version 2.2 of a libarary, and then rollback to version 2.1...how does that cause an issue with the build? If I try to build an older version of qpid that requires version 2.1, and the maven repo only has version 2.2 then one of two things will happen depending on how the pom is configured. If I specify that revision 2.1 is required in the pom file then the build will break because version 2.1 of the library is no longer available. If I don't specify this, then maven will attempt to build against version 2.2 which may fail due to incompatibilities, and even if it succeeds, it won't be the same bits I would have gotten had I built against version 2.1. Ok... I have always used required... so I have never seen it pick the latest. I have also not seen the items go away.. but I understand the issue. With ant we have all the dependencies stored in svn, so if I roll back to an older version of qpid and do a rebuild, then I know I'll get exactly the same bits I would have gotten had I done a build when that version was current. Can the ivy setup Aiden mentioned populate/update the lib directory? That way they latest can be checked in and we can use a single depdendency data to build and create poms. -- bk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r788179 - /qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java
Rafi,
As I see a very minor issue with this commit is that it also prevents
a queue declare when a queue created using the
session.createQueue(queue-name); method is used in creating a
message consumer. IMO when this method is called the user expects a
queue to be created dynamically (even if -Dqpid.declare_queues=false
).
IMO I think the qpid.declare_queues switch should be for
destinations that we look up via JNDI.
Regards,
Rajith
On Wed, Jun 24, 2009 at 4:56 PM, r...@apache.org wrote:
Author: rhs
Date: Wed Jun 24 20:56:15 2009
New Revision: 788179
URL: http://svn.apache.org/viewvc?rev=788179view=rev
Log:
added system properties to control declaration of exchanges and queues
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java?rev=788179r1=788178r2=788179view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java
Wed Jun 24 20:56:15 2009
@@ -205,6 +205,11 @@
*/
protected static final boolean DEFAULT_MANDATORY =
Boolean.parseBoolean(System.getProperty(qpid.default_mandatory, true));
+protected static final boolean DECLARE_QUEUES =
+Boolean.parseBoolean(System.getProperty(qpid.declare_queues,
true));
+protected static final boolean DECLARE_EXCHANGES =
+Boolean.parseBoolean(System.getProperty(qpid.declare_exchanges,
true));
+
/** System property to enable strict AMQP compliance. */
public static final String STRICT_AMQP = STRICT_AMQP;
@@ -2465,9 +2470,16 @@
AMQProtocolHandler protocolHandler = getProtocolHandler();
-declareExchange(amqd, protocolHandler, nowait);
+if (DECLARE_EXCHANGES)
+{
+declareExchange(amqd, protocolHandler, nowait);
+}
-AMQShortString queueName = declareQueue(amqd, protocolHandler,
consumer.isNoLocal(), nowait);
+if (DECLARE_QUEUES || amqd.isNameRequired())
+{
+declareQueue(amqd, protocolHandler, consumer.isNoLocal(),
nowait);
+}
+AMQShortString queueName = amqd.getAMQQueueName();
// store the consumer queue name
consumer.setQueuename(queueName);
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:commits-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
