[jira] [Created] (QPID-3281) Allow qpid to use unix domain socket
Allow qpid to use unix domain socket Key: QPID-3281 URL: https://issues.apache.org/jira/browse/QPID-3281 Project: Qpid Issue Type: New Feature Components: C++ Broker, C++ Client, Python Client Environment: Unix only Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: Future There are a number of cases where using unix domain sockets (AF_UNIX) to communicate between client and broker would be a very useful feature. -- 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-3282) Potential bug when checking socket connections for identical local and remote endpoint
Potential bug when checking socket connections for identical local and remote endpoint -- Key: QPID-3282 URL: https://issues.apache.org/jira/browse/QPID-3282 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Fix For: 0.11 Currently there is a check in Socket::connect that tries to make sure we don't try to connect to the same endpoint that the local end is bound to, this can happen in rare circumstances when connecting to localhost when the OS decides to bind the local end to a port that has just been given up by an exiting application that we are just about to retry connecting to. However the existing test doesn't canonicalise the endpoint names so it might try to do a string compare of localhost:1234 with 127.0.0.1:1234 and fail even though it should succeed. -- 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-3282) Potential bug when checking socket connections for identical local and remote endpoint
[ https://issues.apache.org/jira/browse/QPID-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3282. --- Resolution: Fixed Potential bug when checking socket connections for identical local and remote endpoint -- Key: QPID-3282 URL: https://issues.apache.org/jira/browse/QPID-3282 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Fix For: 0.11 Currently there is a check in Socket::connect that tries to make sure we don't try to connect to the same endpoint that the local end is bound to, this can happen in rare circumstances when connecting to localhost when the OS decides to bind the local end to a port that has just been given up by an exiting application that we are just about to retry connecting to. However the existing test doesn't canonicalise the endpoint names so it might try to do a string compare of localhost:1234 with 127.0.0.1:1234 and fail even though it should succeed. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror --- Key: QPID-3295 URL: https://issues.apache.org/jira/browse/QPID-3295 Project: Qpid Issue Type: Bug Affects Versions: 0.10, 0.8 Reporter: Andrew Stitcher Assignee: Andrew Stitcher If CFLAGS or CXXFLAGS contains -Wall when running configure, autoconf incorrectly detects that gcc doesn't support -Werror This is problematic because it is an important aspect of our policy that there should be no compiler warnings, and this bug stops this being enforced. Notably, the fedora package build has this issue and has been shipping with some unnoticed warnings for a while. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[
https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045588#comment-13045588
]
Andrew Stitcher commented on QPID-3295:
---
Configure.ac uses the gl_COMPILER_FLAGS macro to test whether the compiler
accepts a particular flag. However the program it uses to test compile has an
unused variable in it.
The program is:
int main() {
int x;
;
return 0;
}
when compiled with -Wall -Werror this program reports an error and so autoconf
thinks that -Werror isn't a valid flags for gcc
Under some conditions autoconf incorrectly detects that gcc doesn't support
-Werror
---
Key: QPID-3295
URL: https://issues.apache.org/jira/browse/QPID-3295
Project: Qpid
Issue Type: Bug
Affects Versions: 0.8, 0.10
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
Labels: autoconf, gcc
If CFLAGS or CXXFLAGS contains -Wall when running configure, autoconf
incorrectly detects that gcc doesn't support -Werror
This is problematic because it is an important aspect of our policy that
there should be no compiler warnings, and this bug stops this being enforced.
Notably, the fedora package build has this issue and has been shipping with
some unnoticed warnings for a while.
--
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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[ https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045589#comment-13045589 ] Andrew Stitcher commented on QPID-3295: --- Since -Werror has been supported in every gcc version since at least 2.95 I think it's safe to enable -Werror unconditionally if the compiler is gcc. Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror --- Key: QPID-3295 URL: https://issues.apache.org/jira/browse/QPID-3295 Project: Qpid Issue Type: Bug Affects Versions: 0.8, 0.10 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Labels: autoconf, gcc If CFLAGS or CXXFLAGS contains -Wall when running configure, autoconf incorrectly detects that gcc doesn't support -Werror This is problematic because it is an important aspect of our policy that there should be no compiler warnings, and this bug stops this being enforced. Notably, the fedora package build has this issue and has been shipping with some unnoticed warnings for a while. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[ https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3295. --- Resolution: Fixed Fix Version/s: 0.11 Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror --- Key: QPID-3295 URL: https://issues.apache.org/jira/browse/QPID-3295 Project: Qpid Issue Type: Bug Affects Versions: 0.8, 0.10 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Labels: autoconf, gcc Fix For: 0.11 If CFLAGS or CXXFLAGS contains -Wall when running configure, autoconf incorrectly detects that gcc doesn't support -Werror This is problematic because it is an important aspect of our policy that there should be no compiler warnings, and this bug stops this being enforced. Notably, the fedora package build has this issue and has been shipping with some unnoticed warnings for a while. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[ https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3295: -- Component/s: Build Tools Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror --- Key: QPID-3295 URL: https://issues.apache.org/jira/browse/QPID-3295 Project: Qpid Issue Type: Bug Components: Build Tools Affects Versions: 0.8, 0.10 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Labels: autoconf, gcc Fix For: 0.11 If CFLAGS or CXXFLAGS contains -Wall when running configure, autoconf incorrectly detects that gcc doesn't support -Werror This is problematic because it is an important aspect of our policy that there should be no compiler warnings, and this bug stops this being enforced. Notably, the fedora package build has this issue and has been shipping with some unnoticed warnings for a while. -- 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-3284) Removed unused variables, which caused the build to break under GCC 4.6
[ https://issues.apache.org/jira/browse/QPID-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3284. --- Resolution: Fixed Fix Version/s: (was: Future) 0.11 Committed as very similar but more extensive patch I was already working on. Removed unused variables, which caused the build to break under GCC 4.6 --- Key: QPID-3284 URL: https://issues.apache.org/jira/browse/QPID-3284 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.10 Environment: Fedora 15 x86_64. Reporter: Darryl L. Pierce Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.11 Attachments: 0001-Removed-unused-variables.patch, 0001-Removed-unused-variables.patch There were several variables that were declared and assigned values but whose values were not used. This caused GCC 4.6.0 to raise a warning, which causes the build to stop. This patch removes those unused variables. -- 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-tabpanelfocusedCommentId=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':port 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 dynamic $ qpid-route route list buzz.somedomain.com:5682 buzz.somedomain.com:5682 localhost:5672 T.Prod dynamic 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-tabpanelfocusedCommentId=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':port 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 dynamic $ qpid-route route list buzz.somedomain.com:5682 buzz.somedomain.com:5682 localhost:5672 T.Prod dynamic 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-tabpanelfocusedCommentId=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':port 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 dynamic $ qpid-route route list buzz.somedomain.com:5682 buzz.somedomain.com:5682 localhost:5672 T.Prod dynamic 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-tabpanelfocusedCommentId=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':port 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 dynamic $ qpid-route route list buzz.somedomain.com:5682 buzz.somedomain.com:5682 localhost:5672 T.Prod dynamic 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-tabpanelfocusedCommentId=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':port 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 dynamic $ qpid-route route list buzz.somedomain.com:5682 buzz.somedomain.com:5682 localhost:5672 T.Prod dynamic 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-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: method name=create desc=Create an object of the specified type arg name=type dir=I type=sstr desc=The type of object to create/ arg name=name dir=I type=sstr desc=The name of the object to create/ arg name=properties dir=I type=map desc=Type specific object properties/ arg name=strict dir=I type=bool desc=If specified, treat unrecognised object properties as an error/ /method 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: method name=create desc=Create an object of the specified type arg name=type dir=I type=sstr desc=The type of object to create/ arg name=name dir=I type=sstr desc=The name of the object to create/ arg name=properties dir=I type=map desc=Type specific object properties/ arg name=strict dir=I type=bool desc=If specified, treat unrecognised object properties as an error/ /method 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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 declaration 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] [Created] (QPID-4011) TestIsLocalHost unit_test fails with if machine name resolves to loopback address
Andrew Stitcher created QPID-4011: - Summary: TestIsLocalHost unit_test fails with if machine name resolves to loopback address Key: QPID-4011 URL: https://issues.apache.org/jira/browse/QPID-4011 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client, C++ Clustering Affects Versions: 0.17 Reporter: Andrew Stitcher Assignee: Andrew Stitcher The new SystemInfo::isLocalHost() code doesn't check correctly for interface addresses that resolve to the loopback address. -- 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-4011) TestIsLocalHost unit_test fails with if machine name resolves to loopback address
[ https://issues.apache.org/jira/browse/QPID-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4011. --- Resolution: Fixed Fix Version/s: 0.17 TestIsLocalHost unit_test fails with if machine name resolves to loopback address - Key: QPID-4011 URL: https://issues.apache.org/jira/browse/QPID-4011 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client, C++ Clustering Affects Versions: 0.17 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.17 The new SystemInfo::isLocalHost() code doesn't check correctly for interface addresses that resolve to the loopback address. -- 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-4013) Windows Broker SSL is more difficult to use than necessary and possibly less secure than possible
Andrew Stitcher created QPID-4013: - Summary: Windows Broker SSL is more difficult to use than necessary and possibly less secure than possible Key: QPID-4013 URL: https://issues.apache.org/jira/browse/QPID-4013 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.16, 0.14, 0.17 Environment: Windows Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Fix For: 0.17 The current Windows Broker SSL code always uses the LocalMachine certificate store opened read/write. This has a number of drawbacks: * Opening read/write means that the broker has to run as administrator to use the certificates in the store. The broker only reads from the store so this is actually unnecessary. * Forcing use of LocalMachine for the certificates means that they are readable by every user on the machine which might be a security issue. As it would allow any process on the machine to impersonate the qpid broker. -- 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-4013) Windows Broker SSL is more difficult to use than necessary and possibly less secure than possible
[ https://issues.apache.org/jira/browse/QPID-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4013. --- Resolution: Fixed Note that this change represents a small change in default functionality: The broker now looks in the CurrentUser certificate store by default. To use the previous default specify --ssl-cert-store-location LocalMachine on the qpidd command line. Or set the equivalent option in the configuration file. Windows Broker SSL is more difficult to use than necessary and possibly less secure than possible - Key: QPID-4013 URL: https://issues.apache.org/jira/browse/QPID-4013 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.14, 0.16, 0.17 Environment: Windows Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Fix For: 0.17 The current Windows Broker SSL code always uses the LocalMachine certificate store opened read/write. This has a number of drawbacks: * Opening read/write means that the broker has to run as administrator to use the certificates in the store. The broker only reads from the store so this is actually unnecessary. * Forcing use of LocalMachine for the certificates means that they are readable by every user on the machine which might be a security issue. As it would allow any process on the machine to impersonate the qpid broker. -- 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-4013) Windows Broker SSL is more difficult to use than necessary and possibly less secure than possible
[ https://issues.apache.org/jira/browse/QPID-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280563#comment-13280563 ] Andrew Stitcher commented on QPID-4013: --- This change adds a new ssl related option to qpidd: --ssl-cert-store-location with possible values CurrentUser, LocalMachine, CurrentService This can be used to set the certificate store location that qpidd uses to find the server certificate it uses. Windows Broker SSL is more difficult to use than necessary and possibly less secure than possible - Key: QPID-4013 URL: https://issues.apache.org/jira/browse/QPID-4013 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.14, 0.16, 0.17 Environment: Windows Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Fix For: 0.17 The current Windows Broker SSL code always uses the LocalMachine certificate store opened read/write. This has a number of drawbacks: * Opening read/write means that the broker has to run as administrator to use the certificates in the store. The broker only reads from the store so this is actually unnecessary. * Forcing use of LocalMachine for the certificates means that they are readable by every user on the machine which might be a security issue. As it would allow any process on the machine to impersonate the qpid broker. -- 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-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 resolved QPID-2518. --- Resolution: Fixed Fix Version/s: 0.17 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 Fix For: 0.17 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] [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-tabpanelfocusedCommentId=13280610#comment-13280610 ] Andrew Stitcher commented on QPID-2518: --- These code changes introduce a timer that gets started when a new connection is accepted. If the protocol negotiation phases isn't completed within a specified period then connection will be aborted. A new option is introduced to control the timer timeout period: --max-negotiate-time time in milliseconds The default timeout is 2000ms (2s) which gives a lot of latitude for network delays. 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 Fix For: 0.17 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] [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-tabpanelfocusedCommentId=13280617#comment-13280617 ] Andrew Stitcher commented on QPID-2518: --- This change limits the impact of CVE-2012-2145. But doesn't prevent a determined DoS attack on a broker. 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 Fix For: 0.17 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] [Commented] (QPID-1133) Poller implementation based on the Solaris Event Completion Framework
[ https://issues.apache.org/jira/browse/QPID-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13282124#comment-13282124 ] Andrew Stitcher commented on QPID-1133: --- We now have a poll() based Poller implementation and so this is no longer needed to make qpid work on Solaris. It might be an optimisation though. Poller implementation based on the Solaris Event Completion Framework - Key: QPID-1133 URL: https://issues.apache.org/jira/browse/QPID-1133 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: M3 Reporter: Manuel Teira Assignee: Andrew Stitcher Priority: Minor Attachments: sol-poller.patch A Poller based in Solaris Event Completion Framework. -- 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-1133) Poller implementation based on the Solaris Event Completion Framework
[ https://issues.apache.org/jira/browse/QPID-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-1133. --- Resolution: Later No pressing need to do this since we've had the poll() based Poller. Poller implementation based on the Solaris Event Completion Framework - Key: QPID-1133 URL: https://issues.apache.org/jira/browse/QPID-1133 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: M3 Reporter: Manuel Teira Assignee: Andrew Stitcher Priority: Minor Attachments: sol-poller.patch A Poller based in Solaris Event Completion Framework. -- 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-tabpanelfocusedCommentId=13283567#comment-13283567 ] Andrew Stitcher commented on QPID-2518: --- Good point - that'll teach me to actually read the words in the bug report, rather than reading the words I expect to be there. 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 Fix For: 0.17 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] [Created] (QPID-4021) Badly behaved clients can still clog up the broker
Andrew Stitcher created QPID-4021: - Summary: Badly behaved clients can still clog up the broker Key: QPID-4021 URL: https://issues.apache.org/jira/browse/QPID-4021 Project: Qpid Issue Type: Bug Reporter: Andrew Stitcher The recent code that timeouts out new connections that have not negotiated the protocol within (a default) 2 seconds still leaves a gap where badly behaved applications can tie up the broker. The timeout should really be till either heartbeats are activated in which case they will take over the role of timing out idle connections. Or until the connection is authenticated in which case the policy on admitting users should take care of limiting the connections. -- 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-4021) Badly behaved clients can still clog up the broker
[ https://issues.apache.org/jira/browse/QPID-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4021: -- Component/s: C++ Broker Affects Version/s: 0.17 Badly behaved clients can still clog up the broker -- Key: QPID-4021 URL: https://issues.apache.org/jira/browse/QPID-4021 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Reporter: Andrew Stitcher The recent code that timeouts out new connections that have not negotiated the protocol within (a default) 2 seconds still leaves a gap where badly behaved applications can tie up the broker. The timeout should really be till either heartbeats are activated in which case they will take over the role of timing out idle connections. Or until the connection is authenticated in which case the policy on admitting users should take care of limiting the connections. -- 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-4021) Badly behaved clients can still clog up the broker
[ https://issues.apache.org/jira/browse/QPID-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13283723#comment-13283723 ] Andrew Stitcher commented on QPID-4021: --- This is CVE-2012-2145 Badly behaved clients can still clog up the broker -- Key: QPID-4021 URL: https://issues.apache.org/jira/browse/QPID-4021 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Reporter: Andrew Stitcher The recent code that timeouts out new connections that have not negotiated the protocol within (a default) 2 seconds still leaves a gap where badly behaved applications can tie up the broker. The timeout should really be till either heartbeats are activated in which case they will take over the role of timing out idle connections. Or until the connection is authenticated in which case the policy on admitting users should take care of limiting the connections. -- 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-4022) C++ Broker connection limits by host ip and by user name can get confused
[ https://issues.apache.org/jira/browse/QPID-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291848#comment-13291848 ] Andrew Stitcher commented on QPID-4022: --- This patch looks good. Just one thing: It looks like ConnectionCounter::connection(broker::Connection) now has no real function - did I miss something? C++ Broker connection limits by host ip and by user name can get confused - Key: QPID-4022 URL: https://issues.apache.org/jira/browse/QPID-4022 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.16 Reporter: Chuck Rolke Assignee: Chuck Rolke Attachments: QPID-4022-conn-limits-rev2-10-with-tests.patch The current ACL module uses the ConnectionObserver to watch the life cycle of connections. It tries to disallow the creation of too many connections by a user or from an IP address. However, the method is uses is flawed especially in the cluster case. A better strategy to use it to provide approvers in the ConnectionObserver scheme and then to call them: 1. Limits by IP address are disapproved in the ConnectionFactories. If the limit is reached then the factory does not create the connection codec and the connection never begins a life cycle. This is enforced at the same point in code as the per-broker --max-connection limit using similar enforcement methods. 2. Limits by user name are disapproved at the same point as user authentication happens. Details to follow. -- 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-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4049: -- Affects Version/s: (was: 0.16) 0.17 Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Priority: Critical Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- 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-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293695#comment-13293695 ] Andrew Stitcher commented on QPID-4049: --- Aargh, this looks like yet another place where we've fixed a bug only in one set of cut-and-paste code. Alan fixed this bug for TCP in r1343397, but didn't fix the ssl code. Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Priority: Critical Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- 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-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295351#comment-13295351 ] Andrew Stitcher commented on QPID-4049: --- Fixed now in r1350406 Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Priority: Critical Labels: cut-n-paste-error Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- 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-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4049. --- Resolution: Fixed Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Priority: Critical Labels: cut-n-paste-error Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- 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-3914) SSL Client Authentication support for the Windows C++ client
[ https://issues.apache.org/jira/browse/QPID-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13395885#comment-13395885 ] Andrew Stitcher commented on QPID-3914: --- I don't think you've explained why you need to make the client install anything in the machines certificate stores using the client code itself. Why not install any certificates you need using some powershell script say when you install the client? I don't like adding a feature to the client code that seems to me to be purely administration code. SSL Client Authentication support for the Windows C++ client Key: QPID-3914 URL: https://issues.apache.org/jira/browse/QPID-3914 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.14, 0.16 Environment: Windows (all versions) Reporter: JAkub Scholz Attachments: ssl-client-auth-filecert.patch, ssl-client-authentication.patch The Windows C++ client has been missing support for the SSL Client Authentication - authentication using SSL certificates on the client side. The patch attached to this JIRA implements this feature. -- 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-2567) [c++] Timer - possible thread lock ordering violation
[ https://issues.apache.org/jira/browse/QPID-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407470#comment-13407470 ] Andrew Stitcher commented on QPID-2567: --- I think it is very likely this bug is fixed by the recent checkin r1357827 on trunk. Certainly I can no longer reproduce this bug report on qpid trunk. [c++] Timer - possible thread lock ordering violation - Key: QPID-2567 URL: https://issues.apache.org/jira/browse/QPID-2567 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.7 Environment: RHEL-6 beta Reporter: Kim van der Riet Assignee: Andrew Stitcher Fix For: 0.17 Starting the broker using valgrind and the helgrind thread check tool shows several lock order violations centered around the qpid::sys::Timer class. valgrind --tool=helgrind .libs/lt-qpidd --auth no --log-enable info+ results in the following message (and others that are similar): ==31280== Thread #2: lock order 0x597D548 before 0x59AE350 violated ==31280==at 0x4A0679C: pthread_mutex_lock (hg_intercepts.c:464) ==31280==by 0x4E8C27B: qpid::sys::Mutex::lock() (Mutex.h:116) ==31280==by 0x4E8CD82: qpid::sys::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mutex) (Mutex.h:33) ==31280==by 0x56346FF: qpid::sys::Timer::add(boost::intrusive_ptrqpid::sys::TimerTask) (Timer.cpp:162) ==31280==by 0x4EFDCD0: qpid::broker::LinkRegistry::Periodic::fire() (LinkRegistry.cpp:73) ==31280==by 0x563344C: qpid::sys::TimerTask::fireTask() (Timer.cpp:57) ==31280==by 0x5634917: qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) (Timer.cpp:190) ==31280==by 0x5633E84: qpid::sys::Timer::run() (Timer.cpp:119) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) ==31280== Required order was established by acquisition of lock at 0x597D548 ==31280==at 0x4A095F6: pthread_cond_wait_WRK (hg_intercepts.c:653) ==31280==by 0x4A096B8: pthread_cond_wait@* (hg_intercepts.c:675) ==31280==by 0x4EF587A: qpid::sys::Condition::wait(qpid::sys::Mutex) (Condition.h:63) ==31280==by 0x4EF5932: qpid::sys::Monitor::wait() (Monitor.h:41) ==31280==by 0x5633AA6: qpid::sys::Timer::run() (Timer.cpp:98) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) ==31280== followed by a later acquisition of lock at 0x59AE350 ==31280==at 0x4A0679C: pthread_mutex_lock (hg_intercepts.c:464) ==31280==by 0x4E8C27B: qpid::sys::Mutex::lock() (Mutex.h:116) ==31280==by 0x4E8CD82: qpid::sys::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mutex) (Mutex.h:33) ==31280==by 0x5633B97: qpid::sys::Timer::run() (Timer.cpp:108) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) Running perftest against this broker shows numerous read/write conflicts too. -- 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-2567) [c++] Timer - possible thread lock ordering violation
[ https://issues.apache.org/jira/browse/QPID-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-2567. --- Resolution: Fixed Fix Version/s: 0.17 Probably fixed by r1357827 [c++] Timer - possible thread lock ordering violation - Key: QPID-2567 URL: https://issues.apache.org/jira/browse/QPID-2567 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.7 Environment: RHEL-6 beta Reporter: Kim van der Riet Assignee: Andrew Stitcher Fix For: 0.17 Starting the broker using valgrind and the helgrind thread check tool shows several lock order violations centered around the qpid::sys::Timer class. valgrind --tool=helgrind .libs/lt-qpidd --auth no --log-enable info+ results in the following message (and others that are similar): ==31280== Thread #2: lock order 0x597D548 before 0x59AE350 violated ==31280==at 0x4A0679C: pthread_mutex_lock (hg_intercepts.c:464) ==31280==by 0x4E8C27B: qpid::sys::Mutex::lock() (Mutex.h:116) ==31280==by 0x4E8CD82: qpid::sys::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mutex) (Mutex.h:33) ==31280==by 0x56346FF: qpid::sys::Timer::add(boost::intrusive_ptrqpid::sys::TimerTask) (Timer.cpp:162) ==31280==by 0x4EFDCD0: qpid::broker::LinkRegistry::Periodic::fire() (LinkRegistry.cpp:73) ==31280==by 0x563344C: qpid::sys::TimerTask::fireTask() (Timer.cpp:57) ==31280==by 0x5634917: qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) (Timer.cpp:190) ==31280==by 0x5633E84: qpid::sys::Timer::run() (Timer.cpp:119) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) ==31280== Required order was established by acquisition of lock at 0x597D548 ==31280==at 0x4A095F6: pthread_cond_wait_WRK (hg_intercepts.c:653) ==31280==by 0x4A096B8: pthread_cond_wait@* (hg_intercepts.c:675) ==31280==by 0x4EF587A: qpid::sys::Condition::wait(qpid::sys::Mutex) (Condition.h:63) ==31280==by 0x4EF5932: qpid::sys::Monitor::wait() (Monitor.h:41) ==31280==by 0x5633AA6: qpid::sys::Timer::run() (Timer.cpp:98) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) ==31280== followed by a later acquisition of lock at 0x59AE350 ==31280==at 0x4A0679C: pthread_mutex_lock (hg_intercepts.c:464) ==31280==by 0x4E8C27B: qpid::sys::Mutex::lock() (Mutex.h:116) ==31280==by 0x4E8CD82: qpid::sys::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mutex) (Mutex.h:33) ==31280==by 0x5633B97: qpid::sys::Timer::run() (Timer.cpp:108) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) Running perftest against this broker shows numerous read/write conflicts too. -- 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-4101) Fixes building the Ruby language bindings for Ruby 1.9
[ https://issues.apache.org/jira/browse/QPID-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-4101: - Assignee: Andrew Stitcher Fixes building the Ruby language bindings for Ruby 1.9 -- Key: QPID-4101 URL: https://issues.apache.org/jira/browse/QPID-4101 Project: Qpid Issue Type: Bug Components: Ruby Client Affects Versions: 0.17 Reporter: Darryl L. Pierce Assignee: Andrew Stitcher Attachments: 0001-Fixes-the-Cmake-build-process-for-the-Ruby-language-.patch Building the Ruby language bindings for Ruby 1.9 fail since the build environment cannot find ruby/config.h -- 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-4101) Fixes building the Ruby language bindings for Ruby 1.9
[ https://issues.apache.org/jira/browse/QPID-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4101. --- Resolution: Fixed Fix Version/s: 0.17 Fixed in r1357945 Fixes building the Ruby language bindings for Ruby 1.9 -- Key: QPID-4101 URL: https://issues.apache.org/jira/browse/QPID-4101 Project: Qpid Issue Type: Bug Components: Ruby Client Affects Versions: 0.17 Reporter: Darryl L. Pierce Assignee: Andrew Stitcher Fix For: 0.17 Attachments: 0001-Fixes-the-Cmake-build-process-for-the-Ruby-language-.patch Building the Ruby language bindings for Ruby 1.9 fail since the build environment cannot find ruby/config.h -- 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-3883) Using application headers in messages causes a very large slowdown
[ https://issues.apache.org/jira/browse/QPID-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13408216#comment-13408216 ] Andrew Stitcher commented on QPID-3883: --- r1358275, r1358274 Changes which speed up the encoding of qpid::messaging::Variant types significantly by usually avoiding the intermediate step of using a FieldTable. This change should be in 0.18 Using application headers in messages causes a very large slowdown -- Key: QPID-3883 URL: https://issues.apache.org/jira/browse/QPID-3883 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Affects Versions: 0.14 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Messages that have application headers have a very high overhead compared to messages that don't have application headers. There are multiple causes of this problem: * Messages are copied unnecessarily in the client code * Encoding/decoding FieldTables is inefficient * Encoding/decoding FieldTables is done unnecessarily * Copying FieldTables is inefficient * The mapping of Variants to the current underlying FieldTable implementation may be inefficient -- 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] [Closed] (QPID-4161) Move the build system to CMake
[ https://issues.apache.org/jira/browse/QPID-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher closed QPID-4161. - Resolution: Duplicate This is a duplicate of QPID-3633 Move the build system to CMake -- Key: QPID-4161 URL: https://issues.apache.org/jira/browse/QPID-4161 Project: Qpid Issue Type: Improvement Components: Build Tools Reporter: Darryl L. Pierce The Cmake system needs to be updated so that it can replace the existing autotools system. -- 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-4134) Creates a source tarball for use by the Perl distributions.
[ https://issues.apache.org/jira/browse/QPID-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13421699#comment-13421699 ] Andrew Stitcher commented on QPID-4134: --- I'm not really happy that this is really a source tarball in any useful way. The source tarball packages up the code generated by swig. This is not really source in the sense that a developer could use it to change anything. I'd expect source to include the swig typemap and whatever other files that swig needs to do the generation, and perhaps the original qpid/messaging.h and other C++ header files .Although for packaging purposes you could have a build dependency on the appropriate -devel package and not include the actual files. The extra work I think this needs is to make the Cmake tooling now work both standalone and as part of the full build - I'm not sure how good cmake is at that. Creates a source tarball for use by the Perl distributions. --- Key: QPID-4134 URL: https://issues.apache.org/jira/browse/QPID-4134 Project: Qpid Issue Type: Bug Components: Packaging Reporter: Darryl L. Pierce Labels: bindings, perl, Attachments: 0001-Adds-a-Cmake-target-to-generate-a-source-tarball-for.patch This patch adds a new target to the Cmake build system to produce a source tarball for the Perl bindings. It replaces Makefile.PL.in with Makefile.PL, and removes Perl from the autotools build. -- 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-4168) Unhandled [rare] error condition in EpollPoller.cpp
[ https://issues.apache.org/jira/browse/QPID-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-4168: - Assignee: Andrew Stitcher Unhandled [rare] error condition in EpollPoller.cpp --- Key: QPID-4168 URL: https://issues.apache.org/jira/browse/QPID-4168 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.16 Environment: RHEL 6.2 (probably all POSIX targets) Reporter: Rob Springer Assignee: Andrew Stitcher Priority: Minor There was a bug in one of our programs wherein a thread could call close() on what was effectively a random socket. Occasionally, it would happen to call close() on the alwaysReadableFd registered in the PollerPrivate constructor, which would result in an epoll event for that FD to be returned in the call to epoll_wait() on line 568. It'd then try to dereference the event's ptr element (which was set to 0x1 on registration for that FD), which would lead to a segfault. It's worth reiterating that the triggering bug is absolutely not in Qpid, so this isn't a core functionality issue - it's more of a graceful handling of a unexpected error condition. -- 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-4168) Unhandled [rare] error condition in EpollPoller.cpp
[ https://issues.apache.org/jira/browse/QPID-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13423289#comment-13423289 ] Andrew Stitcher commented on QPID-4168: --- The only graceful way to handle detecting this problem would be to exit in any case. So I'm not sure how actually graceful this would be! [If alwaysReadableFd is closed then there is no way to do some of the necessary functions of EpollPoller so we'd have to assert in the case] Unhandled [rare] error condition in EpollPoller.cpp --- Key: QPID-4168 URL: https://issues.apache.org/jira/browse/QPID-4168 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.16 Environment: RHEL 6.2 (probably all POSIX targets) Reporter: Rob Springer Assignee: Andrew Stitcher Priority: Minor There was a bug in one of our programs wherein a thread could call close() on what was effectively a random socket. Occasionally, it would happen to call close() on the alwaysReadableFd registered in the PollerPrivate constructor, which would result in an epoll event for that FD to be returned in the call to epoll_wait() on line 568. It'd then try to dereference the event's ptr element (which was set to 0x1 on registration for that FD), which would lead to a segfault. It's worth reiterating that the triggering bug is absolutely not in Qpid, so this isn't a core functionality issue - it's more of a graceful handling of a unexpected error condition. -- 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-4180) Occasional Buffer leak in qpidd
Andrew Stitcher created QPID-4180: - Summary: Occasional Buffer leak in qpidd Key: QPID-4180 URL: https://issues.apache.org/jira/browse/QPID-4180 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Andrew Stitcher Assignee: Andrew Stitcher Occasionally when running the tests with valgrind (make check) the stop_broker test fails with a memory leak of one IO buffer: ==13674== HEAP SUMMARY: ==13674== in use at exit: 73,479 bytes in 188 blocks ==13674== total heap usage: 4,794,669 allocs, 4,794,481 frees, 402,637,196 bytes allocated ==13674== ==13674== 65,568 (32 direct, 65,536 indirect) bytes in 1 blocks are definitely lost in loss record 188 of 188 ==13674==at 0x4A06C8E: operator new(unsigned long) (vg_replace_malloc.c:261) ==13674==by 0x535EDF4: qpid::sys::AsynchIOHandler::init(qpid::sys::AsynchIO*, qpid::sys::Timer, unsigned int, int) (AsynchIOHandler.cpp:93) ==13674==by 0x4EA98C1: qpid::sys::AsynchIOProtocolFactory::established(boost::shared_ptrqpid::sys::Poller, qpid::sys::Socket const, qpid::sys::ConnectionCodec::Factory*, bool) (TCPIOPlugin.cpp:169) ==13674==by 0x4EABF69: boost::detail::function::void_function_obj_invoker1boost::_bi::bind_tvoid, boost::_mfi::mf4void, qpid::sys::AsynchIOProtocolFactory, boost::shared_ptrqpid::sys::Poller, qpid::sys::Socket const, qpid::sys::ConnectionCodec::Factory*, bool, boost::_bi::list5boost::_bi::valueqpid::sys::AsynchIOProtocolFactory*, boost::_bi::valueboost::shared_ptrqpid::sys::Poller , boost::arg1, boost::_bi::valueqpid::sys::ConnectionCodec::Factory*, boost::_bi::valuebool , void, qpid::sys::Socket const::invoke(boost::detail::function::function_buffer, qpid::sys::Socket const) (mem_fn_template.hpp:494) ==13674==by 0x528623D: qpid::sys::posix::AsynchAcceptor::readable(qpid::sys::DispatchHandle) (function_template.hpp:1013) ==13674==by 0x5364582: boost::function1void, qpid::sys::DispatchHandle::operator()(qpid::sys::DispatchHandle) const (function_template.hpp:1013) ==13674==by 0x53636D0: qpid::sys::DispatchHandle::processEvent(qpid::sys::Poller::EventType) (DispatchHandle.cpp:280) ==13674==by 0x5293491: qpid::sys::Poller::run() (Poller.h:131) ==13674==by 0x528B9B9: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==13674==by 0x388FE07850: start_thread (in /lib64/libpthread-2.12.so) ==13674==by 0x388F6E76DC: clone (in /lib64/libc-2.12.so) ==13674== ==13674== LEAK SUMMARY: ==13674==definitely lost: 32 bytes in 1 blocks ==13674==indirectly lost: 65,536 bytes in 1 blocks ==13674== possibly lost: 0 bytes in 0 blocks ==13674==still reachable: 7,911 bytes in 186 blocks ==13674== suppressed: 0 bytes in 0 blocks -- 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-2367) Early Initialization of File Descriptors Conflicts With Daemon Best Practices
[ https://issues.apache.org/jira/browse/QPID-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-2367. --- Resolution: Fixed Fix Version/s: 0.19 Early Initialization of File Descriptors Conflicts With Daemon Best Practices - Key: QPID-2367 URL: https://issues.apache.org/jira/browse/QPID-2367 Project: Qpid Issue Type: Improvement Components: C++ Client Affects Versions: 0.5 Environment: Linux (possibly all UNIX), c++, g++ Reporter: Jason Schlauch Assignee: Andrew Stitcher Fix For: 0.19 At least one file descriptor (in qpid/sys/epoll/EpollPoller.*) in the c++ client is global and declared as static. In programs linked against the c++ qpid libs g++ generates code for allocation and, more importantly, initialization of these descriptors that occurs before main(). You can confirm this with gdb by breakpointing both the initialization and main() (the initialization break is hit first). On the other hand, the canonical recipe for creating a UNIX daemon calls for the closing of all open file descriptors after fork()ing (where the fork() certainly occurs after main()). While not an absolute requirement, closing all open file descriptors is considered a best practice. A loop to close all descriptors is also common in boilerplate daemon creation code and has undoubtedly been cut-and-pasted into numerous daemons. The net effect is that the typical daemon will close the file descriptor opened before main() in the c++ client library. In the case of the epoll code this manifests as an inability to connect to the broker. A fix for this would be to defer the initialization of the file descriptor (perhaps via the Singleton pattern or a move of the variables into a class member). -- 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-4142) C++ broker connection counting username error when used in ha cluster and auth is EXTERNAL
[ https://issues.apache.org/jira/browse/QPID-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433495#comment-13433495 ] Andrew Stitcher commented on QPID-4142: --- I approve this fix going into 0.18 C++ broker connection counting username error when used in ha cluster and auth is EXTERNAL -- Key: QPID-4142 URL: https://issues.apache.org/jira/browse/QPID-4142 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Chuck Rolke In a cluster setup with auth enabled and set to EXTERNAL then the Acl connection counting does not get the correct username associated with a shadowed connection. The cluster member that accepts the connection accounts for the correct user name. Other cluster members that receive shadow connections see user name 'anonymous'. -- 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-4240) --link-maintenance-interval option is misspelled
Andrew Stitcher created QPID-4240: - Summary: --link-maintenance-interval option is misspelled Key: QPID-4240 URL: https://issues.apache.org/jira/browse/QPID-4240 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.16, 0.18 Reporter: Andrew Stitcher Assignee: Gordon Sim The new option --link-maintenance-interval is misspelled in cpp/src/qpid/broker/Broker.cpp line 172. It currently is spelt without the second n - --link-maintenace-interval Also this option has no documentation string. -- 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-3565) IPv6 support for SSL transport on Unix C++ client/broker
[ https://issues.apache.org/jira/browse/QPID-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-3565: - Assignee: Andrew Stitcher IPv6 support for SSL transport on Unix C++ client/broker Key: QPID-3565 URL: https://issues.apache.org/jira/browse/QPID-3565 Project: Qpid Issue Type: Sub-task Components: C++ Broker, C++ Client Environment: Unix Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3364) Segmentation fault when unloading shared libraries linked with libqpidmessaging
[
https://issues.apache.org/jira/browse/QPID-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445235#comment-13445235
]
Andrew Stitcher commented on QPID-3364:
---
There's nothing in that change that could/should have fixed any bug like this -
the // ### Hack Alert is really to point out an API which violates good
practice and shouldn't ever be used!
Additionally, I can't think of any good reason that could explain this bug
except runtime loader error.
So I'm happy to mark this as closed.
If it happens again we can reopen it!
Segmentation fault when unloading shared libraries linked with
libqpidmessaging
---
Key: QPID-3364
URL: https://issues.apache.org/jira/browse/QPID-3364
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10, 0.11, 0.14
Environment: Linux version 2.6.32-5-686 (Debian 2.6.32-34squeeze1)
(da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18
07:08:50 UTC 2011
Linux version 2.6.32-5-amd64 (Debian 2.6.32-34squeeze1) (da...@debian.org)
(gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18 23:13:22 UTC 2011
Reporter: Paul Colby
Priority: Minor
Attachments: loadee.cpp, loader.cpp, Makefile
Disclaimer: I'm not a dlopen/dlclose expert... I'm perfectly happy to be told
that I don't know what I'm doing! ;)
h3. Basic Description
If I create a shared object (that may or may not implement anything) that
links with libqpidmessaging (ie g++ ... -lqpidmessaging), and then create an
application that dlopen's that library, then dlclose's that library, then
that application will cause a seg-fault, which appears to be in the
libqpidmessaging library itself.
To demonstrate, I have a loadee.cpp file that contains just the following
unimportant code:
{code:title=loadee.cpp|borderStyle=solid}
void foo() { }
{code}
Then I build a loadee.so shared object like:
{noformat}
g++ -g -shared -lqpidmessaging -o loadee.so loadee.cpp
{noformat}
Next I have:
{code:title=loader.cpp|borderStyle=solid}
#include stdio.h
#include stdlib.h
#include dlfcn.h
int main(int c, char *argv[]) {
void *handle = dlopen(./loadee.so, RTLD_LAZY); // segfaults in dlclose
below.
//void *handle = dlopen(./loadee.so, RTLD_NOW); // no segfault.
if (!handle) {
fprintf(stderr, %s\n, dlerror());
exit(EXIT_FAILURE);
}
dlclose(handle);
return EXIT_SUCCESS;
}
{code}
Finally I build the loader program like:
{noformat}
g++ -g -rdynamic -o loader loader.cpp -ldl
{noformat}
Now, if I run the resulting loader program, then the program seg-faults in
libqpidmessaging. However, there is no such seg-fault (for me at least), if
I *either* remove the -lqpidmessaging flag from the first g++ command, *or*
change the flopen flags from RTLD_NOW to RTLD_LAZY (as indicated in the code
comments above).
h3. Tested Versions
I've tried this against the 0.8 and 0.10 tags, as well as trunk at r1148263,
with both Autotools and CMake.
h3. GDB
Unfortunately, gdb is not giving me much... very strange.
{noformat}
paul@debian:~/src/simple$ gdb ./loader
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/paul/src/simple/loader...done.
(gdb) run
Starting program: /home/paul/src/simple/loader
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
(gdb) bt
Target is executing.
(gdb) bt full
Target is executing.
(gdb) thread apply all bt
Cannot find new threads: generic error
(gdb)
{noformat}
h3. Valgrind
Valgrind is a little more interesting though...
{noformat}
paul@debian:~/src/simple$ valgrind --leak-check=full --show-reachable=yes
./loader
==31992== Memcheck, a memory error detector
==31992== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==31992== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==31992== Command: ./loader
==31992==
==31992== Jump to the invalid address stated on the next line
==31992==at 0x0: ???
==31992==by 0x41A1687: __cxa_finalize (cxa_finalize.c:56)
==31992==by 0x46ED0F3: ??? (in /usr/local/lib/libqpidmessaging.so.2.0.0)
==31992==by 0x473091F: ??? (in /usr/local/lib/libqpidmessaging.so.2.0.0)
==31992==by 0x401271D: _dl_close_worker
[jira] [Closed] (QPID-3364) Segmentation fault when unloading shared libraries linked with libqpidmessaging
[
https://issues.apache.org/jira/browse/QPID-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher closed QPID-3364.
-
Resolution: Cannot Reproduce
This issue seems to have gone away
Segmentation fault when unloading shared libraries linked with
libqpidmessaging
---
Key: QPID-3364
URL: https://issues.apache.org/jira/browse/QPID-3364
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10, 0.11, 0.14
Environment: Linux version 2.6.32-5-686 (Debian 2.6.32-34squeeze1)
(da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18
07:08:50 UTC 2011
Linux version 2.6.32-5-amd64 (Debian 2.6.32-34squeeze1) (da...@debian.org)
(gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18 23:13:22 UTC 2011
Reporter: Paul Colby
Priority: Minor
Attachments: loadee.cpp, loader.cpp, Makefile
Disclaimer: I'm not a dlopen/dlclose expert... I'm perfectly happy to be told
that I don't know what I'm doing! ;)
h3. Basic Description
If I create a shared object (that may or may not implement anything) that
links with libqpidmessaging (ie g++ ... -lqpidmessaging), and then create an
application that dlopen's that library, then dlclose's that library, then
that application will cause a seg-fault, which appears to be in the
libqpidmessaging library itself.
To demonstrate, I have a loadee.cpp file that contains just the following
unimportant code:
{code:title=loadee.cpp|borderStyle=solid}
void foo() { }
{code}
Then I build a loadee.so shared object like:
{noformat}
g++ -g -shared -lqpidmessaging -o loadee.so loadee.cpp
{noformat}
Next I have:
{code:title=loader.cpp|borderStyle=solid}
#include stdio.h
#include stdlib.h
#include dlfcn.h
int main(int c, char *argv[]) {
void *handle = dlopen(./loadee.so, RTLD_LAZY); // segfaults in dlclose
below.
//void *handle = dlopen(./loadee.so, RTLD_NOW); // no segfault.
if (!handle) {
fprintf(stderr, %s\n, dlerror());
exit(EXIT_FAILURE);
}
dlclose(handle);
return EXIT_SUCCESS;
}
{code}
Finally I build the loader program like:
{noformat}
g++ -g -rdynamic -o loader loader.cpp -ldl
{noformat}
Now, if I run the resulting loader program, then the program seg-faults in
libqpidmessaging. However, there is no such seg-fault (for me at least), if
I *either* remove the -lqpidmessaging flag from the first g++ command, *or*
change the flopen flags from RTLD_NOW to RTLD_LAZY (as indicated in the code
comments above).
h3. Tested Versions
I've tried this against the 0.8 and 0.10 tags, as well as trunk at r1148263,
with both Autotools and CMake.
h3. GDB
Unfortunately, gdb is not giving me much... very strange.
{noformat}
paul@debian:~/src/simple$ gdb ./loader
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/paul/src/simple/loader...done.
(gdb) run
Starting program: /home/paul/src/simple/loader
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
(gdb) bt
Target is executing.
(gdb) bt full
Target is executing.
(gdb) thread apply all bt
Cannot find new threads: generic error
(gdb)
{noformat}
h3. Valgrind
Valgrind is a little more interesting though...
{noformat}
paul@debian:~/src/simple$ valgrind --leak-check=full --show-reachable=yes
./loader
==31992== Memcheck, a memory error detector
==31992== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==31992== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==31992== Command: ./loader
==31992==
==31992== Jump to the invalid address stated on the next line
==31992==at 0x0: ???
==31992==by 0x41A1687: __cxa_finalize (cxa_finalize.c:56)
==31992==by 0x46ED0F3: ??? (in /usr/local/lib/libqpidmessaging.so.2.0.0)
==31992==by 0x473091F: ??? (in /usr/local/lib/libqpidmessaging.so.2.0.0)
==31992==by 0x401271D: _dl_close_worker (dl-close.c:271)
==31992==by 0x4013196: _dl_close (dl-close.c:742)
==31992==by 0x4034CA3: dlclose_doit (dlclose.c:37)
==31992==by 0x400D7F5: _dl_catch_error (dl-error.c:178)
==31992==by 0x403509B: _dlerror_run (dlerror.c:164)
==31992==by 0x4034CD9: dlclose (dlclose.c:48)
==31992==by 0x8048812: main (loader.cpp:12)
==31992== Address 0x0 is not
[jira] [Created] (QPID-4272) Large amounts of code are duplicated between the SSL and TCP transports
Andrew Stitcher created QPID-4272: - Summary: Large amounts of code are duplicated between the SSL and TCP transports Key: QPID-4272 URL: https://issues.apache.org/jira/browse/QPID-4272 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3618) c++ broker dies if federation link is flaky and errors out
[ https://issues.apache.org/jira/browse/QPID-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3618: -- Fix Version/s: (was: 0.15) c++ broker dies if federation link is flaky and errors out -- Key: QPID-3618 URL: https://issues.apache.org/jira/browse/QPID-3618 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.12 Environment: Linux, ARM platform. Limited hardware resources. Federation link over a cellular data connection. Reporter: Brandon Pedersen Assignee: Andrew Stitcher Labels: federation, push PROBLEM STATEMENT: I have a durable queue push route configured to send messages to a central broker. The link between the source broker and the destination broker is a flaky cellular connection. When the link goes on and off it will very frequently cause the broker to seg fault and die. STEPS TO REPRODUCE: This is tricky to reproduce but it most often occurs when the physical data connection is just being brought up. i.e. the cell connection went down, qpid releases the connectionafter a while the connection comes back up and qpid tries to reconnect *possibly* (not certain) when the connection has not been completely set up. RESULTS: The broker receives some sort of data frame before the connection is fully established and therefore throws and exception. During this process it appears there is another thread that accesses some pointer that is invalid and causes the program to die. LOGS: The log shows the following messages just before dieing: Nov 14 15:43:35 mtcdp daemon.err qpidd[6790]: 2011-11-14 15:43:35 error Connection local:55764-remote:5672 closed by error: Connection not yet open, invalid frame received.(501) Nov 14 15:43:35 mtcdp daemon.err qpidd[6790]: 2011-11-14 15:43:35 error Connection local:55764-remote:5672 closed by error: Connection not yet open, invalid frame received.(501) Notice that the connection error message shows up twice, this seems suspicious to me. This occurs every time the broker dies. I got a core dump from the seg fault (a couple of times) and this is the backtrace Core was generated by `qpidd'. Program terminated with signal 11, Segmentation fault. #0 0x403fdc98 in qpid::SessionState::disableReceiverTracking() () from /usr/lib/libqpidcommon.so.2 (gdb) backtrace #0 0x403fdc98 in qpid::SessionState::disableReceiverTracking() () from /usr/lib/libqpidcommon.so.2 #1 0x4010e8a8 in qpid::broker::Bridge::create(qpid::broker::Connection) () from /usr/lib/libqpidbroker.so.2 #2 0x4017ed18 in qpid::broker::Link::ioThreadProcessing() () from /usr/lib/libqpidbroker.so.2 #3 0x40180920 in ?? () from /usr/lib/libqpidbroker.so.2 Cannot access memory at address 0x2d74c0f8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3633) Make cmake the primary build tool for the cpp tree
[ https://issues.apache.org/jira/browse/QPID-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481224#comment-13481224 ] Andrew Stitcher commented on QPID-3633: --- committed changes r1400780-r1400783 which bring the cmake install target fairly closely into line with the automake install target. Make cmake the primary build tool for the cpp tree -- Key: QPID-3633 URL: https://issues.apache.org/jira/browse/QPID-3633 Project: Qpid Issue Type: Improvement Components: Build Tools Affects Versions: 0.19 Reporter: Justin Ross Assignee: Andrew Stitcher This will serve as a tracker for the steps remaining to prepare cmake to be our primary (and very probably only) build tool for the cpp tree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-3633) Make cmake the primary build tool for the cpp tree
[ https://issues.apache.org/jira/browse/QPID-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481224#comment-13481224 ] Andrew Stitcher edited comment on QPID-3633 at 10/22/12 6:59 AM: - committed changes r1400780-r1400783 for 0.20 which bring the cmake install target fairly closely into line with the automake install target. was (Author: astitcher): committed changes r1400780-r1400783 which bring the cmake install target fairly closely into line with the automake install target. Make cmake the primary build tool for the cpp tree -- Key: QPID-3633 URL: https://issues.apache.org/jira/browse/QPID-3633 Project: Qpid Issue Type: Improvement Components: Build Tools Affects Versions: 0.19 Reporter: Justin Ross Assignee: Andrew Stitcher This will serve as a tracker for the steps remaining to prepare cmake to be our primary (and very probably only) build tool for the cpp tree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3633) Make cmake the primary build tool for the cpp tree
[ https://issues.apache.org/jira/browse/QPID-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481463#comment-13481463 ] Andrew Stitcher commented on QPID-3633: --- This last issue has nothing really to do with this issue - it's just a different bug that has crept into the source base coincidentally at the same time. Make cmake the primary build tool for the cpp tree -- Key: QPID-3633 URL: https://issues.apache.org/jira/browse/QPID-3633 Project: Qpid Issue Type: Improvement Components: Build Tools Affects Versions: 0.19 Reporter: Justin Ross Assignee: Andrew Stitcher This will serve as a tracker for the steps remaining to prepare cmake to be our primary (and very probably only) build tool for the cpp tree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4272) Large amounts of code are duplicated between the SSL and TCP transports
[ https://issues.apache.org/jira/browse/QPID-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13483013#comment-13483013 ] Andrew Stitcher commented on QPID-4272: --- With checkins r1401558-r1401561 this is now greatly improved, with the only significant duplication left in the client SslConnector.cpp and TCPConnector.cpp code. Large amounts of code are duplicated between the SSL and TCP transports --- Key: QPID-4272 URL: https://issues.apache.org/jira/browse/QPID-4272 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4272) Large amounts of code are duplicated between the SSL and TCP transports
[ https://issues.apache.org/jira/browse/QPID-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4272: -- Fix Version/s: 0.19 Large amounts of code are duplicated between the SSL and TCP transports --- Key: QPID-4272 URL: https://issues.apache.org/jira/browse/QPID-4272 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.19 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4272) Large amounts of code are duplicated between the SSL and TCP transports
[ https://issues.apache.org/jira/browse/QPID-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4272. --- Resolution: Fixed There are only small amounts of duplicated code left Large amounts of code are duplicated between the SSL and TCP transports --- Key: QPID-4272 URL: https://issues.apache.org/jira/browse/QPID-4272 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.19 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3565) IPv6 support for SSL transport on Unix C++ client/broker
[ https://issues.apache.org/jira/browse/QPID-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3565: -- Fix Version/s: 0.19 IPv6 support for SSL transport on Unix C++ client/broker Key: QPID-3565 URL: https://issues.apache.org/jira/browse/QPID-3565 Project: Qpid Issue Type: Sub-task Components: C++ Broker, C++ Client Environment: Unix Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.19 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-3565) IPv6 support for SSL transport on Unix C++ client/broker
[ https://issues.apache.org/jira/browse/QPID-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3565. --- Resolution: Fixed Due to the refactoring that happened for QPID-4272 the SSL code now shares the same connection establishment code as TCP in all cases so SSL over IPv6 should now work as it does for IPv4. IPv6 support for SSL transport on Unix C++ client/broker Key: QPID-3565 URL: https://issues.apache.org/jira/browse/QPID-3565 Project: Qpid Issue Type: Sub-task Components: C++ Broker, C++ Client Environment: Unix Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.19 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-1132) Add support for Sun Studio compiler suite detection
[ https://issues.apache.org/jira/browse/QPID-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-1132. --- Resolution: Won't Fix Add support for Sun Studio compiler suite detection --- Key: QPID-1132 URL: https://issues.apache.org/jira/browse/QPID-1132 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: M3 Environment: Sun Studio 12 on Solaris 10 Reporter: Manuel Teira Assignee: Andrew Stitcher Priority: Minor Attachments: suncc.patch Support for Sun Studio 12 detection in configure.ac. Includes: Detection of the Sun C++ compiler Using particular warning flags on Sun C++ compiler Adding flags needed for boost usage on Sun Compilers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4435) Reconnect on connect failure hangs at third address to try
Andrew Stitcher created QPID-4435: - Summary: Reconnect on connect failure hangs at third address to try Key: QPID-4435 URL: https://issues.apache.org/jira/browse/QPID-4435 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Environment: Linux Reporter: Andrew Stitcher Assignee: Andrew Stitcher Necessary conditions to trigger hang: * You are connecting to a name that resolves to 3 or more underlying network addresses. * The first 2 addresses refuse the connection (there is no daemon listening on the appropriate port at that address). In this case the client will attempt to connect to the third resolved address, but will hang forever waiting. If you look at a server log that is listening on the third address then you will eventually see: ... error Connection ... No protocol received closing because the server has received the connection and made the initial reply but has not heard back in the alloted time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
