[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname and this causes problems with localhost among others
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072885#comment-13072885 ] Andrew Stitcher commented on QPID-3375: --- I think there are a number of problems with this proposed change: 1. Federation tests during "make check" depend on using loopback addresses: They set up multiple brokers on a single machine and wire them together with loopback routes. Disallowing loopback routes would prevent this testing. It may be possible to figure out an external network address for the machine, but this cannot be guaranteed (not all machines have an external address, but all have loopback with most current networking setups) 2. You can't resolve the names to get IP addresses at configuration time: * The current federation mechanism automatically retries under many circumstances including name resolution failure, this is actually a real feature in that it allows the name->address mapping to change or to round robin in a way that resolving ahead of time doesn't. * In a mixed IPv4/IPv6 network doing the lookup somewhere other than the machine actually making the connection _at the time the connection is needed_ may not get the correct answer. Actually the is is true for any network but in a mixed network the v4 and v6 connectivity may differ across the network. * The address resolution will usually return multiple IP addresses which need to be tried in turn. You can't do this in config-route as it can currently only send a single name. > qpid-route does not resolve hostname and this causes problems with localhost > among others > - > > Key: QPID-3375 > URL: https://issues.apache.org/jira/browse/QPID-3375 > Project: Qpid > Issue Type: Bug > Components: python tools >Affects Versions: 0.10 > Environment: All >Reporter: William Henry >Assignee: Gordon Sim > Labels: qpid-route > Attachments: qpid-route, qpid-route.diff > > > All the examples for Federation and qpid-route use localhost. For a multihost > environment this is not a good idea. > 1. 'localhost': can end up in the routing table of remote host > erroneously. > 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the > route erroneously > 3. Even non localhost names don't get resolved and checked. > Here is the test I was performing. > I was doing some playing/testing with federation and I used two machines: my > laptop (sligo) and a remote machine (buzz). I ran three brokers: 2 on sligo > on > ports 5672 and 5682 and one on remote on port 5682. > From sligo I set up some links between all the brokers. > (The problem has already occurred on the links above. Listing the routes will > show the problem. But we'll go on) > From sligo I set up a topic exchange on each broker: > $ qpid-config -a localhost:5672 add exchange topic T.Prod > $ qpid-config -a localhost:5682 add exchange topic T.Prod > $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod > On sligo I set up dynamic routes from source localhost:5672 to localhost:5682 > and buzz.somedomain.com:5682. > When I list the routes from sligo I see: > $ qpid-route route list localhost:5682 > localhost:5682 localhost:5672 T.Prod > $ qpid-route route list buzz.somedomain.com:5682 > buzz.somedomain.com:5682 localhost:5672 T.Prod > When I run example program drain on localhost:5682 on sligo I get the > messages sent using the spout example program to default broker on sligo (on > 5672). > When I run drain on buzz I don't see anything. > I see references to "localhost:5672" in the trace output of buzz's broker. > This is BAD! > We need qpid-route to resolve hostname before passing the arg to the remote > broker. > (In the meantime we might want to warn users of using 'localhost' with > qpid-route across different hosts.) > I will attach a diff and a new version of qpid-route for review. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname and this causes problems with localhost among others
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072890#comment-13072890 ] Andrew Stitcher commented on QPID-3375: --- Actually it's not clear to me what the bug here actually is: Is it that one broker will pass one of its routes to another federated broker, if this is so then this behaviour can never be guaranteed to work as the view of the network may be different from the two locations irrespective of loopback addresses. But the best hope of making this work is to pass DNS names around and not IP addresses. OR Is it that the admin needs to take into account the difference between networking where he is and where the broker he configures is? In this case we need to improve the documentation and tools substantially, because qpid-route doesn't really make explicit from which viewpoint the network names are resolved. We just talk about source and destination without being clear from whose viewpoint the routes are named. > qpid-route does not resolve hostname and this causes problems with localhost > among others > - > > Key: QPID-3375 > URL: https://issues.apache.org/jira/browse/QPID-3375 > Project: Qpid > Issue Type: Bug > Components: python tools >Affects Versions: 0.10 > Environment: All >Reporter: William Henry >Assignee: Gordon Sim > Labels: qpid-route > Attachments: qpid-route, qpid-route.diff > > > All the examples for Federation and qpid-route use localhost. For a multihost > environment this is not a good idea. > 1. 'localhost': can end up in the routing table of remote host > erroneously. > 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the > route erroneously > 3. Even non localhost names don't get resolved and checked. > Here is the test I was performing. > I was doing some playing/testing with federation and I used two machines: my > laptop (sligo) and a remote machine (buzz). I ran three brokers: 2 on sligo > on > ports 5672 and 5682 and one on remote on port 5682. > From sligo I set up some links between all the brokers. > (The problem has already occurred on the links above. Listing the routes will > show the problem. But we'll go on) > From sligo I set up a topic exchange on each broker: > $ qpid-config -a localhost:5672 add exchange topic T.Prod > $ qpid-config -a localhost:5682 add exchange topic T.Prod > $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod > On sligo I set up dynamic routes from source localhost:5672 to localhost:5682 > and buzz.somedomain.com:5682. > When I list the routes from sligo I see: > $ qpid-route route list localhost:5682 > localhost:5682 localhost:5672 T.Prod > $ qpid-route route list buzz.somedomain.com:5682 > buzz.somedomain.com:5682 localhost:5672 T.Prod > When I run example program drain on localhost:5682 on sligo I get the > messages sent using the spout example program to default broker on sligo (on > 5672). > When I run drain on buzz I don't see anything. > I see references to "localhost:5672" in the trace output of buzz's broker. > This is BAD! > We need qpid-route to resolve hostname before passing the arg to the remote > broker. > (In the meantime we might want to warn users of using 'localhost' with > qpid-route across different hosts.) > I will attach a diff and a new version of qpid-route for review. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname and this causes problems with localhost among others
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072924#comment-13072924 ] Andrew Stitcher commented on QPID-3375: --- I agree that only allowing localhost in the source when we have localhost in the destination is a reasonable strategic heuristic to help eliminate some user error. But I think that we should just print a stern warning if localhost is used rather than cause an error as we stand to stop behaviour that the admin might be trying to set up intentionally (not that I can think of a reason for it presently). > qpid-route does not resolve hostname and this causes problems with localhost > among others > - > > Key: QPID-3375 > URL: https://issues.apache.org/jira/browse/QPID-3375 > Project: Qpid > Issue Type: Bug > Components: python tools >Affects Versions: 0.10 > Environment: All >Reporter: William Henry >Assignee: Gordon Sim > Labels: qpid-route > Attachments: qpid-route, qpid-route.diff > > > All the examples for Federation and qpid-route use localhost. For a multihost > environment this is not a good idea. > 1. 'localhost': can end up in the routing table of remote host > erroneously. > 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the > route erroneously > 3. Even non localhost names don't get resolved and checked. > Here is the test I was performing. > I was doing some playing/testing with federation and I used two machines: my > laptop (sligo) and a remote machine (buzz). I ran three brokers: 2 on sligo > on > ports 5672 and 5682 and one on remote on port 5682. > From sligo I set up some links between all the brokers. > (The problem has already occurred on the links above. Listing the routes will > show the problem. But we'll go on) > From sligo I set up a topic exchange on each broker: > $ qpid-config -a localhost:5672 add exchange topic T.Prod > $ qpid-config -a localhost:5682 add exchange topic T.Prod > $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod > On sligo I set up dynamic routes from source localhost:5672 to localhost:5682 > and buzz.somedomain.com:5682. > When I list the routes from sligo I see: > $ qpid-route route list localhost:5682 > localhost:5682 localhost:5672 T.Prod > $ qpid-route route list buzz.somedomain.com:5682 > buzz.somedomain.com:5682 localhost:5672 T.Prod > When I run example program drain on localhost:5682 on sligo I get the > messages sent using the spout example program to default broker on sligo (on > 5672). > When I run drain on buzz I don't see anything. > I see references to "localhost:5672" in the trace output of buzz's broker. > This is BAD! > We need qpid-route to resolve hostname before passing the arg to the remote > broker. > (In the meantime we might want to warn users of using 'localhost' with > qpid-route across different hosts.) > I will attach a diff and a new version of qpid-route for review. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3375) qpid-route does not resolve hostname and this causes problems with localhost among others
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072924#comment-13072924 ] Andrew Stitcher edited comment on QPID-3375 at 7/29/11 6:18 PM: I agree that only allowing localhost in the source when we have localhost in the destination is a reasonable tactical heuristic to help eliminate some user error. But I think that we should just print a stern warning if localhost is used rather than cause an error as we stand to stop behaviour that the admin might be trying to set up intentionally (not that I can think of a reason for it presently). was (Author: astitcher): I agree that only allowing localhost in the source when we have localhost in the destination is a reasonable strategic heuristic to help eliminate some user error. But I think that we should just print a stern warning if localhost is used rather than cause an error as we stand to stop behaviour that the admin might be trying to set up intentionally (not that I can think of a reason for it presently). > qpid-route does not resolve hostname and this causes problems with localhost > among others > - > > Key: QPID-3375 > URL: https://issues.apache.org/jira/browse/QPID-3375 > Project: Qpid > Issue Type: Bug > Components: python tools >Affects Versions: 0.10 > Environment: All >Reporter: William Henry >Assignee: Gordon Sim > Labels: qpid-route > Attachments: qpid-route, qpid-route.diff > > > All the examples for Federation and qpid-route use localhost. For a multihost > environment this is not a good idea. > 1. 'localhost': can end up in the routing table of remote host > erroneously. > 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the > route erroneously > 3. Even non localhost names don't get resolved and checked. > Here is the test I was performing. > I was doing some playing/testing with federation and I used two machines: my > laptop (sligo) and a remote machine (buzz). I ran three brokers: 2 on sligo > on > ports 5672 and 5682 and one on remote on port 5682. > From sligo I set up some links between all the brokers. > (The problem has already occurred on the links above. Listing the routes will > show the problem. But we'll go on) > From sligo I set up a topic exchange on each broker: > $ qpid-config -a localhost:5672 add exchange topic T.Prod > $ qpid-config -a localhost:5682 add exchange topic T.Prod > $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod > On sligo I set up dynamic routes from source localhost:5672 to localhost:5682 > and buzz.somedomain.com:5682. > When I list the routes from sligo I see: > $ qpid-route route list localhost:5682 > localhost:5682 localhost:5672 T.Prod > $ qpid-route route list buzz.somedomain.com:5682 > buzz.somedomain.com:5682 localhost:5672 T.Prod > When I run example program drain on localhost:5682 on sligo I get the > messages sent using the spout example program to default broker on sligo (on > 5672). > When I run drain on buzz I don't see anything. > I see references to "localhost:5672" in the trace output of buzz's broker. > This is BAD! > We need qpid-route to resolve hostname before passing the arg to the remote > broker. > (In the meantime we might want to warn users of using 'localhost' with > qpid-route across different hosts.) > I will attach a diff and a new version of qpid-route for review. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname and this causes problems with localhost among others
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072955#comment-13072955 ] Andrew Stitcher commented on QPID-3375: --- Re the gai_error(): as messy as this behaviour seems I think is probably correct (assuming I understand correctly). DNS lookups can be ephemeral and so getting a lookup error now doesn't mean that if I try it in 5 minutes I will still get an error. I'm pretty sure the builtin retry mechanism in the broker link code will indeed retry if it gets a DNS resolution error so that you see the exception in the link status, but then it retries later. Or is the gai_error() appearing somewhere else? > qpid-route does not resolve hostname and this causes problems with localhost > among others > - > > Key: QPID-3375 > URL: https://issues.apache.org/jira/browse/QPID-3375 > Project: Qpid > Issue Type: Bug > Components: python tools >Affects Versions: 0.10 > Environment: All >Reporter: William Henry >Assignee: Gordon Sim > Labels: qpid-route > Attachments: qpid-route, qpid-route.diff > > > All the examples for Federation and qpid-route use localhost. For a multihost > environment this is not a good idea. > 1. 'localhost': can end up in the routing table of remote host > erroneously. > 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the > route erroneously > 3. Even non localhost names don't get resolved and checked. > Here is the test I was performing. > I was doing some playing/testing with federation and I used two machines: my > laptop (sligo) and a remote machine (buzz). I ran three brokers: 2 on sligo > on > ports 5672 and 5682 and one on remote on port 5682. > From sligo I set up some links between all the brokers. > (The problem has already occurred on the links above. Listing the routes will > show the problem. But we'll go on) > From sligo I set up a topic exchange on each broker: > $ qpid-config -a localhost:5672 add exchange topic T.Prod > $ qpid-config -a localhost:5682 add exchange topic T.Prod > $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod > On sligo I set up dynamic routes from source localhost:5672 to localhost:5682 > and buzz.somedomain.com:5682. > When I list the routes from sligo I see: > $ qpid-route route list localhost:5682 > localhost:5682 localhost:5672 T.Prod > $ qpid-route route list buzz.somedomain.com:5682 > buzz.somedomain.com:5682 localhost:5672 T.Prod > When I run example program drain on localhost:5682 on sligo I get the > messages sent using the spout example program to default broker on sligo (on > 5672). > When I run drain on buzz I don't see anything. > I see references to "localhost:5672" in the trace output of buzz's broker. > This is BAD! > We need qpid-route to resolve hostname before passing the arg to the remote > broker. > (In the meantime we might want to warn users of using 'localhost' with > qpid-route across different hosts.) > I will attach a diff and a new version of qpid-route for review. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname and this causes problems with localhost among others
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081903#comment-13081903 ] Andrew Stitcher commented on QPID-3375: --- It's not really correct to check against the string form "localhost" as there is only convention that marks it out as a name for the loopback interface, and moreover there will be a number of names in most systems that give loopback (eg "localhost.localdomain" as well) Probably the correct test IMO is to resolve the name and then check whether the resolved name is a loopback address (127.0.0.1/::1). However this is fallible as you are not testing for loopback on the actual machine that you will send the route to and so the name resolutions could be different. This inability to do an exactly correct job is the major reason to only produce a warning IMO. > qpid-route does not resolve hostname and this causes problems with localhost > among others > - > > Key: QPID-3375 > URL: https://issues.apache.org/jira/browse/QPID-3375 > Project: Qpid > Issue Type: Bug > Components: python tools >Affects Versions: 0.10 > Environment: All >Reporter: William Henry >Assignee: Gordon Sim > Labels: qpid-route > Attachments: QPID-3375.patch, qpid-route, qpid-route, > qpid-route-diff.txt, qpid-route.diff > > > All the examples for Federation and qpid-route use localhost. For a multihost > environment this is not a good idea. > 1. 'localhost': can end up in the routing table of remote host > erroneously. > 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the > route erroneously > 3. Even non localhost names don't get resolved and checked. > Here is the test I was performing. > I was doing some playing/testing with federation and I used two machines: my > laptop (sligo) and a remote machine (buzz). I ran three brokers: 2 on sligo > on > ports 5672 and 5682 and one on remote on port 5682. > From sligo I set up some links between all the brokers. > (The problem has already occurred on the links above. Listing the routes will > show the problem. But we'll go on) > From sligo I set up a topic exchange on each broker: > $ qpid-config -a localhost:5672 add exchange topic T.Prod > $ qpid-config -a localhost:5682 add exchange topic T.Prod > $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod > On sligo I set up dynamic routes from source localhost:5672 to localhost:5682 > and buzz.somedomain.com:5682. > When I list the routes from sligo I see: > $ qpid-route route list localhost:5682 > localhost:5682 localhost:5672 T.Prod > $ qpid-route route list buzz.somedomain.com:5682 > buzz.somedomain.com:5682 localhost:5672 T.Prod > When I run example program drain on localhost:5682 on sligo I get the > messages sent using the spout example program to default broker on sligo (on > 5672). > When I run drain on buzz I don't see anything. > I see references to "localhost:5672" in the trace output of buzz's broker. > This is BAD! > We need qpid-route to resolve hostname before passing the arg to the remote > broker. > (In the meantime we might want to warn users of using 'localhost' with > qpid-route across different hosts.) > I will attach a diff and a new version of qpid-route for review. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3404) Qpid should support IPv6 connections
Qpid should support IPv6 connections Key: QPID-3404 URL: https://issues.apache.org/jira/browse/QPID-3404 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client, Java Broker, Java Client, Python Client, python tools, Qpid Managment Framework Reporter: Andrew Stitcher Qpid should support IPv6 (actually TCPv6) connections for all of the language implementations. This also implies having a way to specify IPv6 literal addresses in the connection URLs that we use to connection clients to brokers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3404) Qpid should support IPv6 connections
[ https://issues.apache.org/jira/browse/QPID-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081927#comment-13081927 ] Andrew Stitcher commented on QPID-3404: --- I propose to use this as a top level issue to track overall progress and use sub issues for actual work items > Qpid should support IPv6 connections > > > Key: QPID-3404 > URL: https://issues.apache.org/jira/browse/QPID-3404 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client, Java Broker, Java Client, Python > Client, python tools, Qpid Managment Framework >Reporter: Andrew Stitcher > > Qpid should support IPv6 (actually TCPv6) connections for all of the language > implementations. > This also implies having a way to specify IPv6 literal addresses in the > connection URLs that we use to connection clients to brokers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3405) IPv6 support for C++ Linux client/broker
IPv6 support for C++ Linux client/broker Key: QPID-3405 URL: https://issues.apache.org/jira/browse/QPID-3405 Project: Qpid Issue Type: Sub-task Reporter: Andrew Stitcher -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3406) IPv6 support for C++ Windows client/broker
IPv6 support for C++ Windows client/broker -- Key: QPID-3406 URL: https://issues.apache.org/jira/browse/QPID-3406 Project: Qpid Issue Type: Sub-task Components: C++ Broker, C++ Client Reporter: Andrew Stitcher -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3405) IPv6 support for C++ Linux client/broker
[ https://issues.apache.org/jira/browse/QPID-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3405: -- Component/s: (was: Qpid Managment Framework) (was: python tools) (was: Python Client) (was: Java Client) (was: Java Broker) > IPv6 support for C++ Linux client/broker > > > Key: QPID-3405 > URL: https://issues.apache.org/jira/browse/QPID-3405 > Project: Qpid > Issue Type: Sub-task > Components: C++ Broker, C++ Client >Reporter: Andrew Stitcher > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3406) IPv6 support for C++ Windows client/broker
[ https://issues.apache.org/jira/browse/QPID-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-3406: - Assignee: Andrew Stitcher > IPv6 support for C++ Windows client/broker > -- > > Key: QPID-3406 > URL: https://issues.apache.org/jira/browse/QPID-3406 > Project: Qpid > Issue Type: Sub-task > Components: C++ Broker, C++ Client >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3405) IPv6 support for C++ Linux client/broker
[ https://issues.apache.org/jira/browse/QPID-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-3405: - Assignee: Andrew Stitcher > IPv6 support for C++ Linux client/broker > > > Key: QPID-3405 > URL: https://issues.apache.org/jira/browse/QPID-3405 > Project: Qpid > Issue Type: Sub-task > Components: C++ Broker, C++ Client >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3407) IPv6 support for python client
IPv6 support for python client -- Key: QPID-3407 URL: https://issues.apache.org/jira/browse/QPID-3407 Project: Qpid Issue Type: Sub-task Components: Python Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3404) Qpid should support IPv6 connections
[ https://issues.apache.org/jira/browse/QPID-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3404: -- Description: Qpid should support IPv6 (actually TCPv6) connections for all of the language implementations. This also implies having a way to specify IPv6 literal addresses in the connection URLs that we use to connect clients to brokers. was: Qpid should support IPv6 (actually TCPv6) connections for all of the language implementations. This also implies having a way to specify IPv6 literal addresses in the connection URLs that we use to connection clients to brokers. > Qpid should support IPv6 connections > > > Key: QPID-3404 > URL: https://issues.apache.org/jira/browse/QPID-3404 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client, Java Broker, Java Client, Python > Client, python tools, Qpid Managment Framework >Reporter: Andrew Stitcher > > Qpid should support IPv6 (actually TCPv6) connections for all of the language > implementations. > This also implies having a way to specify IPv6 literal addresses in the > connection URLs that we use to connect clients to brokers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3408) IPv6 support for Java client/broker
[ https://issues.apache.org/jira/browse/QPID-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3408: -- Component/s: (was: Qpid Managment Framework) (was: python tools) (was: Python Client) (was: C++ Client) (was: C++ Broker) > IPv6 support for Java client/broker > --- > > Key: QPID-3408 > URL: https://issues.apache.org/jira/browse/QPID-3408 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker, Java Client >Reporter: Andrew Stitcher > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3408) IPv6 support for Java client/broker
IPv6 support for Java client/broker --- Key: QPID-3408 URL: https://issues.apache.org/jira/browse/QPID-3408 Project: Qpid Issue Type: Sub-task Reporter: Andrew Stitcher -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3407) IPv6 support for python client
[ https://issues.apache.org/jira/browse/QPID-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3407: -- Fix Version/s: 0.14 > IPv6 support for python client > -- > > Key: QPID-3407 > URL: https://issues.apache.org/jira/browse/QPID-3407 > Project: Qpid > Issue Type: Sub-task > Components: Python Client >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-488) Concurrent access to apr_pools (which are not thread safe)
[ https://issues.apache.org/jira/browse/QPID-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-488: - Fix Version/s: 0.14 > Concurrent access to apr_pools (which are not thread safe) > -- > > Key: QPID-488 > URL: https://issues.apache.org/jira/browse/QPID-488 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Affects Versions: M2 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Critical > Fix For: 0.14 > > > The c++ codebase is now set to share an apr pool per process which is a > problem as apr_pools are not thread safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3405) IPv6 support for C++ Linux client/broker
[ https://issues.apache.org/jira/browse/QPID-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3405: -- Fix Version/s: 0.14 > IPv6 support for C++ Linux client/broker > > > Key: QPID-3405 > URL: https://issues.apache.org/jira/browse/QPID-3405 > Project: Qpid > Issue Type: Sub-task > Components: C++ Broker, C++ Client >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3406) IPv6 support for C++ Windows client/broker
[ https://issues.apache.org/jira/browse/QPID-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3406: -- Fix Version/s: 0.14 > IPv6 support for C++ Windows client/broker > -- > > Key: QPID-3406 > URL: https://issues.apache.org/jira/browse/QPID-3406 > Project: Qpid > Issue Type: Sub-task > Components: C++ Broker, C++ Client >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-555) c++ client hangs if broker closes connection unexpectedly.
[ https://issues.apache.org/jira/browse/QPID-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-555: - Fix Version/s: 0.14 > c++ client hangs if broker closes connection unexpectedly. > -- > > Key: QPID-555 > URL: https://issues.apache.org/jira/browse/QPID-555 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: M2 >Reporter: Alan Conway >Priority: Critical > Fix For: 0.14 > > > Run the broker, start tests/perftest, kill the broker. The client logs the > socket error but never exits. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3348) Qmf broker proxy method create() does not handle keyword arguments, only regular parameters
[
https://issues.apache.org/jira/browse/QPID-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-3348:
--
Fix Version/s: (was: 0.14)
> Qmf broker proxy method create() does not handle keyword arguments, only
> regular parameters
> ---
>
> Key: QPID-3348
> URL: https://issues.apache.org/jira/browse/QPID-3348
> Project: Qpid
> Issue Type: Bug
>Affects Versions: 0.13
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
>
> The Qmf management methods defined in the management-schema.xml file are
> implemented through the console Object class __getattr__() method. This calls
> Object.invoke(), which in turn calls Object._sendMethodRequest().
> However, the implementation of _sendMethodRequest() accounts only for regular
> arguments in the args parameter, and ignores the kwargs parameter. Hence, the
> call to the create() call:
>
>
>
>
>
>
> as follows:
> broker_proxy.create("exchange", name, props, True)
> will work, but
> broker_proxy.create(type="exchange", name=name, properties=props, strict=True)
> will fail (Exception: Incorrect number of arguments: expected 4, got 0).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3309) Management broker object port is not set if broker started with port number set to 0
[ https://issues.apache.org/jira/browse/QPID-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3309: -- Fix Version/s: (was: 0.14) > Management broker object port is not set if broker started with port number > set to 0 > > > Key: QPID-3309 > URL: https://issues.apache.org/jira/browse/QPID-3309 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.13 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The management broker object has a port attribute which is set to the value > passed to the broker when it is started. If the value of port is zero, then > the broker will use an unused port number and return this number on the > command line. However, the broker management object is not updated, and > returns a value of 0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-488) Concurrent access to apr_pools (which are not thread safe)
[ https://issues.apache.org/jira/browse/QPID-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-488: - Fix Version/s: (was: 0.14) > Concurrent access to apr_pools (which are not thread safe) > -- > > Key: QPID-488 > URL: https://issues.apache.org/jira/browse/QPID-488 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Affects Versions: M2 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Critical > > The c++ codebase is now set to share an apr pool per process which is a > problem as apr_pools are not thread safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-555) c++ client hangs if broker closes connection unexpectedly.
[ https://issues.apache.org/jira/browse/QPID-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-555: - Fix Version/s: (was: 0.14) > c++ client hangs if broker closes connection unexpectedly. > -- > > Key: QPID-555 > URL: https://issues.apache.org/jira/browse/QPID-555 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: M2 >Reporter: Alan Conway >Priority: Critical > > Run the broker, start tests/perftest, kill the broker. The client logs the > socket error but never exits. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3044) Implement JCA Adapter for Java JMS client
[ https://issues.apache.org/jira/browse/QPID-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3044: -- Fix Version/s: (was: 0.11) 0.14 > Implement JCA Adapter for Java JMS client > - > > Key: QPID-3044 > URL: https://issues.apache.org/jira/browse/QPID-3044 > Project: Qpid > Issue Type: New Feature > Components: Java Client >Affects Versions: 0.8, 0.9, 0.10 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: JCA, JMS, Java, qpid > Fix For: 0.14 > > > Currently there is no way to integrate the use of Qpid messaging into a Java > Application Server. > The solution is to create a JCA (J2EE Connector Architecture) adapter to allow > the Qpid JMS client to correctly work with the J2EE container. > This is an entirely new Java component, but may require small amounts of > change to the > JMS client code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3309) Management broker object port is not set if broker started with port number set to 0
[ https://issues.apache.org/jira/browse/QPID-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3309: -- Fix Version/s: 0.14 > Management broker object port is not set if broker started with port number > set to 0 > > > Key: QPID-3309 > URL: https://issues.apache.org/jira/browse/QPID-3309 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.13 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: 0.14 > > > The management broker object has a port attribute which is set to the value > passed to the broker when it is started. If the value of port is zero, then > the broker will use an unused port number and return this number on the > command line. However, the broker management object is not updated, and > returns a value of 0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3348) Qmf broker proxy method create() does not handle keyword arguments, only regular parameters
[
https://issues.apache.org/jira/browse/QPID-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-3348:
--
Fix Version/s: 0.14
> Qmf broker proxy method create() does not handle keyword arguments, only
> regular parameters
> ---
>
> Key: QPID-3348
> URL: https://issues.apache.org/jira/browse/QPID-3348
> Project: Qpid
> Issue Type: Bug
>Affects Versions: 0.13
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.14
>
>
> The Qmf management methods defined in the management-schema.xml file are
> implemented through the console Object class __getattr__() method. This calls
> Object.invoke(), which in turn calls Object._sendMethodRequest().
> However, the implementation of _sendMethodRequest() accounts only for regular
> arguments in the args parameter, and ignores the kwargs parameter. Hence, the
> call to the create() call:
>
>
>
>
>
>
> as follows:
> broker_proxy.create("exchange", name, props, True)
> will work, but
> broker_proxy.create(type="exchange", name=name, properties=props, strict=True)
> will fail (Exception: Incorrect number of arguments: expected 4, got 0).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3409) Allow use of IPv6 literal addresses in python/qmf tools (for federation etc.)
Allow use of IPv6 literal addresses in python/qmf tools (for federation etc.) - Key: QPID-3409 URL: https://issues.apache.org/jira/browse/QPID-3409 Project: Qpid Issue Type: Sub-task Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3418) FreeBSD 8.2 port for Apache Qpid 0.10
[ https://issues.apache.org/jira/browse/QPID-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085113#comment-13085113 ] Andrew Stitcher commented on QPID-3418: --- Some small points: The shar format (although hallowed by unix history) is probably not the most accessible to most people any more, if you could use zip or tgz it would be easier to inspect your patches. As to the patches: They are wrong! (at least in the context of current use of the nss library). You are actually supposed to include the headers in the way we do it - I know this is silly, annoying, not the way _you_ would have done it etc. but this is necessary. Unfortunately half the distributions use nss as a top level include directory and half use nss3. So you need to change the include path to find the unadorned include file names. In the current cmake/autoconfig files we use either the built in cmake rules or pkgconfig --cflags nss. Given that nss usually comes with pkgconfig descriptors you might investigate why you didn't pick them up on your freebsd build. > FreeBSD 8.2 port for Apache Qpid 0.10 > - > > Key: QPID-3418 > URL: https://issues.apache.org/jira/browse/QPID-3418 > Project: Qpid > Issue Type: New Feature > Components: Packaging >Affects Versions: 0.10 > Environment: FreeBSD minotaur.apache.org 8.2-RELEASE FreeBSD > 8.2-RELEASE #0 r219081M: Wed Mar 2 08:29:52 CET 2011 > root@www4:/usr/obj/usr/src/sys/GENERIC amd64 >Reporter: Daniel S. Haischt > Labels: build > Fix For: Future > > Attachments: qpid.shar > > > Please find attached FreeBSD port descriptor files for Apache Qpid. They were > created on a FreeBSD 8.2 64-bit system and contain already some patches in > the files directory to make Apache Qpid compile on FreeBSD. > I stopped my porting efforts at a point where I became aware of JIRA > QPID-2549 and discussed how to proceed further on the Apache Qpid ML [2]. > [1] https://issues.apache.org/jira/browse/QPID-2549 > [2] > http://mail-archives.apache.org/mod_mbox/qpid-dev/201108.mbox/%3CCAC0wh9ZjuK0Ns_2LnAbM=oufhcg2gavsb99+pkpuybrtr6k...@mail.gmail.com%3E -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3447) Creating invalid federation link causes file descriptor leak
[ https://issues.apache.org/jira/browse/QPID-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-3447: - Assignee: Andrew Stitcher > Creating invalid federation link causes file descriptor leak > > > Key: QPID-3447 > URL: https://issues.apache.org/jira/browse/QPID-3447 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.10 >Reporter: Pavel Moravec >Assignee: Andrew Stitcher > Labels: patch > Attachments: fd_leak.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Specifying invalid IP address of destination broker causes repeatable file > descriptor leak. > Steps to Reproduce: > 1. qpid-route -v link add localhost 10:17700 > (alternativelly, create a dynamic route likeqpid-route dynamic add > localhost 10:17700 amq.direct ) > 2. lsof -p $(pgrep qpidd) | grep "can't identify protocol" > Since then, lsof will show "can't identify protocol" file descriptors whose > number is increasing in time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3447) Creating invalid federation link causes file descriptor leak
[ https://issues.apache.org/jira/browse/QPID-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3447. --- Resolution: Fixed Fix Version/s: 0.13 > Creating invalid federation link causes file descriptor leak > > > Key: QPID-3447 > URL: https://issues.apache.org/jira/browse/QPID-3447 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.10 >Reporter: Pavel Moravec >Assignee: Andrew Stitcher > Labels: patch > Fix For: 0.13 > > Attachments: fd_leak.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Specifying invalid IP address of destination broker causes repeatable file > descriptor leak. > Steps to Reproduce: > 1. qpid-route -v link add localhost 10:17700 > (alternativelly, create a dynamic route likeqpid-route dynamic add > localhost 10:17700 amq.direct ) > 2. lsof -p $(pgrep qpidd) | grep "can't identify protocol" > Since then, lsof will show "can't identify protocol" file descriptors whose > number is increasing in time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3447) Creating invalid federation link causes file descriptor leak
[ https://issues.apache.org/jira/browse/QPID-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089061#comment-13089061 ] Andrew Stitcher commented on QPID-3447: --- Note the attached fix is not the fix that was applied as it only ameliorates the symptom of running out of file handles rather than fixing the underlying Socket leak. > Creating invalid federation link causes file descriptor leak > > > Key: QPID-3447 > URL: https://issues.apache.org/jira/browse/QPID-3447 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.10 >Reporter: Pavel Moravec >Assignee: Andrew Stitcher > Labels: patch > Fix For: 0.13 > > Attachments: fd_leak.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Specifying invalid IP address of destination broker causes repeatable file > descriptor leak. > Steps to Reproduce: > 1. qpid-route -v link add localhost 10:17700 > (alternativelly, create a dynamic route likeqpid-route dynamic add > localhost 10:17700 amq.direct ) > 2. lsof -p $(pgrep qpidd) | grep "can't identify protocol" > Since then, lsof will show "can't identify protocol" file descriptors whose > number is increasing in time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3464) Fix QPID Build on Debian Squeeze
[ https://issues.apache.org/jira/browse/QPID-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099016#comment-13099016 ] Andrew Stitcher commented on QPID-3464: --- I note that the diffs seem to be against 0.10 so there is some chance they don't apply cleanly against trunk. [BTW it would probably be easier to review these changes if you made a review board review as I'd get a bit more context there] Specifically I'm a little unclear about some of the cmake changes: * Introduced a help2man build in docs/man (and done a neat jobs of it) however we've actually stopped doing this build entirely from our current build. However it's unfortunately not removed completely yet though so this work isn't currently useful to us. * Removed Boost libs from the detection list that are required on windows even though they are not required on unix - there is even a comment just above explaining this. * This change: - else (CMAKE_SYSTEM_NAME STREQUAL Windows) + else (CMAKE_SYSTEM_NAME STREQUAL Linux) In ssl.cmake just looks wrong to me and I wonder if its ever been run, as it should make cmake give an error (CMake cares about matching the "if" parameters with the "else" parameters and gives an error if they don't match but the corresponding "if" hasn't changed. * Added unconditional pragmas into the code to deal with warnings from the boost library, but this must either depend on boost version or the compiler version and so should be much more tightly constrained with appropriate ifdefs and comments that explain when you need to turn these warnings off. And preferably they should be turned off only for the shortest time that's necessary - I suspect it's a template instantiation that causes the problem so this might be hard. Having made these detailed comments, on the whole this is a very good piece of work and neatens some things a lot. It looks like it moves in the direction of cmake build parity too which is a big plus. > Fix QPID Build on Debian Squeeze > > > Key: QPID-3464 > URL: https://issues.apache.org/jira/browse/QPID-3464 > Project: Qpid > Issue Type: Improvement > Components: Build Tools >Affects Versions: 0.12 > Environment: Debian Squeeze >Reporter: Jan-Marek Glogowski >Priority: Minor > Attachments: 01_build-libqmfengine-before-libqmf.diff, > 02_configure.ac-fix-polling-detection.diff, > 03_install-python-libs-into-PYTHON_LIB.diff, > 04_reorganize-automake-qpid-perl-bindings-build.diff, > 05_cleanup-cmake-build.diff, 06_fix-ignored-return-value-warnings.diff > > > I'm using serveral patches to build QPID on Debian Squeeze. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3464) Fix QPID Build on Debian Squeeze
[ https://issues.apache.org/jira/browse/QPID-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099026#comment-13099026 ] Andrew Stitcher edited comment on QPID-3464 at 9/7/11 3:25 PM: --- In the 06 patch there are a number of uses of strerror(): * the project standard is to use :: to preface global library calls (to disambiguate them from any local meaning of the function name), BUT * strerror() is not thread safe so we have an internal thread safe strError() function that we use instead - you should use this. was (Author: astitcher): In the 06 patch there ar ea number of uses of strerror(): * the project standard is to use :: to preface global library calls (to disambiguate them from any local meaning of the function name), BUT * strerror() is not thread safe so we have an internal thread safe strError() function that we use instead - you should use this. > Fix QPID Build on Debian Squeeze > > > Key: QPID-3464 > URL: https://issues.apache.org/jira/browse/QPID-3464 > Project: Qpid > Issue Type: Improvement > Components: Build Tools >Affects Versions: 0.12 > Environment: Debian Squeeze >Reporter: Jan-Marek Glogowski >Priority: Minor > Attachments: 01_build-libqmfengine-before-libqmf.diff, > 02_configure.ac-fix-polling-detection.diff, > 03_install-python-libs-into-PYTHON_LIB.diff, > 04_reorganize-automake-qpid-perl-bindings-build.diff, > 05_cleanup-cmake-build.diff, 06_fix-ignored-return-value-warnings.diff > > > I'm using serveral patches to build QPID on Debian Squeeze. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3464) Fix QPID Build on Debian Squeeze
[ https://issues.apache.org/jira/browse/QPID-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099026#comment-13099026 ] Andrew Stitcher commented on QPID-3464: --- In the 06 patch there ar ea number of uses of strerror(): * the project standard is to use :: to preface global library calls (to disambiguate them from any local meaning of the function name), BUT * strerror() is not thread safe so we have an internal thread safe strError() function that we use instead - you should use this. > Fix QPID Build on Debian Squeeze > > > Key: QPID-3464 > URL: https://issues.apache.org/jira/browse/QPID-3464 > Project: Qpid > Issue Type: Improvement > Components: Build Tools >Affects Versions: 0.12 > Environment: Debian Squeeze >Reporter: Jan-Marek Glogowski >Priority: Minor > Attachments: 01_build-libqmfengine-before-libqmf.diff, > 02_configure.ac-fix-polling-detection.diff, > 03_install-python-libs-into-PYTHON_LIB.diff, > 04_reorganize-automake-qpid-perl-bindings-build.diff, > 05_cleanup-cmake-build.diff, 06_fix-ignored-return-value-warnings.diff > > > I'm using serveral patches to build QPID on Debian Squeeze. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3464) Fix QPID Build on Debian Squeeze
[ https://issues.apache.org/jira/browse/QPID-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099028#comment-13099028 ] Andrew Stitcher commented on QPID-3464: --- The poller selection patch (02): I like the changes however I think they are based on a small misunderstanding: At present the poll based poller does not exist - it has long been suggested as a fallback poller for posix based systems but never been actually implemented, so unhappily it needs to be commented out from actually being detected. Actually I don't think the Solaris ecf poller actually works although there is bit rotted code in the tree for it. > Fix QPID Build on Debian Squeeze > > > Key: QPID-3464 > URL: https://issues.apache.org/jira/browse/QPID-3464 > Project: Qpid > Issue Type: Improvement > Components: Build Tools >Affects Versions: 0.12 > Environment: Debian Squeeze >Reporter: Jan-Marek Glogowski >Priority: Minor > Attachments: 01_build-libqmfengine-before-libqmf.diff, > 02_configure.ac-fix-polling-detection.diff, > 03_install-python-libs-into-PYTHON_LIB.diff, > 04_reorganize-automake-qpid-perl-bindings-build.diff, > 05_cleanup-cmake-build.diff, 06_fix-ignored-return-value-warnings.diff > > > I'm using serveral patches to build QPID on Debian Squeeze. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3473) [Java] Replace use of MINA IO with IO layer developed for the Java 0-10 client
[ https://issues.apache.org/jira/browse/QPID-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099159#comment-13099159 ] Andrew Stitcher commented on QPID-3473: --- Is there an open jira to track the final demise of Mina? I'm very keen on this work for similar reasons to Rajith. More directly to do with the JCA Adapter. if that work is targetted for 0.14 that would make me very happy. > [Java] Replace use of MINA IO with IO layer developed for the Java 0-10 client > -- > > Key: QPID-3473 > URL: https://issues.apache.org/jira/browse/QPID-3473 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common, Java Tests >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: 0.14 > > > Historically the Java client (when using non 0-10 versions on AMQP) and the > Java Broker have used (a very old version of) MINA to provide the IO > transport. There are fundamental issues when using MINA in the way we have > been using it, and as such we have undertaken a lot of work to properly > abstract the definition of a transport layer and allow for alternatives. > Now that the abstraction work has been completed we can replace the use of > MINA with the IO layer that was developed for the 0-10 client. As a separate > JIRA we should replace the final dependency we have on MINA in terms of the > use of their expandable ByteBuffer. > We may decide to implement a new transport based on a current version of MINA > in the future, but if doing so we should ensure to keep within the > abstractions now defined). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3464) Fix QPID Build on Debian Squeeze
[ https://issues.apache.org/jira/browse/QPID-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-3464: - Assignee: Andrew Stitcher > Fix QPID Build on Debian Squeeze > > > Key: QPID-3464 > URL: https://issues.apache.org/jira/browse/QPID-3464 > Project: Qpid > Issue Type: Improvement > Components: Build Tools >Affects Versions: 0.12 > Environment: Debian Squeeze >Reporter: Jan-Marek Glogowski >Assignee: Andrew Stitcher >Priority: Minor > Attachments: 01_build-libqmfengine-before-libqmf.diff, > 02_configure.ac-fix-polling-detection.diff, > 03_install-python-libs-into-PYTHON_LIB.diff, > 04_reorganize-automake-qpid-perl-bindings-build.diff, > 05_cleanup-cmake-build.diff, 06_fix-ignored-return-value-warnings.diff, > 07_fixes_based_on_jira_comments.diff > > > I'm using serveral patches to build QPID on Debian Squeeze. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3944) Autotools build system doesn't correctly detect python developer libraries
[ https://issues.apache.org/jira/browse/QPID-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3944. --- Resolution: Fixed Fix Version/s: 0.16 > Autotools build system doesn't correctly detect python developer libraries > -- > > Key: QPID-3944 > URL: https://issues.apache.org/jira/browse/QPID-3944 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: 0.15, 0.16 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.16, 0.17 > > > A change made for 0.15 as part of QPID-3464 broke the autotools python > developer libraries/headers detection logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-2518) Qpid C++ broker can easily be blocked by client trying to connect over SSL port
[ https://issues.apache.org/jira/browse/QPID-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273591#comment-13273591 ] Andrew Stitcher commented on QPID-2518: --- This bug also applies to regular TCP connections > Qpid C++ broker can easily be blocked by client trying to connect over SSL > port > --- > > Key: QPID-2518 > URL: https://issues.apache.org/jira/browse/QPID-2518 > Project: Qpid > Issue Type: Bug > Components: C++ Broker > Environment: Red Hat Enterprise MRG 1.2 >Reporter: Armin Noll >Assignee: Andrew Stitcher > > We are running a C++ broker as deamon with the following configuration: > > log-enable=info+ > log-to-file=/var/lib/qpidd/op_prod09/data/0097/qpidd.log > log-to-syslog=no > auth=yes > acl-file=qpidd.acl > realm=QPID0097 > data-dir=/var/lib/qpidd/op_prod09/data/0097 > pid-dir=/var/lib/qpidd/op_prod09/data/0097 > port=20097 > wait=30 > num-jfiles=4 > jfile-size-pgs=1 > wcache-page-size=128 > tpl-num-jfiles=4 > tpl-jfile-size-pgs=1 > tpl-wcache-page-size=128 > ssl-cert-db=/var/lib/qpidd/op_prod09/data/0097 > ssl-port=10097 > ssl-cert-name=RGC001 > ssl-cert-password-file=/var/lib/qpidd/op_prod09/data/0097/amq_cert_db.pwd > ssl-require-client-authentication=yes > cluster-name=QPID0097 > cluster-url=amqp:tcp:172.16.45.198:20097 > cluster-username=x > cluster-password=x > > We tried to connect an application to the SSL port which does not "talk" the > correct protocol. We simply used telnet: > $ telnet 172.16.45.198 10097 > > The result was (we waited at least 30 min, then killed the process running > telnet): > The broker doesn't react anymore, no more new client connections can be > established, the broker even cannot be stopped with "qpidd -p 20097 -q". > > This way anybody in the world could easily block our service provided over a > Qpid broker. > Is there a way to get around this? > This issue has also been reported as Red Hat service request no. 2014266. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-2518) Qpid C++ broker can easily be blocked by client trying to connect over SSL port
[ https://issues.apache.org/jira/browse/QPID-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reopened QPID-2518: --- Assignee: Andrew Stitcher As far as I can tell this bug is still present. Despite any comments above. > Qpid C++ broker can easily be blocked by client trying to connect over SSL > port > --- > > Key: QPID-2518 > URL: https://issues.apache.org/jira/browse/QPID-2518 > Project: Qpid > Issue Type: Bug > Components: C++ Broker > Environment: Red Hat Enterprise MRG 1.2 >Reporter: Armin Noll >Assignee: Andrew Stitcher > > We are running a C++ broker as deamon with the following configuration: > > log-enable=info+ > log-to-file=/var/lib/qpidd/op_prod09/data/0097/qpidd.log > log-to-syslog=no > auth=yes > acl-file=qpidd.acl > realm=QPID0097 > data-dir=/var/lib/qpidd/op_prod09/data/0097 > pid-dir=/var/lib/qpidd/op_prod09/data/0097 > port=20097 > wait=30 > num-jfiles=4 > jfile-size-pgs=1 > wcache-page-size=128 > tpl-num-jfiles=4 > tpl-jfile-size-pgs=1 > tpl-wcache-page-size=128 > ssl-cert-db=/var/lib/qpidd/op_prod09/data/0097 > ssl-port=10097 > ssl-cert-name=RGC001 > ssl-cert-password-file=/var/lib/qpidd/op_prod09/data/0097/amq_cert_db.pwd > ssl-require-client-authentication=yes > cluster-name=QPID0097 > cluster-url=amqp:tcp:172.16.45.198:20097 > cluster-username=x > cluster-password=x > > We tried to connect an application to the SSL port which does not "talk" the > correct protocol. We simply used telnet: > $ telnet 172.16.45.198 10097 > > The result was (we waited at least 30 min, then killed the process running > telnet): > The broker doesn't react anymore, no more new client connections can be > established, the broker even cannot be stopped with "qpidd -p 20097 -q". > > This way anybody in the world could easily block our service provided over a > Qpid broker. > Is there a way to get around this? > This issue has also been reported as Red Hat service request no. 2014266. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-4004) qpid::framing::Buffer::Iterator not very useful
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-4004: - Assignee: Andrew Stitcher > qpid::framing::Buffer::Iterator not very useful > --- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4004) qpid::framing::Buffer::Iterator not very useful
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277073#comment-13277073 ] Andrew Stitcher commented on QPID-4004: --- There are a few bits of cruft in the Buffer class and interface: * This iterator which actually isn't used by any current code * record() and restore() member functions which are aren't really safe to use. [The Buffer class doesn't keep a stack of recorded locations, so you can't perform any function calls that might themselves do record()/restore()] This makes it hard to reason about locally, and hard to ensure globally. > qpid::framing::Buffer::Iterator not very useful > --- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4004) Cruft in qpid::framing::Buffer class should be removed
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4004: -- Summary: Cruft in qpid::framing::Buffer class should be removed (was: qpid::framing::Buffer::Iterator not very useful) > Cruft in qpid::framing::Buffer class should be removed > -- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4004) Cruft in qpid::framing::Buffer class should be removed
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4004. --- Resolution: Fixed Fix Version/s: 0.17 > Cruft in qpid::framing::Buffer class should be removed > -- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > Fix For: 0.17 > > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4005) Eliminate "using" especially "using namespace" from header file
Andrew Stitcher created QPID-4005: - Summary: Eliminate "using" especially "using namespace" from header file Key: QPID-4005 URL: https://issues.apache.org/jira/browse/QPID-4005 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Priority: Minor The using declaration is generally unsuitable for use in header files as it affects the namespace of any file including that header file. This can make the C++ build unstable under code maintenance. We should remove using and using namespace from header files and replace it where necessary in the C++ source files that previously relied on the declaration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4005) Eliminate "using" especially "using namespace" from header file
[
https://issues.apache.org/jira/browse/QPID-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277207#comment-13277207
]
Andrew Stitcher commented on QPID-4005:
---
There is really a hierarchy of badness here:
Worst:
"using namespace" In the global scope of a header file - This pollutes the
namespace of any using source file.
"using " In the global scope of a header file - This may cause
some unexpected symbol resolution which will be affected by which header files
are included - tricky to diagnose if it happens.
These previous are especially bad if they are in exported headers because they
affect programs which merely use a qpid library.
Bad:
"
namespace qpid { ... using ...;
"
This can still cause the above problems and confusions to qpid developers but
at least have little to no chance of confusing library users.
Probably not actually harmful:
Using "using ... " inside a block scope generated by a macro in a header file.
Questionable from a taste point of view, but can't pollute anyone elses
namespace.
> Eliminate "using" especially "using namespace" from header file
> ---
>
> Key: QPID-4005
> URL: https://issues.apache.org/jira/browse/QPID-4005
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker, C++ Client
>Reporter: Andrew Stitcher
>Priority: Minor
>
> The using declaration is generally unsuitable for use in header files as it
> affects the namespace of any file including that header file.
> This can make the C++ build unstable under code maintenance.
> We should remove using and using namespace from header files and replace it
> where necessary in the C++ source files that previously relied on the
> declaration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] Commented: (QPID-1834) Misconfiguration of config path for Debian libsasl2-2 (SASL support)
[ https://issues.apache.org/jira/browse/QPID-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705024#action_12705024 ] Andrew Stitcher commented on QPID-1834: --- It looks to me that this would be best addressed during package configuration (autoconf/cmake). In fact Makefile.in is already generated by automake so there must be a modicum of work in this direction, perhaps it's just the default configuration that's wrong. > Misconfiguration of config path for Debian libsasl2-2 (SASL support) > > > Key: QPID-1834 > URL: https://issues.apache.org/jira/browse/QPID-1834 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: M4 > Environment: Debian "squeeze" >Reporter: Garrett Smith > > The libsasl2-2 package is configured with the option: > --with-configdir=/etc/sasl:/usr/lib/sasl2 > Background on this decision can be found here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211156 > cpp/etc/Makefile.in specifies SASL_CONF as /etc/sasl2, which isn't on the > config path that the Debian package is compiled with. The result is that the > qpid sasl configuration is never used. This is a pain to debug as the missed > configuration is silently ignored. > I'm not sure what the ideal solution is here, but I think this ought to be > addressed given we're talking about Debian. > A config option for qpidd would probably be appropriate, or, in keeping with > the hard coding strategy, create a link from /etc/sasl to /etc/sasl2. Just a > couple ideas though. -- 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-1842) QMF-generated code doesn't export symbols
[ https://issues.apache.org/jira/browse/QPID-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706597#action_12706597 ] Andrew Stitcher commented on QPID-1842: --- I think the easiest solution in fact would be just to create the acl module as a static library in windows and link directly to the broker code in windows. This works because the acl code is disabled separately from just not being loaded. Actually the acl module is unusual in that it an optional part of the broker rather than being a plugin like the other plugins > QMF-generated code doesn't export symbols > - > > Key: QPID-1842 > URL: https://issues.apache.org/jira/browse/QPID-1842 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework > Environment: Windows, Visual Studio >Reporter: Steve Huston > > The C++ ACL plugin fails to link on Windows because the needed QMF-generated > symbols built into the broker library are not exported. > It is possible, with little trouble, to change the qmf-gen templates to > generate the proper export declarations; however, this would cause all > generated symbols to be exported, not just the ACL-related ones. This is not > necessarily a bad thing, but I'm open to more ideas on how to accomplish this. > The wide-ranging nature of the code gen was hinted at in QPID-1274. So that's > possibly something to consider. > If I don't hear objections within a day or two, I'll go ahead and add the > exports to all generated symbols. -- 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-1842) QMF-generated code doesn't export symbols
[ https://issues.apache.org/jira/browse/QPID-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707364#action_12707364 ] Andrew Stitcher commented on QPID-1842: --- I don't think SELinux is supported on Windows, so this workaround won't affect any other work going on. In the long term we need a proper solution, but the current situation is that broker acls can't be used on Windows. The long term solution is to tidy up the plugin interface/qmf interface so it doesn't have this issue. > QMF-generated code doesn't export symbols > - > > Key: QPID-1842 > URL: https://issues.apache.org/jira/browse/QPID-1842 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework > Environment: Windows, Visual Studio >Reporter: Steve Huston > > The C++ ACL plugin fails to link on Windows because the needed QMF-generated > symbols built into the broker library are not exported. > It is possible, with little trouble, to change the qmf-gen templates to > generate the proper export declarations; however, this would cause all > generated symbols to be exported, not just the ACL-related ones. This is not > necessarily a bad thing, but I'm open to more ideas on how to accomplish this. > The wide-ranging nature of the code gen was hinted at in QPID-1274. So that's > possibly something to consider. > If I don't hear objections within a day or two, I'll go ahead and add the > exports to all generated symbols. -- 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-1842) QMF-generated code doesn't export symbols
[ https://issues.apache.org/jira/browse/QPID-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708195#action_12708195 ] Andrew Stitcher commented on QPID-1842: --- With the most recent changes the only symbols that still fail are in the qmf::org::apache::qpid::acl namespace. (After some discussion with tross) I think that what should be happening (but isn't currently) is that the qmf generated code in this namespace should be linked in with the acl module itself. As fas as I can understand these symbols aren't used outside the acl module anyway. The way to do this is to modify the managment.mk/.cmake files to split the list of cpp files along namespace lines just as the .h files are split then they could be included in different lists in CMakefile.txt/Makefile.am Any other commetns Ted? > QMF-generated code doesn't export symbols > - > > Key: QPID-1842 > URL: https://issues.apache.org/jira/browse/QPID-1842 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework > Environment: Windows, Visual Studio >Reporter: Steve Huston > > The C++ ACL plugin fails to link on Windows because the needed QMF-generated > symbols built into the broker library are not exported. > It is possible, with little trouble, to change the qmf-gen templates to > generate the proper export declarations; however, this would cause all > generated symbols to be exported, not just the ACL-related ones. This is not > necessarily a bad thing, but I'm open to more ideas on how to accomplish this. > The wide-ranging nature of the code gen was hinted at in QPID-1274. So that's > possibly something to consider. > If I don't hear objections within a day or two, I'll go ahead and add the > exports to all generated symbols. -- 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-1847) The framing codec code for clustering is linked into qpidcommon
The framing codec code for clustering is linked into qpidcommon --- Key: QPID-1847 URL: https://issues.apache.org/jira/browse/QPID-1847 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: M4 Reporter: Andrew Stitcher Priority: Minor This would make sense if qpid common was a ststic library in which case it would only be picked up by the module that wants it (cluster.so). but currently it gets build into every broker and client which makes them significantly larger than they need to be. This is particularly so for the Windows port as the cluster framing code gets built in even though we don't support any clustering on windows. -- 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-1847) The framing codec code for clustering is linked into qpidcommon
[ https://issues.apache.org/jira/browse/QPID-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708226#action_12708226 ] Andrew Stitcher commented on QPID-1847: --- When I say built into every broker and client I don't mean at link time, but rather that the resident code at run time is larger because of this unnecessary code. > The framing codec code for clustering is linked into qpidcommon > --- > > Key: QPID-1847 > URL: https://issues.apache.org/jira/browse/QPID-1847 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Affects Versions: M4 >Reporter: Andrew Stitcher >Priority: Minor > > This would make sense if qpid common was a ststic library in which case it > would only be picked up by the module that wants it (cluster.so). but > currently it gets build into every broker and client which makes them > significantly larger than they need to be. > This is particularly so for the Windows port as the cluster framing code gets > built in even though we don't support any clustering on windows. -- 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-1852) Logger::log isn't thread safe (by inspection)
Logger::log isn't thread safe (by inspection) - Key: QPID-1852 URL: https://issues.apache.org/jira/browse/QPID-1852 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: Andrew Stitcher Assignee: Andrew Stitcher In source file cpp/src/qpid/log/Logger.h Logger::log() uses the function localtime which is not thread saf localtime() needs to be replaced with localtime_r() for threadsafety. Incidentally sprintf() and most of the rest of the function can be replaced with strftime(). -- 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-1852) Logger::log isn't thread safe (by inspection)
[ https://issues.apache.org/jira/browse/QPID-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-1852. --- Resolution: Fixed > Logger::log isn't thread safe (by inspection) > - > > Key: QPID-1852 > URL: https://issues.apache.org/jira/browse/QPID-1852 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: M4 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Original Estimate: 2h > Remaining Estimate: 2h > > In source file cpp/src/qpid/log/Logger.h Logger::log() uses the function > localtime which is not thread saf > localtime() needs to be replaced with localtime_r() for threadsafety. > Incidentally sprintf() and most of the rest of the function can be replaced > with strftime(). -- 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-1198) Changes for the solaris port
[ https://issues.apache.org/jira/browse/QPID-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709073#action_12709073 ] Andrew Stitcher commented on QPID-1198: --- Is this bug now closed re M5? Does M5 compile/run on Solaris? Manuel can you elucidate? > Changes for the solaris port > > > Key: QPID-1198 > URL: https://issues.apache.org/jira/browse/QPID-1198 > Project: Qpid > Issue Type: New Feature > Components: C++ Broker >Affects Versions: M4 >Reporter: Manuel Teira >Assignee: Andrew Stitcher > Fix For: 0.5 > > Attachments: acl.patch, ecfpoller-refactoring.patch, > localaddrs.patch, solaris-port.patch, syslog-feature-test.patch > > > Patch with changes needed to have the project compiling under Sun Studio 12, > on a Solaris Sparc machine. Tests are also passing. > This patch summarizes all the changes in my local copy, including those from > the non-resolved jira issues: QPID-1132 and QPID-1133. > Other changes are: > 1.- Missing include files > 2.- Some GNUishms in system calls. I think there're two cases for this: >2.1.- POSIX strerror_r doesn't return the buffer. >2.2. - pthread_yield is not POSIX compliant. Using sched_yield instead. > 3.- No FTP and LOG_FTP syslog categories on Solaris. > 4.- The private inheritance bug in the solaris compiler > 5.- The Uuid.h solaris non-const members. > 6.- Some explicit namespacing. In some parts of the code. > 7.- Replace all the u_intN_t typenames with uintN_t typenames. > 8.- The queue issue. Name already used in solaris system headers. > 9.-Some minor bashisms in scripts, complaining under pure sh shells. -- 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-1868) Implicit TLS variables in AsyncIO can cause access violation when dynamically loading qpidcommon and qpidclient DLLs
[ https://issues.apache.org/jira/browse/QPID-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711741#action_12711741 ] Andrew Stitcher commented on QPID-1868: --- As noted on the devlist (dev@qpid.apache.org) these thread locals vars are not used overall in the functioning of the windows port IO. So they could be removed entirely, which would make a much simpler fix. However qpid definitely contains some other thread local usage (though possibly not in the windows port) and this issue would occur there. Of course we could just say anything prior to Vista/Win 2008 is not supported! > Implicit TLS variables in AsyncIO can cause access violation when dynamically > loading qpidcommon and qpidclient DLLs > > > Key: QPID-1868 > URL: https://issues.apache.org/jira/browse/QPID-1868 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: 0.5 > Environment: Windows XP w/SP3 > Visual Studio 2005 >Reporter: David Rennalls > Attachments: AsyncIO_TLS.patch > > > src/qpid/sys/windows/AsynchIO.cpp is using some implicit thread local storage > variables. If the qpid DLLs are dynamically loaded (or another DLL that > statically links in qpid) no space will be allocated for the TLS data. So if > client code tries to access one of the TLS variables defined in AsyncIO.cpp > it will get an access violation. Taken from [1]... > "..If a DLL declares any nonlocal data or object as __declspec( thread ), it > can cause a protection fault if dynamically loaded. After the DLL is loaded > with LoadLibrary, it causes system failure whenever the code references the > nonlocal __declspec( thread ) data. Because the global variable space for a > thread is allocated at run time, the size of this space is based on a > calculation of the requirements of the application plus the requirements of > all of the DLLs that are statically linked. When you use LoadLibrary, there > is no way to extend this space to allow for the thread local variables > declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in > your DLL to allocate TLS if the DLL might be loaded with LoadLibrary..." > ...[2] also warns against this.. > "Windows Server 2003 and Windows XP: The Visual C++ compiler supports a > syntax that enables you to declare thread-local variables: _declspec(thread). > If you use this syntax in a DLL, you will not be able to load the DLL > explicitly using LoadLibrary on versions of Windows prior to Windows Vista. > If your DLL will be loaded explicitly, you must use the thread local storage > functions instead of _declspec(thread)." > I ran into this when my DLL that links in qpid client and common libs > statically is loaded dynamically by a python wrapper, the first access to the > one of the TLS variables cause a crash. For reference , [3] (part 1 of 8) has > a good overview of TLS on Windows, and implicit vs explicit TLS > [1] http://msdn.microsoft.com/en-us/library/2s9wt68x(vs.71).aspx - Rules and > Limitations for TLS > [2] http://msdn.microsoft.com/en-us/library/ms684175.aspx - LoadLibrary > function > [3] http://www.nynaeve.net/?p=180 - Thread Local Storage, part 1: Overview -- 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-1868) Implicit TLS variables in AsyncIO can cause access violation when dynamically loading qpidcommon and qpidclient DLLs
[ https://issues.apache.org/jira/browse/QPID-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711841#action_12711841 ] Andrew Stitcher commented on QPID-1868: --- This is a good direction, but please don't introduce boost::thread related stuff directly into the code, it should be abstracted in the platform specific area. The Unix ports do not use much in the way of boost libraries and I'm trying to reduce the dependencies in the application code not increase it. This is because boost library dependencies are a packaging nightmare, as boost doesn't maintain their previous releases at all. I'm happy for the individual ports to rely on it if they like though as this issue may be different on Windows etc. I suppose we need a "proper" way to do portable thread local vars so we'll need to introduce an abstraction or at least an indirection in qpid/sys. > Implicit TLS variables in AsyncIO can cause access violation when dynamically > loading qpidcommon and qpidclient DLLs > > > Key: QPID-1868 > URL: https://issues.apache.org/jira/browse/QPID-1868 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: 0.5 > Environment: Windows XP w/SP3 > Visual Studio 2005 >Reporter: David Rennalls > Attachments: AsyncIO_TLS.patch, patch.txt > > > src/qpid/sys/windows/AsynchIO.cpp is using some implicit thread local storage > variables. If the qpid DLLs are dynamically loaded (or another DLL that > statically links in qpid) no space will be allocated for the TLS data. So if > client code tries to access one of the TLS variables defined in AsyncIO.cpp > it will get an access violation. Taken from [1]... > "..If a DLL declares any nonlocal data or object as __declspec( thread ), it > can cause a protection fault if dynamically loaded. After the DLL is loaded > with LoadLibrary, it causes system failure whenever the code references the > nonlocal __declspec( thread ) data. Because the global variable space for a > thread is allocated at run time, the size of this space is based on a > calculation of the requirements of the application plus the requirements of > all of the DLLs that are statically linked. When you use LoadLibrary, there > is no way to extend this space to allow for the thread local variables > declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in > your DLL to allocate TLS if the DLL might be loaded with LoadLibrary..." > ...[2] also warns against this.. > "Windows Server 2003 and Windows XP: The Visual C++ compiler supports a > syntax that enables you to declare thread-local variables: _declspec(thread). > If you use this syntax in a DLL, you will not be able to load the DLL > explicitly using LoadLibrary on versions of Windows prior to Windows Vista. > If your DLL will be loaded explicitly, you must use the thread local storage > functions instead of _declspec(thread)." > I ran into this when my DLL that links in qpid client and common libs > statically is loaded dynamically by a python wrapper, the first access to the > one of the TLS variables cause a crash. For reference , [3] (part 1 of 8) has > a good overview of TLS on Windows, and implicit vs explicit TLS > [1] http://msdn.microsoft.com/en-us/library/2s9wt68x(vs.71).aspx - Rules and > Limitations for TLS > [2] http://msdn.microsoft.com/en-us/library/ms684175.aspx - LoadLibrary > function > [3] http://www.nynaeve.net/?p=180 - Thread Local Storage, part 1: Overview -- 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-1879) The client library uses a new thread for every connection
The client library uses a new thread for every connection - Key: QPID-1879 URL: https://issues.apache.org/jira/browse/QPID-1879 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: M4, M3, M2.1, M2, M1, 0.5 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.6 This is actually slightly worse than just using a new thread per broker connection as it also uses a new Poller for every Connection and the Poller is fairly hefty and includes a number of fds for its own use. This multiplies the client fd use for clients with many Connections. It's not really acceptable that opening 1000 connections should create 1000 threads. It should be noted that this isn't the only aspect of the client library that uses excessive numbers of threads, lets knock them off one by one -- 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-1879) The client library uses a new thread for every connection
[ https://issues.apache.org/jira/browse/QPID-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-1879. --- Resolution: Fixed Don't use a thread for every new client Connection - By default the max number of threads now used for network io is the number of cpus available. - This can be overridden with the QPID_MAX_IOTHREADS environment variable or the config file > The client library uses a new thread for every connection > - > > Key: QPID-1879 > URL: https://issues.apache.org/jira/browse/QPID-1879 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: M1, M2, M2.1, M3, M4, 0.5 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.6 > > > This is actually slightly worse than just using a new thread per broker > connection as it also uses a new Poller for every Connection and the Poller > is fairly hefty and includes a number of fds for its own use. This multiplies > the client fd use for clients with many Connections. > It's not really acceptable that opening 1000 connections should create 1000 > threads. > It should be noted that this isn't the only aspect of the client library that > uses excessive numbers of threads, lets knock them off one by one -- 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-1904) Timestamps are incorrect
[ https://issues.apache.org/jira/browse/QPID-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734139#action_12734139 ] Andrew Stitcher commented on QPID-1904: --- I suspect this is an issue with the qmf code using the underlying qpid::sys:AbsTime class representation directly and assuming it is a since the 1970 epoch. This is not not the case - as documented in cpp/src/qpid/sys/Time.h the value is nanosecs since an unknown base. Accidentally it is probably since 1/1/970 on unix systems, but on Windows I'd bet the epoch is different. This class was never intended to represent calendar time and so there is no facility to convert it directly. I guess the quick fix is to shift the epoch base of the windows code when converting AbsTime to Duration since that is the only way to gain access to the internal nanosec from epoch value. A better way would be to introduce a calendar date to AbsTime constructor so that you can specify the epoch base when you convert to Duration (negative values of AbsTime are perfectly meaningful for this class). > Timestamps are incorrect > > > Key: QPID-1904 > URL: https://issues.apache.org/jira/browse/QPID-1904 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework >Affects Versions: 0.5 > Environment: Windows XP > Reproduced both with the python API and the .Net API >Reporter: Julien Lavigne du Cadet > Attachments: qpid-dates.png > > > The timestamps for configuration and instrumentation messages are incorrect > both with the python and the .Net api. > According to the documentation "All timestamps are uint64 values representing > nanoseconds since the epoch (January 1, 1970)." However, the dates resulting > can be several years in the past or in the future. > To reproduce with the python api : > - in disp.py, line 178 add the following line : > print gmtime (nsec / 10) > - start qpid-tool and list the queues => the full dates will be displayed -- 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-1904) Timestamps are incorrect
[
https://issues.apache.org/jira/browse/QPID-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734145#action_12734145
]
Andrew Stitcher commented on QPID-1904:
---
>From inspection I suspect this code in cpp/src/qpid/sys/windows/Time.cpp:
Duration::Duration(const AbsTime& time0) : nanosecs(0) {
time_period p(ptime(min_date_time), time0.timepoint);
nanosecs = p.length().total_nanoseconds();
}
I suspect that ptime(min_date_time) is NOT the 1970 epoch.
> Timestamps are incorrect
>
>
> Key: QPID-1904
> URL: https://issues.apache.org/jira/browse/QPID-1904
> Project: Qpid
> Issue Type: Bug
> Components: Qpid Managment Framework
>Affects Versions: 0.5
> Environment: Windows XP
> Reproduced both with the python API and the .Net API
>Reporter: Julien Lavigne du Cadet
> Attachments: qpid-dates.png
>
>
> The timestamps for configuration and instrumentation messages are incorrect
> both with the python and the .Net api.
> According to the documentation "All timestamps are uint64 values representing
> nanoseconds since the epoch (January 1, 1970)." However, the dates resulting
> can be several years in the past or in the future.
> To reproduce with the python api :
> - in disp.py, line 178 add the following line :
> print gmtime (nsec / 10)
> - start qpid-tool and list the queues => the full dates will be displayed
--
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-1918) Patches/files for Windows QMF plug-in support
[ https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-1918: - Assignee: Andrew Stitcher (was: Steve Huston) > Patches/files for Windows QMF plug-in support > - > > Key: QPID-1918 > URL: https://issues.apache.org/jira/browse/QPID-1918 > Project: Qpid > Issue Type: New Feature > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 >Reporter: Pete MacKinnon >Assignee: Andrew Stitcher > Attachments: qpid-1918.patch > > > Various files for the Windows QMF plug-in support in cpp, based off revision: > 785848 > Need Static builds (release and debug) for correct runtime integration with > Condor: > src/broker.vcproj > src/client.vcproj > src/common.vcproj > src/qmfagent.vcproj > src/qmfconsole.vcproj > src/qpid.sln > src/qpidbroker.vcproj > - Changed to provide compile flags required for header file integration of > Posix types declared by both Qpid and Condor: > src/qpid/sys/windows/IntegerTypes.h > src/qpid/sys/windows/uuid.cpp > src/qpid/sys/windows/uuid.h > - Modified signature of PipeHandle ctor and fixed a Windows race condition in > the processing loop: > src/qpid/agent/ManagementAgentImpl.cpp > - Refactored the pipe code so that Condor can get a true socket fd it can > select on in daemon_core: > src/qpid/sys/Pipehandle.h > src/qpid/sys/posix/PipeHandle.cpp > src/qpid/sys/windows/PipeHandle.cpp > - Removed explicit dependency on Debug libs since we now have even more > targets. Added Apache license: > examples/qmf_agent.vcproj > - Added Apache license: > src/protocol_gen.mak > examples/qmf-agent/example_gen.mak > - Updated QMF Agent example README: > examples/README -- 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-1918) Patches/files for Windows QMF plug-in support
[ https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749554#action_12749554 ] Andrew Stitcher commented on QPID-1918: --- The attached patch contains multiple changes; please split up the patch into multiple self contianed patches, one for each change. That way we can look at smaller lumps of code and hopefully commit the chnages incrementally. > Patches/files for Windows QMF plug-in support > - > > Key: QPID-1918 > URL: https://issues.apache.org/jira/browse/QPID-1918 > Project: Qpid > Issue Type: New Feature > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 >Reporter: Pete MacKinnon >Assignee: Andrew Stitcher > Attachments: qpid-1918.patch > > > Various files for the Windows QMF plug-in support in cpp, based off revision: > 785848 > Need Static builds (release and debug) for correct runtime integration with > Condor: > src/broker.vcproj > src/client.vcproj > src/common.vcproj > src/qmfagent.vcproj > src/qmfconsole.vcproj > src/qpid.sln > src/qpidbroker.vcproj > - Changed to provide compile flags required for header file integration of > Posix types declared by both Qpid and Condor: > src/qpid/sys/windows/IntegerTypes.h > src/qpid/sys/windows/uuid.cpp > src/qpid/sys/windows/uuid.h > - Modified signature of PipeHandle ctor and fixed a Windows race condition in > the processing loop: > src/qpid/agent/ManagementAgentImpl.cpp > - Refactored the pipe code so that Condor can get a true socket fd it can > select on in daemon_core: > src/qpid/sys/Pipehandle.h > src/qpid/sys/posix/PipeHandle.cpp > src/qpid/sys/windows/PipeHandle.cpp > - Removed explicit dependency on Debug libs since we now have even more > targets. Added Apache license: > examples/qmf_agent.vcproj > - Added Apache license: > src/protocol_gen.mak > examples/qmf-agent/example_gen.mak > - Updated QMF Agent example README: > examples/README -- 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-1918) Patches/files for Windows QMF plug-in support
[ https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749555#action_12749555 ] Andrew Stitcher commented on QPID-1918: --- git diff output isn't sufficient to feed to patch as it doesn't handle the renamed files correctly. So qpid/cpp/examples/qmf-agent/sample.cpp qpid/cpp/examples/qmf-agent/sample_gen.mak aren't created by the patch. Use git format-patch. > Patches/files for Windows QMF plug-in support > - > > Key: QPID-1918 > URL: https://issues.apache.org/jira/browse/QPID-1918 > Project: Qpid > Issue Type: New Feature > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 >Reporter: Pete MacKinnon >Assignee: Andrew Stitcher > Attachments: qpid-1918.patch > > > Various files for the Windows QMF plug-in support in cpp, based off revision: > 785848 > Need Static builds (release and debug) for correct runtime integration with > Condor: > src/broker.vcproj > src/client.vcproj > src/common.vcproj > src/qmfagent.vcproj > src/qmfconsole.vcproj > src/qpid.sln > src/qpidbroker.vcproj > - Changed to provide compile flags required for header file integration of > Posix types declared by both Qpid and Condor: > src/qpid/sys/windows/IntegerTypes.h > src/qpid/sys/windows/uuid.cpp > src/qpid/sys/windows/uuid.h > - Modified signature of PipeHandle ctor and fixed a Windows race condition in > the processing loop: > src/qpid/agent/ManagementAgentImpl.cpp > - Refactored the pipe code so that Condor can get a true socket fd it can > select on in daemon_core: > src/qpid/sys/Pipehandle.h > src/qpid/sys/posix/PipeHandle.cpp > src/qpid/sys/windows/PipeHandle.cpp > - Removed explicit dependency on Debug libs since we now have even more > targets. Added Apache license: > examples/qmf_agent.vcproj > - Added Apache license: > src/protocol_gen.mak > examples/qmf-agent/example_gen.mak > - Updated QMF Agent example README: > examples/README -- 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-1918) Patches/files for Windows QMF plug-in support
[ https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749570#action_12749570 ] Andrew Stitcher commented on QPID-1918: --- cpp/include/qpid/sys/windows/IntegerTypes.h: It's not clear to me why se need either pid_t or ssize_t in here at all, pid_t - I'm not sure that any code that uses pid_t is going to port well to windows, but the definition there should be DWORD (that's what GetCurrentProcessId() returns). I'm confused by the use of the HAVE_xxx macros here,we're already in Windows specific code are there some circumstances where pid_t or ssize_t might be defined under windows? > Patches/files for Windows QMF plug-in support > - > > Key: QPID-1918 > URL: https://issues.apache.org/jira/browse/QPID-1918 > Project: Qpid > Issue Type: New Feature > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 >Reporter: Pete MacKinnon >Assignee: Andrew Stitcher > Attachments: qpid-1918.patch > > > Various files for the Windows QMF plug-in support in cpp, based off revision: > 785848 > Need Static builds (release and debug) for correct runtime integration with > Condor: > src/broker.vcproj > src/client.vcproj > src/common.vcproj > src/qmfagent.vcproj > src/qmfconsole.vcproj > src/qpid.sln > src/qpidbroker.vcproj > - Changed to provide compile flags required for header file integration of > Posix types declared by both Qpid and Condor: > src/qpid/sys/windows/IntegerTypes.h > src/qpid/sys/windows/uuid.cpp > src/qpid/sys/windows/uuid.h > - Modified signature of PipeHandle ctor and fixed a Windows race condition in > the processing loop: > src/qpid/agent/ManagementAgentImpl.cpp > - Refactored the pipe code so that Condor can get a true socket fd it can > select on in daemon_core: > src/qpid/sys/Pipehandle.h > src/qpid/sys/posix/PipeHandle.cpp > src/qpid/sys/windows/PipeHandle.cpp > - Removed explicit dependency on Debug libs since we now have even more > targets. Added Apache license: > examples/qmf_agent.vcproj > - Added Apache license: > src/protocol_gen.mak > examples/qmf-agent/example_gen.mak > - Updated QMF Agent example README: > examples/README -- 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-1918) Patches/files for Windows QMF plug-in support
[ https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749571#action_12749571 ] Andrew Stitcher commented on QPID-1918: --- cpp/include/qpid/sys/windows/uuid.h / cpp/src/qpid/sys/windows/uuid.cpp: This change makes no sens to me: The qpid code doesn't need the includes in the header so it's in the implementation file. How can including more in the header file be valid? If something else needs #include then add it there. > Patches/files for Windows QMF plug-in support > - > > Key: QPID-1918 > URL: https://issues.apache.org/jira/browse/QPID-1918 > Project: Qpid > Issue Type: New Feature > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 >Reporter: Pete MacKinnon >Assignee: Andrew Stitcher > Attachments: qpid-1918.patch > > > Various files for the Windows QMF plug-in support in cpp, based off revision: > 785848 > Need Static builds (release and debug) for correct runtime integration with > Condor: > src/broker.vcproj > src/client.vcproj > src/common.vcproj > src/qmfagent.vcproj > src/qmfconsole.vcproj > src/qpid.sln > src/qpidbroker.vcproj > - Changed to provide compile flags required for header file integration of > Posix types declared by both Qpid and Condor: > src/qpid/sys/windows/IntegerTypes.h > src/qpid/sys/windows/uuid.cpp > src/qpid/sys/windows/uuid.h > - Modified signature of PipeHandle ctor and fixed a Windows race condition in > the processing loop: > src/qpid/agent/ManagementAgentImpl.cpp > - Refactored the pipe code so that Condor can get a true socket fd it can > select on in daemon_core: > src/qpid/sys/Pipehandle.h > src/qpid/sys/posix/PipeHandle.cpp > src/qpid/sys/windows/PipeHandle.cpp > - Removed explicit dependency on Debug libs since we now have even more > targets. Added Apache license: > examples/qmf_agent.vcproj > - Added Apache license: > src/protocol_gen.mak > examples/qmf-agent/example_gen.mak > - Updated QMF Agent example README: > examples/README -- 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-1918) Patches/files for Windows QMF plug-in support
[
https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749573#action_12749573
]
Andrew Stitcher commented on QPID-1918:
---
cpp/src/CMakeLists.txt:
[Ignoring the spurious looking changes at the top]
There is endless repetition of the following pattern:
if (QPID_WINDOWS_STATIC)
add_library (qpidcommon STATIC ${libqpidcommon_SOURCES})
else ()
add_library (qpidcommon SHARED ${libqpidcommon_SOURCES})
endif (QPID_WINDOWS_STATIC)
Instead of doing this everywhere change it so that you define LIBRARY_LINKAGE
to be STATIC or SHARED or somesuch at the top of the file just once and then do:
add_library(qpidcommon ${LIBRARY_LINKAGE} ${libqpidcommon_SOURCES})
[Avoiding duplication is not restricted to actual code]
> Patches/files for Windows QMF plug-in support
> -
>
> Key: QPID-1918
> URL: https://issues.apache.org/jira/browse/QPID-1918
> Project: Qpid
> Issue Type: New Feature
> Components: Qpid Managment Framework
> Environment: Windows XP SP3, VC++ 9.0
>Reporter: Pete MacKinnon
>Assignee: Andrew Stitcher
> Attachments: qpid-1918.patch
>
>
> Various files for the Windows QMF plug-in support in cpp, based off revision:
> 785848
> Need Static builds (release and debug) for correct runtime integration with
> Condor:
> src/broker.vcproj
> src/client.vcproj
> src/common.vcproj
> src/qmfagent.vcproj
> src/qmfconsole.vcproj
> src/qpid.sln
> src/qpidbroker.vcproj
> - Changed to provide compile flags required for header file integration of
> Posix types declared by both Qpid and Condor:
> src/qpid/sys/windows/IntegerTypes.h
> src/qpid/sys/windows/uuid.cpp
> src/qpid/sys/windows/uuid.h
> - Modified signature of PipeHandle ctor and fixed a Windows race condition in
> the processing loop:
> src/qpid/agent/ManagementAgentImpl.cpp
> - Refactored the pipe code so that Condor can get a true socket fd it can
> select on in daemon_core:
> src/qpid/sys/Pipehandle.h
> src/qpid/sys/posix/PipeHandle.cpp
> src/qpid/sys/windows/PipeHandle.cpp
> - Removed explicit dependency on Debug libs since we now have even more
> targets. Added Apache license:
> examples/qmf_agent.vcproj
> - Added Apache license:
> src/protocol_gen.mak
> examples/qmf-agent/example_gen.mak
> - Updated QMF Agent example README:
> examples/README
--
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-1918) Patches/files for Windows QMF plug-in support
[ https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749575#action_12749575 ] Andrew Stitcher commented on QPID-1918: --- cpp/src/qpid/agent/ManagementAgentImpl.cpp: Seeing as this is the only place that PipeHandle is used why the change in interface and in fact what's the external distinction all about? > Patches/files for Windows QMF plug-in support > - > > Key: QPID-1918 > URL: https://issues.apache.org/jira/browse/QPID-1918 > Project: Qpid > Issue Type: New Feature > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 >Reporter: Pete MacKinnon >Assignee: Andrew Stitcher > Attachments: qpid-1918.patch > > > Various files for the Windows QMF plug-in support in cpp, based off revision: > 785848 > Need Static builds (release and debug) for correct runtime integration with > Condor: > src/broker.vcproj > src/client.vcproj > src/common.vcproj > src/qmfagent.vcproj > src/qmfconsole.vcproj > src/qpid.sln > src/qpidbroker.vcproj > - Changed to provide compile flags required for header file integration of > Posix types declared by both Qpid and Condor: > src/qpid/sys/windows/IntegerTypes.h > src/qpid/sys/windows/uuid.cpp > src/qpid/sys/windows/uuid.h > - Modified signature of PipeHandle ctor and fixed a Windows race condition in > the processing loop: > src/qpid/agent/ManagementAgentImpl.cpp > - Refactored the pipe code so that Condor can get a true socket fd it can > select on in daemon_core: > src/qpid/sys/Pipehandle.h > src/qpid/sys/posix/PipeHandle.cpp > src/qpid/sys/windows/PipeHandle.cpp > - Removed explicit dependency on Debug libs since we now have even more > targets. Added Apache license: > examples/qmf_agent.vcproj > - Added Apache license: > src/protocol_gen.mak > examples/qmf-agent/example_gen.mak > - Updated QMF Agent example README: > examples/README -- 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-1918) Patches/files for Windows QMF plug-in support
[
https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749578#action_12749578
]
Andrew Stitcher commented on QPID-1918:
---
cpp/src/qpid/sys/windows/PipeHandle.cpp:
I don't understand most of what's going on here, but the code has a very bad
error in it twice:
bool createTcpPipe(bool overlapped, int writeFd, int readFd) {
...
writeFd = pair[0];
readFd = pair[1];
...
}
&
bool createCrtPipe(int writeFd, int readFd) {
int pair[2];
...
writeFd = pair[0];
readFd = pair[1];
...
}
[the code seems to assume that the fds are really passed by reference and so
can be usefully assigned]
> Patches/files for Windows QMF plug-in support
> -
>
> Key: QPID-1918
> URL: https://issues.apache.org/jira/browse/QPID-1918
> Project: Qpid
> Issue Type: New Feature
> Components: Qpid Managment Framework
> Environment: Windows XP SP3, VC++ 9.0
>Reporter: Pete MacKinnon
>Assignee: Andrew Stitcher
> Attachments: qpid-1918.patch
>
>
> Various files for the Windows QMF plug-in support in cpp, based off revision:
> 785848
> Need Static builds (release and debug) for correct runtime integration with
> Condor:
> src/broker.vcproj
> src/client.vcproj
> src/common.vcproj
> src/qmfagent.vcproj
> src/qmfconsole.vcproj
> src/qpid.sln
> src/qpidbroker.vcproj
> - Changed to provide compile flags required for header file integration of
> Posix types declared by both Qpid and Condor:
> src/qpid/sys/windows/IntegerTypes.h
> src/qpid/sys/windows/uuid.cpp
> src/qpid/sys/windows/uuid.h
> - Modified signature of PipeHandle ctor and fixed a Windows race condition in
> the processing loop:
> src/qpid/agent/ManagementAgentImpl.cpp
> - Refactored the pipe code so that Condor can get a true socket fd it can
> select on in daemon_core:
> src/qpid/sys/Pipehandle.h
> src/qpid/sys/posix/PipeHandle.cpp
> src/qpid/sys/windows/PipeHandle.cpp
> - Removed explicit dependency on Debug libs since we now have even more
> targets. Added Apache license:
> examples/qmf_agent.vcproj
> - Added Apache license:
> src/protocol_gen.mak
> examples/qmf-agent/example_gen.mak
> - Updated QMF Agent example README:
> examples/README
--
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] Closed: (QPID-1737) qpid C++ will not build with WinSDK 7
[ https://issues.apache.org/jira/browse/QPID-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher closed QPID-1737. - Resolution: Fixed Fix Version/s: 0.6 As best I can tell this now builds correctly on Windows and Linux > qpid C++ will not build with WinSDK 7 > - > > Key: QPID-1737 > URL: https://issues.apache.org/jira/browse/QPID-1737 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: M4 > Environment: XP 32 bit with latest SDK from Microsoft (SDK 7 beta) >Reporter: James Mansion >Assignee: Steve Huston > Fix For: 0.6 > > Attachments: SIP.patch > > > I'm trying to build M4 of AMQP on XP with the Win7 SDK Beta, and I'm seeing > that > Manageable::STATUS_INVALID_PARAMETER > is being expanded to: > Manageable::((DWORD )0xC00DL); > I think this is because src\qpid/sys/windows/uuid.h has included rpc.h and > included a lot of the SDK as a result. > STATUS_INVALID_PARAMETER is defined in ntstatus.h and winnt.h. > The include structure is rather Byzantine - I see there's a JIRA to tidy > things up, though that is focussed on client applications. > I suspect that one way or another this will bite again even if sufficient > 'undefs' are added in the code now. > I know this is Microsoft's bad for namespace pollution, but the practical > answer is to change the name of this constant. -- 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-2082) Put all of the C++ code in the source tree into a namespace
Put all of the C++ code in the source tree into a namespace --- Key: QPID-2082 URL: https://issues.apache.org/jira/browse/QPID-2082 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Currently the test and example code is in the global namespace. It would be neater especially in a code browser that sorts flat by namespace to put all the code into a namespace. -- 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-2086) intermittent federated cluster hangs since r810591
[ https://issues.apache.org/jira/browse/QPID-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752674#action_12752674 ] Andrew Stitcher commented on QPID-2086: --- I can't reproduce this running federated_cluster_test_with_node_failure in a loop for about 30 mins on a 2 CPU fairly slow box. This is after r812590 which fixes a probably unrelated bug in AsynchIO.cpp > intermittent federated cluster hangs since r810591 > -- > > Key: QPID-2086 > URL: https://issues.apache.org/jira/browse/QPID-2086 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Blocker > > On revision 810590 I can run federated_cluster_test_with_node_failure in a > loop for over 100 iterations without any hangs. > However on revision 810591 the same loop hangs quite easily (generally within > 10 runs or so). -- 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-2086) intermittent federated cluster hangs since r810591
[ https://issues.apache.org/jira/browse/QPID-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-2086: - Assignee: Alan Conway (was: Andrew Stitcher) > intermittent federated cluster hangs since r810591 > -- > > Key: QPID-2086 > URL: https://issues.apache.org/jira/browse/QPID-2086 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Reporter: Gordon Sim >Assignee: Alan Conway >Priority: Blocker > > On revision 810590 I can run federated_cluster_test_with_node_failure in a > loop for over 100 iterations without any hangs. > However on revision 810591 the same loop hangs quite easily (generally within > 10 runs or so). -- 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-2082) Put all of the C++ code in the source tree into a namespace
[ https://issues.apache.org/jira/browse/QPID-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753287#action_12753287 ] Andrew Stitcher commented on QPID-2082: --- I've now put all of the test code into the qpid::tests namespace. However I've left the example code in the global namespace so as not to add irrelevant details to the examples. There are still a few things in the global namespace that are part of the qpidd main program, this code should probably be moved into the src/qpid/broker directory and put in the qpid::broker namespace > Put all of the C++ code in the source tree into a namespace > --- > > Key: QPID-2082 > URL: https://issues.apache.org/jira/browse/QPID-2082 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Minor > > Currently the test and example code is in the global namespace. > It would be neater especially in a code browser that sorts flat by namespace > to put all the code into a namespace. -- 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-2150) Excessive warnings about Timer woken up late on Windows
[ https://issues.apache.org/jira/browse/QPID-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766590#action_12766590 ] Andrew Stitcher commented on QPID-2150: --- I have a couple of things to add: 1. It would make sense not to warn for times less than the timer resolution. I didn't do this mostly due to laziness! 2. Really the timer code doesn't have any idea what the real criteria for warning is as it doesn't know what constraints the Timer clients are running under. So the warning is set fairly tight. Given that the timer isn't being used for anything very sensitive to small delays putting the warning up to 30ms or even 50ms wouldn't be a problem for all platforms. > Excessive warnings about Timer woken up late on Windows > --- > > Key: QPID-2150 > URL: https://issues.apache.org/jira/browse/QPID-2150 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.6 > Environment: Windows >Reporter: Steve Huston > Fix For: 0.6 > > > The C++ broker when running on Windows, shows a lot of warning messages like: > 2009-10-15 21:48:37 warning Timer woken up 15ms late > The lateness is usually between 10 and 15 msec, owing to the relative > imprecision in waking up a thread on Windows. I have two suggestions for > resolving this: > 1. Change the message from warning to debug. I'm a bit concerned that, > regardless of platform, if users of a product where speed is an issue start > seeing messages about timers waking up late, they may be concerned, without > any cause probably. I'm thinking that the only people interested in this > message are those diagnosing things who may want to enable debug messages. > 2. Allow a platform-specific value for the threshold at which lateness > prompts a message. For example, the current 10 msec limit is tighter than is > useful for Windows - 30msec would be better. -- 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] Issue Comment Edited: (QPID-2223) Controlling order of plug-in initialization.
[ https://issues.apache.org/jira/browse/QPID-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783717#action_12783717 ] Andrew Stitcher edited comment on QPID-2223 at 11/30/09 3:59 PM: - I don't like solutions that rely on an extrinsic numbering because it can be hard to figure out the correct value unless you know about absolutely every module that could be loaded. I think that a better solution would be one which uses a dependency tree. So I think it's more useful for plugins to specify which other plugins they depend on. Then the module code initialises them in the correct order. This definitely leads to more complication, as you have to deal with optional and required dependencies, but I think it "does the right thing" in an explicit way. was (Author: astitcher): I don't like solutions that rely on an extrinsic numbering because it can be hard to figure out the correct value unless you know about absolutely every module than could be loaded. I think that a better solution would be one which uses a dependency tree. So I think it's more useful for plugins to specify which other plugins they depend on. Then the module code initialises them in the correct order. This definitely leads to more complication, as you have to deal with optional and required dependencies, but I think it "does the right thing" in an explicit way. > Controlling order of plug-in initialization. > > > Key: QPID-2223 > URL: https://issues.apache.org/jira/browse/QPID-2223 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Alan Conway >Assignee: Alan Conway > > The specific use case for this is as follows: > The cluster plug-in needs to know in earlyInitialize whether or not the > broker has a store so it can correctly advertise itself as > persistent/transient when joining the cluster. > The current solution is > /** > > * Initialization order. If a plugin does not override this, it > > * returns DEFAULT_INIT_ORDER. Plugins that need to be initialized > > * earlier/later than normal can override initOrder to return > > * a lower/higher value than DEFAULT_INIT_ORDER. > > */ > QPID_COMMON_EXTERN virtual int initOrder() const; > The cluster plugin sets a higher initOrder so it will initialize after the > store and can test whether broker.getStore() is a null store. > This feature was added without sufficient discussion. The goal of this JIRA > is to determine if there's a better solution that would apply more generally. > If so we'll implement that instead. -- 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-2223) Controlling order of plug-in initialization.
[ https://issues.apache.org/jira/browse/QPID-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783717#action_12783717 ] Andrew Stitcher commented on QPID-2223: --- I don't like solutions that rely on an extrinsic numbering because it can be hard to figure out the correct value unless you know about absolutely every module than could be loaded. I think that a better solution would be one which uses a dependency tree. So I think it's more useful for plugins to specify which other plugins they depend on. Then the module code initialises them in the correct order. This definitely leads to more complication, as you have to deal with optional and required dependencies, but I think it "does the right thing" in an explicit way. > Controlling order of plug-in initialization. > > > Key: QPID-2223 > URL: https://issues.apache.org/jira/browse/QPID-2223 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Alan Conway >Assignee: Alan Conway > > The specific use case for this is as follows: > The cluster plug-in needs to know in earlyInitialize whether or not the > broker has a store so it can correctly advertise itself as > persistent/transient when joining the cluster. > The current solution is > /** > > * Initialization order. If a plugin does not override this, it > > * returns DEFAULT_INIT_ORDER. Plugins that need to be initialized > > * earlier/later than normal can override initOrder to return > > * a lower/higher value than DEFAULT_INIT_ORDER. > > */ > QPID_COMMON_EXTERN virtual int initOrder() const; > The cluster plugin sets a higher initOrder so it will initialize after the > store and can test whether broker.getStore() is a null store. > This feature was added without sufficient discussion. The goal of this JIRA > is to determine if there's a better solution that would apply more generally. > If so we'll implement that instead. -- 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-2227) The qpid c++ source distribution is missing src/tests/cluster.cmake & has a now unnecessary src/tests/test_env.sh
The qpid c++ source distribution is missing src/tests/cluster.cmake & has a now unnecessary src/tests/test_env.sh - Key: QPID-2227 URL: https://issues.apache.org/jira/browse/QPID-2227 Project: Qpid Issue Type: Bug Components: Build Tools Affects Versions: 0.6 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor 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-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: -- Description: 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. was: It uses the output in the documentation. 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. > 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 > Fix For: 0.6 > > > 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] Created: (QPID-2228) C++ "make dist " builds the entire broker just to print out qpidd --help
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 Fix For: 0.6 It uses the output in the documentation. 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-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 reassigned QPID-2228: - Assignee: Andrew Stitcher > 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 > Fix For: 0.6 > > > It uses the output in the documentation. 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] Resolved: (QPID-2227) The qpid c++ source distribution is missing src/tests/cluster.cmake & has a now unnecessary src/tests/test_env.sh
[ https://issues.apache.org/jira/browse/QPID-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-2227. --- Resolution: Fixed > The qpid c++ source distribution is missing src/tests/cluster.cmake & has a > now unnecessary src/tests/test_env.sh > - > > Key: QPID-2227 > URL: https://issues.apache.org/jira/browse/QPID-2227 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: 0.6 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Minor > 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] Issue Comment Edited: (QPID-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785425#action_12785425
]
Andrew Stitcher edited comment on QPID-2214 at 12/3/09 6:15 PM:
Good work for isolating this "unbounded growth" scenario when creating and then
destroying io worker threads.
However I don't see how the patch can fix the diagnosed problem.
There is no way to call the ThreadStatus destructor presently except when
shutting the entire program down, in other words during the call of the
allThreadsStatus destructor.
The individual ThreadStatus instances aren't deleted on each thread being
destroyed and I don't think there is a way to make this happen.
I'm currently thinking about this.
was (Author: astitcher):
Good work for isolating this "unbounded growth" scenario when creating and
then destroying io worker threads.
However I don't see how the patch can fix the diagnosed problem.
There is no way to call the ThreadStatus destructor presently except when
shutting the entire program dow, in other words during the call of the
allThreadsStatus destructor.
The individual ThreadStatus instances aren't deleted on each thread being
destroyed and I don't think there is a way to make this happen.
I'm currently thinking about this.
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Attachments: qpid-memleak.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785425#action_12785425
]
Andrew Stitcher commented on QPID-2214:
---
Good work for isolating this "unbounded growth" scenario when creating and then
destroying io worker threads.
However I don't see how the patch can fix the diagnosed problem.
There is no way to call the ThreadStatus destructor presently except when
shutting the entire program dow, in other words during the call of the
allThreadsStatus destructor.
The individual ThreadStatus instances aren't deleted on each thread being
destroyed and I don't think there is a way to make this happen.
I'm currently thinking about this.
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Attachments: qpid-memleak.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785428#action_12785428
]
Andrew Stitcher commented on QPID-2214:
---
The "correct" way to fix this is to ensure that you never create an unbounded
number of io threads.
The design intention was always that the number of io threads was small and
fixed, and the client code breaks that intention.
I'm looking at a fix that stops the client code from creating and then
destroying a thread per connection.
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Attachments: qpid-memleak.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785436#action_12785436
]
Andrew Stitcher commented on QPID-2214:
---
Incidentally,as Daniel implies, I don't think that the valgrind output is
related at all to the "memory leak".
The valgrind detected problem appears to happen when a thread isn't properly
joined before the program exits and so doesn't clean up the thread specific
data that it has allocated.
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Attachments: qpid-memleak.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787067#action_12787067
]
Andrew Stitcher commented on QPID-2214:
---
I've committed a change on the trunk branch for the memory leak, that is going
into 0.6 which is to be released soon.
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Attachments: qpid-memleak.patch, qpid-memleak2.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787069#action_12787069
]
Andrew Stitcher commented on QPID-2214:
---
The committed fix isn't the amended patch for a few reasons - I worked on it
based on the original mostly on Friday (before the amended patch was here).
The amended patch introduces an entirely new library dependency to qpid, and
justifying this is significant.
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Attachments: qpid-memleak.patch, qpid-memleak2.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-2214:
--
Fix Version/s: 0.6
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Fix For: 0.6
>
> Attachments: qpid-memleak.patch, qpid-memleak2.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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-2214) memory leak in qpid::client::Connection
[
https://issues.apache.org/jira/browse/QPID-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved QPID-2214.
---
Resolution: Fixed
The growth in memory for each open/close of a connection has been removed.
The valgrind ttrace (which is an entirely different bug) remains.
> memory leak in qpid::client::Connection
> ---
>
> Key: QPID-2214
> URL: https://issues.apache.org/jira/browse/QPID-2214
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: qpid 0.5 on a Debian Linux with gcc 4.3.3.
>Reporter: Daniel Etzold
>Assignee: Andrew Stitcher
>Priority: Critical
> Fix For: 0.6
>
> Attachments: qpid-memleak.patch, qpid-memleak2.patch
>
>
> Hi,
> when executing the code below (connecting and disconnecting to a local broker
> without sending any messages) the memory usage increases constantly and
> rapidly. After 10.000 iterations several hundred megabytes of resident memory
> are used.
> When commenting out the lines "connection.open()" and "close()" the memory
> usage does not increase.
> So, is there a memory leak in Connection open/close?
> int
> main(int argc, char** argv)
> {
> while (1) {
> qpid::client::Connection connection;
> connection.open("localhost", 5672);
> connection.close();
> }
> }
> Running my test binary with valgrind (the loop is limited to 100 iterations)
> valgrind --leak-check=full ./myqpidtest
> it seems that valgrind does not find any memory leaks.
> =17321== 76 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==17321==at 0x4007ADE: calloc (vg_replace_malloc.c:279)
> ==17321==by 0x430CD4E7: (within /lib/ld-2.3.6.so)
> ==17321==by 0x430CD58B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==17321==by 0x43AE428F: pthread_create@@GLIBC_2.1 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x43AE4AA7: pthread_cre...@glibc_2.0 (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==17321==by 0x4AA3B55:
> qpid::sys::ThreadPrivate::ThreadPrivate(qpid::sys::Runnable*) (in
> libqpidcommon.so.0.1.0)
> ==17321==by 0x4AA3682: qpid::sys::Thread::Thread(qpid::sys::Runnable*)
> (in libqpidcommon.so.0.1.0)
> ==17321==by 0x4C8BC6B: qpid::client::TCPConnector::init() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C8040A: qpid::client::ConnectionImpl::open() (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CD4A:
> qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
> libqpidclient.so.0.1.0)
> ==17321==by 0x4C6CED2: qpid::client::Connection::open(std::string const&,
> int, std::string const&, std::string const&, std::string const&, unsigned
> short) (in libqpidclient.so.0.1.0)
> ==17321==by 0x805EE1E: main (myqpidtest.cpp:281)
> ==17321==
> ==17321== LEAK SUMMARY:
> ==17321==definitely lost: 76 bytes in 1 blocks.
> ==17321== possibly lost: 0 bytes in 0 blocks.
> ==17321==still reachable: 48 bytes in 3 blocks.
> ==17321== suppressed: 0 bytes in 0 blocks.
> The 76 bytes which are reported to be definitely lost is constant whether
> running the loop 100 time or 1000 times.
> Regards,
> Daniel
--
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] Reopened: (QPID-1879) The client library uses a new thread for every connection
[ https://issues.apache.org/jira/browse/QPID-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reopened QPID-1879: --- This fix was reverted, due to some unforeseen interactions > The client library uses a new thread for every connection > - > > Key: QPID-1879 > URL: https://issues.apache.org/jira/browse/QPID-1879 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: M1, M2, M2.1, M3, M4, 0.5 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.6 > > > This is actually slightly worse than just using a new thread per broker > connection as it also uses a new Poller for every Connection and the Poller > is fairly hefty and includes a number of fds for its own use. This multiplies > the client fd use for clients with many Connections. > It's not really acceptable that opening 1000 connections should create 1000 > threads. > It should be noted that this isn't the only aspect of the client library that > uses excessive numbers of threads, lets knock them off one by one -- 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-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 reassigned QPID-1951: - Assignee: Andrew Stitcher > 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 > > 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-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:comment-tabpanel&focusedCommentId=12787739#action_12787739 ] Andrew Stitcher commented on QPID-1951: --- Essentially these types need to be removed one way or antoher from use within the Windows code > 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 > > 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] Issue Comment Edited: (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:comment-tabpanel&focusedCommentId=12787739#action_12787739 ] Andrew Stitcher edited comment on QPID-1951 at 12/8/09 8:50 PM: Essentially these types need to be removed one way or another from use within the Windows code was (Author: astitcher): Essentially these types need to be removed one way or antoher from use within the Windows code > 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 > > 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-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788257#action_12788257 ] Andrew Stitcher commented on QPID-2256: --- This must be a bug iin 0.6 as the code doesn't exist in 0.5 > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at > ../../cpp/in
[jira] Updated: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-2256: -- Affects Version/s: (was: 0.5) 0.6 > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at > ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5b162
[jira] Commented: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788259#action_12788259 ] Andrew Stitcher commented on QPID-2256: --- This might be related to having client and broker in the same process, as under this one case the DeletionManager would be shared. > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af11696
