Re: Cannot connect to RabbitMQ 3.3.5 using qpid-client-0.30
Hi Nathan, This works! In RabbitMQ was necessary: - to create virtual host with /, for example: /MY_VIRTUAL_HOST. - to create a queue in above virtual host - to bind using a routing key with the same name of above queue ... and run Hello.java ! Regards. - wr
JMS Destination handling for AMQP 1.0
Hi everyone (please use reply-all to keep both lists on the trail), I would like to have a discussion around JMS destination handling in the JMS Mapping for AMQP 1.0, in particular around how to handle JMS Destination names via the AMQP address field of a link (producer/consumer) source/target and the to, and reply-to field of messages. Apologies for the length of the mail, there is a fair bit to outline. I moved some information for full context to the end to help a tiny bit. JMS defines multiple Destination types that each have their own inherent name space, so it is possible for example to have a Queue and a Topic with the same name (e.g foo). AMQP defines an address field on the source/target of links (producers/consumers), and a to and reply-to field are available on messages, to indicate the destination node (e.g queue/topic) address. These are typically string values, and they form a single space since as there is no additional node type information only the address name itself. This is is mostly an issue for non-temporary Queues and Topics since TemporaryQueue and TemporaryTopic destinations will be given generated addresses by the 'broker' peer through use of dynamic nodes, and so can naturally be prevented from having the same addresses as each other, and be made unlikely or unable to clash with non-temporary nodes. To handle this mapping between JMS and AMQP it would seem we must either: 1. Not support JMS Queues and Topics with the same name existing at all, OR 2. Allow multiple nodes to have the same address string but use type metadata (via capabilities + annotations, see additional context) to discriminate between them, OR 3. Utilise address string naming conventions (e.g prefixes) for them to separate the types into subspaces. The first option is an issue for implementations that already do, and wish to continue to, allow Queues and Topics with the same name via other protocols while also supporting AMQP, and would be a limitation in terms of full JMS support. The second option would break reply-to usage for any clients or intermediaries that don't understand the message annotations and/or source+target capabilities carrying type metadata (see additional context). The third option either requires clients to always utilise the full address strings in session.createQueue(queue-prefixfoo) etc calls, or providing a means to configure the prefixes within the client so that they are added/removed behind the scenes and the application just uses session.createQueue(foo), but the resulting AMQP address string would be queue-prefixfoo. The main issue with requiring clients always use the full address as the session.createQueue(..) value would be for bridging between different systems using different conventions, though the values for those methods are noted as being provider-specific. Both the old Qpid AMQP 1.0 JMS client, and the new JMS client we are creating that implements the JMS Mapping for AMQP being worked on, currently do some form of the third option, providing a way to configure a 'queue prefix' and 'topic prefix' that are used to prefix the application provided strings in session.createQueue(..) etc for outgoing addresses used for links and messages and be stripped from incoming addresses on messages to give the names used for the JMSDestination and JMSReplyTo objects. Temporary destinations are named by the 'broker' peer and their addresses are used as provided. The main issue with this approach is that such configuration makes it more difficult to use the client against a number of different brokers, which is a goal, since this configuration is likely to differ between them meaning even the simplest HelloWorld type example may be unable to work against them without additional configuration. Between ActiveMQ and Qpid we currently appear to have 3 different options for our brokers (two different prefixes being required, or it being optional [at the cost of being unable to support Queues and Topics with the same name]), and considering others would likely expand this. An idea to handle this was to have the brokers use connection properties to inform the client of the prefixes (if any) they require it to use, allowing different brokers to supply their own specific value (if any) to meet their requirements, and allowing clients/simple applications to work against many of them without further configuration change. An alternative suggestion was to have the JMS Mapping define a set of standard name prefixes the client would use by default, such that the issue of Topics and Queues with the same name is addressed by the mapping, while also allowing brokers to specify their own values via connection properties so that their specific needs can still be met if different (e.g they have existing naming conventions they wish/need to retain). There was also a suggestion that something beyond a simple prefix may be needed, I will let the person behind those thoughts expand further to stop
Re: JMS Destination handling for AMQP 1.0
On 17 December 2014 at 13:37, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi everyone (please use reply-all to keep both lists on the trail), I would like to have a discussion around JMS destination handling in the JMS Mapping for AMQP 1.0, in particular around how to handle JMS Destination names via the AMQP address field of a link (producer/consumer) source/target and the to, and reply-to field of messages. Apologies for the length of the mail, there is a fair bit to outline. I moved some information for full context to the end to help a tiny bit. JMS defines multiple Destination types that each have their own inherent name space, so it is possible for example to have a Queue and a Topic with the same name (e.g foo). AMQP defines an address field on the source/target of links (producers/consumers), and a to and reply-to field are available on messages, to indicate the destination node (e.g queue/topic) address. These are typically string values, and they form a single space since as there is no additional node type information only the address name itself. This is is mostly an issue for non-temporary Queues and Topics since TemporaryQueue and TemporaryTopic destinations will be given generated addresses by the 'broker' peer through use of dynamic nodes, and so can naturally be prevented from having the same addresses as each other, and be made unlikely or unable to clash with non-temporary nodes. To handle this mapping between JMS and AMQP it would seem we must either: 1. Not support JMS Queues and Topics with the same name existing at all, OR 2. Allow multiple nodes to have the same address string but use type metadata (via capabilities + annotations, see additional context) to discriminate between them, OR 3. Utilise address string naming conventions (e.g prefixes) for them to separate the types into subspaces. As per the OASIS TC call yesterday, I think option 3 is the only truly viable solution here. The first option is an issue for implementations that already do, and wish to continue to, allow Queues and Topics with the same name via other protocols while also supporting AMQP, and would be a limitation in terms of full JMS support. The second option would break reply-to usage for any clients or intermediaries that don't understand the message annotations and/or source+target capabilities carrying type metadata (see additional context). The third option either requires clients to always utilise the full address strings in session.createQueue(queue-prefixfoo) etc calls, or providing a means to configure the prefixes within the client so that they are added/removed behind the scenes and the application just uses session.createQueue(foo), but the resulting AMQP address string would be queue-prefixfoo. The main issue with requiring clients always use the full address as the session.createQueue(..) value would be for bridging between different systems using different conventions, though the values for those methods are noted as being provider-specific. Both the old Qpid AMQP 1.0 JMS client, and the new JMS client we are creating that implements the JMS Mapping for AMQP being worked on, currently do some form of the third option, providing a way to configure a 'queue prefix' and 'topic prefix' that are used to prefix the application provided strings in session.createQueue(..) etc for outgoing addresses used for links and messages and be stripped from incoming addresses on messages to give the names used for the JMSDestination and JMSReplyTo objects. Temporary destinations are named by the 'broker' peer and their addresses are used as provided. The main issue with this approach is that such configuration makes it more difficult to use the client against a number of different brokers, which is a goal, since this configuration is likely to differ between them meaning even the simplest HelloWorld type example may be unable to work against them without additional configuration. Between ActiveMQ and Qpid we currently appear to have 3 different options for our brokers (two different prefixes being required, or it being optional [at the cost of being unable to support Queues and Topics with the same name]), and considering others would likely expand this. An idea to handle this was to have the brokers use connection properties to inform the client of the prefixes (if any) they require it to use, allowing different brokers to supply their own specific value (if any) to meet their requirements, and allowing clients/simple applications to work against many of them without further configuration change. An alternative suggestion was to have the JMS Mapping define a set of standard name prefixes the client would use by default, such that the issue of Topics and Queues with the same name is addressed by the mapping, while also allowing brokers to specify their own values via connection properties so that their specific needs
Compiling qpid on aix 6.1 with xlc 13.1.0
Hi, We have abandoned using gcc on aix to compile qpid and have now moved on to our next problem child, xlc. Boost compiled successfully, but when we try to compile qpid, an argument mismatch apparently occurs. The environment description and details are below. The associated files are attached. If anyone can offer any insight into what is wrong or has any suggestions on what we should try to resolve this, your assistance will be gratefully accepted. Regards, Chris Whelan # environment export CC=/opt/IBM/xlC/13.1.0/bin/xlc export CXX=/opt/IBM/xlC/13.1.0/bin/xlc++ export BOOST_ROOT=/home/dbapi/enquesta_5_0/boost_1_57_0 # for xlC: export PATH=/opt/IBM/xlC/13.1.0/bin:$PATH # for other dependencies built locally export PATH=/home/dbapi/enquesta_5_0/usr/local/bin:$PATH Email attachments: cmakeOutput.txt is the output from running cmake makeAllOutput.txt is the output from the compile (make all) vector.t is an IBM source file, /opt/IBM/xlC/13.1.0/include/vector.t InlineVector.h is from qpid source, $QPID_HOME/src/qpid/InlineVector.h The error from makeAllOutput.txt (make all command) /opt/IBM/xlC/13.1.0/include/vector.t, line 41.55: 1540-0215 (S) The wrong numb er of arguments has been specified for qpid::InlineAllocatorstd::allocatorqpi d::Rangeqpid::framing::SequenceNumber ,3::allocate(size_type). /opt/IBM/xlC/13.1.0/include/vector.t, line 37.6: 1540-0700 (I) The previous me ssage was produced while processing std::vectorqpid::Rangeqpid::framing::Sequ enceNumber,qpid::InlineAllocatorstd::allocatorqpid::Rangeqpid::framing::Sequ enceNumber ,3 ::reserve(size_type). /home/dbapi/enquesta_5_0/qpid-cpp-0.30/src/qpid/InlineVector.h, line 50.13: 15 40-0700 (I) The previous message was produced while processing qpid::InlineVect orqpid::Rangeqpid::framing::SequenceNumber,3,std::allocatorqpid::Rangeqpid: :framing::SequenceNumber ::InlineVector(const allocator_type ). aixdev2:/home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld $cmake .. Build type is *RelWithDebInfo* (has debug symbols) -- The C compiler identification is XL 13.1.0 -- The CXX compiler identification is XL 13.1.0 -- Check for working C compiler: /opt/IBM/xlC/13.1.0/bin/xlc -- Check for working C compiler: /opt/IBM/xlC/13.1.0/bin/xlc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /opt/IBM/xlC/13.1.0/bin/xlc++ -- Check for working CXX compiler: /opt/IBM/xlC/13.1.0/bin/xlc++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found PythonInterp: /usr/bin/python (found version 2.7.5) -- Found PkgConfig: /usr/bin/pkg-config (found version 0.19) -- Found Ruby: /usr/local/bin/ruby (found version 2.0.0) -- Found Doxygen: /usr/local/bin/doxygen (found version 1.5.1) -- Could NOT find VALGRIND (missing: VALGRIND_EXECUTABLE) -- Looking for sasl_checkpass in sasl2 -- Looking for sasl_checkpass in sasl2 - not found -- Looking for include file sasl/sasl.h -- Looking for include file sasl/sasl.h - not found -- Could NOT find SASL (missing: FOUND_SASL_LIB FOUND_SASL_H) -- Regenerating AMQP protocol sources Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/MethodBodyConstVisitor.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/MethodBodyDefaultVisitor.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/MethodBodyDefaultVisitor.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/MethodBodyFactory.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_ClientOperations.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_ServerOperations.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_AllOperations.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/ClientInvoker.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/ClientInvoker.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/ServerInvoker.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/ServerInvoker.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AllInvoker.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AllInvoker.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_ClientProxy.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_ClientProxy.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_ServerProxy.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_ServerProxy.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_AllProxy.h Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/qpid/framing/AMQP_AllProxy.cpp Generated /home/dbapi/enquesta_5_0/qpid-cpp-0.30/bld/src/../include/qpid/client/no_keyword/AsyncSession_0_10.h Generated
Re: JMS Destination handling for AMQP 1.0
On 17 December 2014 at 13:43, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 13:37, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi everyone (please use reply-all to keep both lists on the trail), I would like to have a discussion around JMS destination handling in the JMS Mapping for AMQP 1.0, in particular around how to handle JMS Destination names via the AMQP address field of a link (producer/consumer) source/target and the to, and reply-to field of messages. Apologies for the length of the mail, there is a fair bit to outline. I moved some information for full context to the end to help a tiny bit. JMS defines multiple Destination types that each have their own inherent name space, so it is possible for example to have a Queue and a Topic with the same name (e.g foo). AMQP defines an address field on the source/target of links (producers/consumers), and a to and reply-to field are available on messages, to indicate the destination node (e.g queue/topic) address. These are typically string values, and they form a single space since as there is no additional node type information only the address name itself. This is is mostly an issue for non-temporary Queues and Topics since TemporaryQueue and TemporaryTopic destinations will be given generated addresses by the 'broker' peer through use of dynamic nodes, and so can naturally be prevented from having the same addresses as each other, and be made unlikely or unable to clash with non-temporary nodes. To handle this mapping between JMS and AMQP it would seem we must either: 1. Not support JMS Queues and Topics with the same name existing at all, OR 2. Allow multiple nodes to have the same address string but use type metadata (via capabilities + annotations, see additional context) to discriminate between them, OR 3. Utilise address string naming conventions (e.g prefixes) for them to separate the types into subspaces. As per the OASIS TC call yesterday, I think option 3 is the only truly viable solution here. In case my expansions below dont make it clear enough, so do I. The first option is an issue for implementations that already do, and wish to continue to, allow Queues and Topics with the same name via other protocols while also supporting AMQP, and would be a limitation in terms of full JMS support. The second option would break reply-to usage for any clients or intermediaries that don't understand the message annotations and/or source+target capabilities carrying type metadata (see additional context). The third option either requires clients to always utilise the full address strings in session.createQueue(queue-prefixfoo) etc calls, or providing a means to configure the prefixes within the client so that they are added/removed behind the scenes and the application just uses session.createQueue(foo), but the resulting AMQP address string would be queue-prefixfoo. The main issue with requiring clients always use the full address as the session.createQueue(..) value would be for bridging between different systems using different conventions, though the values for those methods are noted as being provider-specific. Both the old Qpid AMQP 1.0 JMS client, and the new JMS client we are creating that implements the JMS Mapping for AMQP being worked on, currently do some form of the third option, providing a way to configure a 'queue prefix' and 'topic prefix' that are used to prefix the application provided strings in session.createQueue(..) etc for outgoing addresses used for links and messages and be stripped from incoming addresses on messages to give the names used for the JMSDestination and JMSReplyTo objects. Temporary destinations are named by the 'broker' peer and their addresses are used as provided. The main issue with this approach is that such configuration makes it more difficult to use the client against a number of different brokers, which is a goal, since this configuration is likely to differ between them meaning even the simplest HelloWorld type example may be unable to work against them without additional configuration. Between ActiveMQ and Qpid we currently appear to have 3 different options for our brokers (two different prefixes being required, or it being optional [at the cost of being unable to support Queues and Topics with the same name]), and considering others would likely expand this. An idea to handle this was to have the brokers use connection properties to inform the client of the prefixes (if any) they require it to use, allowing different brokers to supply their own specific value (if any) to meet their requirements, and allowing clients/simple applications to work against many of them without further configuration change. An alternative suggestion was to have the JMS Mapping define a set of standard name prefixes the client would use by default, such that the issue of Topics and Queues with the same name
Re: JMS Destination handling for AMQP 1.0
On 17 December 2014 at 15:45, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 13:43, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 13:37, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi everyone (please use reply-all to keep both lists on the trail), I would like to have a discussion around JMS destination handling in the JMS Mapping for AMQP 1.0, in particular around how to handle JMS Destination names via the AMQP address field of a link (producer/consumer) source/target and the to, and reply-to field of messages. Apologies for the length of the mail, there is a fair bit to outline. I moved some information for full context to the end to help a tiny bit. JMS defines multiple Destination types that each have their own inherent name space, so it is possible for example to have a Queue and a Topic with the same name (e.g foo). AMQP defines an address field on the source/target of links (producers/consumers), and a to and reply-to field are available on messages, to indicate the destination node (e.g queue/topic) address. These are typically string values, and they form a single space since as there is no additional node type information only the address name itself. This is is mostly an issue for non-temporary Queues and Topics since TemporaryQueue and TemporaryTopic destinations will be given generated addresses by the 'broker' peer through use of dynamic nodes, and so can naturally be prevented from having the same addresses as each other, and be made unlikely or unable to clash with non-temporary nodes. To handle this mapping between JMS and AMQP it would seem we must either: 1. Not support JMS Queues and Topics with the same name existing at all, OR 2. Allow multiple nodes to have the same address string but use type metadata (via capabilities + annotations, see additional context) to discriminate between them, OR 3. Utilise address string naming conventions (e.g prefixes) for them to separate the types into subspaces. As per the OASIS TC call yesterday, I think option 3 is the only truly viable solution here. In case my expansions below dont make it clear enough, so do I. The first option is an issue for implementations that already do, and wish to continue to, allow Queues and Topics with the same name via other protocols while also supporting AMQP, and would be a limitation in terms of full JMS support. The second option would break reply-to usage for any clients or intermediaries that don't understand the message annotations and/or source+target capabilities carrying type metadata (see additional context). The third option either requires clients to always utilise the full address strings in session.createQueue(queue-prefixfoo) etc calls, or providing a means to configure the prefixes within the client so that they are added/removed behind the scenes and the application just uses session.createQueue(foo), but the resulting AMQP address string would be queue-prefixfoo. The main issue with requiring clients always use the full address as the session.createQueue(..) value would be for bridging between different systems using different conventions, though the values for those methods are noted as being provider-specific. Both the old Qpid AMQP 1.0 JMS client, and the new JMS client we are creating that implements the JMS Mapping for AMQP being worked on, currently do some form of the third option, providing a way to configure a 'queue prefix' and 'topic prefix' that are used to prefix the application provided strings in session.createQueue(..) etc for outgoing addresses used for links and messages and be stripped from incoming addresses on messages to give the names used for the JMSDestination and JMSReplyTo objects. Temporary destinations are named by the 'broker' peer and their addresses are used as provided. The main issue with this approach is that such configuration makes it more difficult to use the client against a number of different brokers, which is a goal, since this configuration is likely to differ between them meaning even the simplest HelloWorld type example may be unable to work against them without additional configuration. Between ActiveMQ and Qpid we currently appear to have 3 different options for our brokers (two different prefixes being required, or it being optional [at the cost of being unable to support Queues and Topics with the same name]), and considering others would likely expand this. An idea to handle this was to have the brokers use connection properties to inform the client of the prefixes (if any) they require it to use, allowing different brokers to supply their own specific value (if any) to meet their requirements, and allowing clients/simple applications to work against many of them without further configuration change. An alternative
How to create a Destination to RabbitMQ custom exchange using qpid-client-0.30
Hi there again! I am trying to connect to RabbitMQ queue (AMQP 0-9-1) via custom exchange using Destination (Binding URL) without success. I have tried several definitions of destination, here my JNDI config: --.-- connectionfactory.myRabbitMQConnectionFactory1 = amqp://admin:xxx@clientid /DES_DEV?brokerlist='tcp://10.105.135.53:5672' destination.myDestination1 = direct://ex_test1/rk_test1/q_test1 destination.myDestination2 = direct://ex_test1//q_test1?autodelete='false'durable='true'internal='false'routingkey='q_test1' destination.myDestination3 = direct://ex_test1//q_test1?routingkey='rk_test1' --.-- My Java code is: ---.---.-- System.setProperty(qpid.amqp.version, 0-91); *System.setProperty(qpid.dest_**syntax, BURL);* ... ConnectionFactory connectionFactory = (ConnectionFactory) context.lookup(myRabbitMQConnectionFactory1); Connection connection = connectionFactory.createConnection(); connection.start(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); TextMessage message = session.createTextMessage(Hello world - DESTINATION BURL !!); Destination destination = (Destination) context.lookup(myJndiDirectDestination1); // tested with 1, 2 and Destination3 MessageProducer messageProducerD = session.createProducer(destination); messageProducerD.send(message); ... ---.---.--- Here, my custom exchange is ex_test1 and I have used different values for routing keys. I have to created previously the exchange (ex_test1) with different routing keys, for example: binding-a) ex_test1 ~ rk_test1 ~ q_test1 binding-b) ex_test1 ~ empty ~ q_test1 binding-c) ex_test1 ~ q_test1 ~ q_test1 binding-d) amq.direct ~ q_test1 ~ q_test1 binding-e) amq.direct ~ rk_test1 ~ q_test1 When running this code, no errors are shown, only *binding-d* and *binding-e* work and the message is published in RabbitMQ. They have in the header thw following: Exchange : amq.direct headers: JMS_QPID_DESTTYPE:1 What is the correct definition of DESTINATION using custom exchange? Thanks. -- wr
Re: JMS Destination handling for AMQP 1.0
On 17 December 2014 at 17:25, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 15:00, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 15:45, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 13:43, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 13:37, Robbie Gemmell robbie.gemm...@gmail.com wrote: [.. snip ..] Any more concrete thoughts/examples? Nothing concrete... more just wanting to avoid premature standardisation on something we later find to be inadequate for the eventual requirement. Ok. I'm trying to figure out if I am on the same page. Are you thinking of something that would simply be used to decide whether a given fixed/supplied prefix was used or not (e.g apply this fixed/given prefix if this regex matched anything in the given JMS 'name' string), or something more complicated that might decide what to apply based on what matched? It may be that it is sufficient to say prefix + exclusion pattern, e.g. prefix with queue: unless the name begins with $ or / - that would probably cover all the cases I can currently think of (global addressing and magic $ addresses) Another consideration might be special addresses, like $management which the server would not want to be mangled but which we would still want to make easily accessible through session.createQueue(). Good point. Thoughts? A quick thought on Destination equivalence - I'm guessing that in JMS terms two Destinations are equal iff they are of the same type (Topic/Queue/etc - derived from meta-data) and use the same *mangled* AMQP address? -- Rob If the name mangling is conducted on the way out of the client to form an AMQP address from the initial 'JMS name', and reversed on the way in to the client to give the 'JMS name' used for getJMSDestination/getJMSReplyTo, then I guess two Destination objects would be considered equal if they had the same type and same 'JMS Name'. I was thinking that we would potentially want to avoid having to have a reversible mangling algorithm. IIRC you can't extract the name from a Destination object after it has been created. I dont think we can get away without reversability. All the concrete Destination objects JMS specifies let you retrieve the name, via getQueueName() or getTopicName(). Thats how you figure out where the message was sent or should be returned to if you use getJMSDestination()/getJMSReplyTo(). I forgot about getQueueName() / getTopicName() but you shouldn't be using them for anything if you are looking for portability should you? However I do take your point that you would potential want to have a demangling function so that getQueueName() could be computed from the AMQP address. the AMQP address is the real identity as far as AMQP is concerned. Moreover there may be some addresses (even within systems which have distinct queue and topic domains) which exist within other domains, or which live outside the domains ($management for example) Sure, but the JMS objects wont necessarily know about the exact AMQP address unless we always make the application provide the full AMQP address or decide on a single fixed prefix that can be applied/removed within the destination objects themselves. Huh? If you have a name mangling function that turns X - f(X) (where f(X) is the AMQP address) then createQueue( X ) can know f(X) and messages that come from the wire are going to be aware of f(X) (the AMQP address) since that is what they are built from. You shouldn't need to know the JMS name in order to test equality. When do you think that the JMS objects would not know (be able to calculate) the AMQP address? The only funkiness might be if you were bridging between two JMS over AMQP connections where the prefix in use on the different connections was different. In that case I'm not sure that two addresses can ever be considered equal. Special addresses like $management might really live outside the domains, but the client is ultimately going to access them via the domains, e.g session.createQueue($management) from your example I was using domain to mean a namespace within the AMQP address space. $management does not live within queue:* or topic:* earlier, which will give a JMS object that gets compared like any other unless the client is made specifically aware of those special addresses in some way. -- Rob -- Rob Robbie Additional Context: We also need to transmit the destination type information during link (e.g producer/consumer) attachment and on sent messages to ensure we can support the required JMS behaviours (e.g. to indicate we are attaching to a particular type of node, say a queue, and for carrying JMSDestination and JMSReplyTo type on messages to indicate/discover where a message
Re: JMS Destination handling for AMQP 1.0
On 17 December 2014 at 16:46, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 17:25, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 15:00, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 15:45, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 13:43, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 13:37, Robbie Gemmell robbie.gemm...@gmail.com wrote: [.. snip ..] Any more concrete thoughts/examples? Nothing concrete... more just wanting to avoid premature standardisation on something we later find to be inadequate for the eventual requirement. Ok. I'm trying to figure out if I am on the same page. Are you thinking of something that would simply be used to decide whether a given fixed/supplied prefix was used or not (e.g apply this fixed/given prefix if this regex matched anything in the given JMS 'name' string), or something more complicated that might decide what to apply based on what matched? It may be that it is sufficient to say prefix + exclusion pattern, e.g. prefix with queue: unless the name begins with $ or / - that would probably cover all the cases I can currently think of (global addressing and magic $ addresses) Another consideration might be special addresses, like $management which the server would not want to be mangled but which we would still want to make easily accessible through session.createQueue(). Good point. Thoughts? A quick thought on Destination equivalence - I'm guessing that in JMS terms two Destinations are equal iff they are of the same type (Topic/Queue/etc - derived from meta-data) and use the same *mangled* AMQP address? -- Rob If the name mangling is conducted on the way out of the client to form an AMQP address from the initial 'JMS name', and reversed on the way in to the client to give the 'JMS name' used for getJMSDestination/getJMSReplyTo, then I guess two Destination objects would be considered equal if they had the same type and same 'JMS Name'. I was thinking that we would potentially want to avoid having to have a reversible mangling algorithm. IIRC you can't extract the name from a Destination object after it has been created. I dont think we can get away without reversability. All the concrete Destination objects JMS specifies let you retrieve the name, via getQueueName() or getTopicName(). Thats how you figure out where the message was sent or should be returned to if you use getJMSDestination()/getJMSReplyTo(). I forgot about getQueueName() / getTopicName() but you shouldn't be using them for anything if you are looking for portability should you? No, and you shouldnt really use session.createQueue() either...but, its what lots of people do. However I do take your point that you would potential want to have a demangling function so that getQueueName() could be computed from the AMQP address. the AMQP address is the real identity as far as AMQP is concerned. Moreover there may be some addresses (even within systems which have distinct queue and topic domains) which exist within other domains, or which live outside the domains ($management for example) Sure, but the JMS objects wont necessarily know about the exact AMQP address unless we always make the application provide the full AMQP address or decide on a single fixed prefix that can be applied/removed within the destination objects themselves. Huh? If you have a name mangling function that turns X - f(X) (where f(X) is the AMQP address) then createQueue( X ) can know f(X) and messages that come from the wire are going to be aware of f(X) (the AMQP address) since that is what they are built from. You shouldn't need to know the JMS name in order to test equality. When do you think that the JMS objects would not know (be able to calculate) the AMQP address? The only funkiness might be if you were bridging between two JMS over AMQP connections where the prefix in use on the different connections was different. In that case I'm not sure that two addresses can ever be considered equal. That is one case I am thinking of. Destinations coming from JNDI rather than session.createQueue() being another, when the connection doesnt necessarily even exist, and isnt able to be referred to if it does. We could make destinations not created via session.createQueue(..) etc always require the full AMQP address string be provided of course, though then you might get some weirdness around getQueueName() behaviour between objects created via JNDI (which might not have access to f(x) or its reversal depending on how we define them) and those created e.g by a consumer (which would have access) after a message arrives. I have typically thought of 'provider specific' in the past to distinguish between different client+broker pairs, however
Re: How to create a Destination to RabbitMQ custom exchange using qpid-client-0.30
On 12/17/2014 10:45 AM, Wayna Runa wrote: Hi there again! I am trying to connect to RabbitMQ queue (AMQP 0-9-1) via custom exchange using Destination (Binding URL) without success. I have tried several definitions of destination, here my JNDI config: --.-- connectionfactory.myRabbitMQConnectionFactory1 = amqp://admin:xxx@clientid /DES_DEV?brokerlist='tcp://10.105.135.53:5672' destination.myDestination1 = direct://ex_test1/rk_test1/q_test1 destination.myDestination2 = direct://ex_test1//q_test1?autodelete='false'durable='true'internal='false'routingkey='q_test1' destination.myDestination3 = direct://ex_test1//q_test1?routingkey='rk_test1' --.-- Hi, If you want to send to the exchange, regardless of the bound queues, then don't specify a queue. destination.myDestination1 = BURL:direct://ex_text1/rk_test1/ If you specify the queue name, somewhere along the line RabbitMQ expects a queue of that name to be pre-bound to the exchange or it drops the message with an error. So the queue name shouldn't be used for sending messages, however, a routing key is expected (even though this isn't clear from any of the Qpid, RabbitMQ, or AMQP docs). The RabbitMQ web management interface is really helpful as it will also show you connections, channels, and queue consumers. Hope that helps, Nathan My Java code is: ---.---.-- System.setProperty(qpid.amqp.version, 0-91); *System.setProperty(qpid.dest_**syntax, BURL);* ... ConnectionFactory connectionFactory = (ConnectionFactory) context.lookup(myRabbitMQConnectionFactory1); Connection connection = connectionFactory.createConnection(); connection.start(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); TextMessage message = session.createTextMessage(Hello world - DESTINATION BURL !!); Destination destination = (Destination) context.lookup(myJndiDirectDestination1); // tested with 1, 2 and Destination3 MessageProducer messageProducerD = session.createProducer(destination); messageProducerD.send(message); ... ---.---.--- Here, my custom exchange is ex_test1 and I have used different values for routing keys. I have to created previously the exchange (ex_test1) with different routing keys, for example: binding-a) ex_test1 ~ rk_test1 ~ q_test1 binding-b) ex_test1 ~ empty ~ q_test1 binding-c) ex_test1 ~ q_test1 ~ q_test1 binding-d) amq.direct ~ q_test1 ~ q_test1 binding-e) amq.direct ~ rk_test1 ~ q_test1 When running this code, no errors are shown, only *binding-d* and *binding-e* work and the message is published in RabbitMQ. They have in the header thw following: Exchange : amq.direct headers: JMS_QPID_DESTTYPE:1 What is the correct definition of DESTINATION using custom exchange? Thanks. -- wr This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: JMS Destination handling for AMQP 1.0
On 17 December 2014 at 18:37, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 16:46, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 17:25, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 15:00, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 15:45, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 17 December 2014 at 13:43, Rob Godfrey rob.j.godf...@gmail.com wrote: On 17 December 2014 at 13:37, Robbie Gemmell robbie.gemm...@gmail.com wrote: [.. snip ..] Any more concrete thoughts/examples? Nothing concrete... more just wanting to avoid premature standardisation on something we later find to be inadequate for the eventual requirement. Ok. I'm trying to figure out if I am on the same page. Are you thinking of something that would simply be used to decide whether a given fixed/supplied prefix was used or not (e.g apply this fixed/given prefix if this regex matched anything in the given JMS 'name' string), or something more complicated that might decide what to apply based on what matched? It may be that it is sufficient to say prefix + exclusion pattern, e.g. prefix with queue: unless the name begins with $ or / - that would probably cover all the cases I can currently think of (global addressing and magic $ addresses) Another consideration might be special addresses, like $management which the server would not want to be mangled but which we would still want to make easily accessible through session.createQueue(). Good point. Thoughts? A quick thought on Destination equivalence - I'm guessing that in JMS terms two Destinations are equal iff they are of the same type (Topic/Queue/etc - derived from meta-data) and use the same *mangled* AMQP address? -- Rob If the name mangling is conducted on the way out of the client to form an AMQP address from the initial 'JMS name', and reversed on the way in to the client to give the 'JMS name' used for getJMSDestination/getJMSReplyTo, then I guess two Destination objects would be considered equal if they had the same type and same 'JMS Name'. I was thinking that we would potentially want to avoid having to have a reversible mangling algorithm. IIRC you can't extract the name from a Destination object after it has been created. I dont think we can get away without reversability. All the concrete Destination objects JMS specifies let you retrieve the name, via getQueueName() or getTopicName(). Thats how you figure out where the message was sent or should be returned to if you use getJMSDestination()/getJMSReplyTo(). I forgot about getQueueName() / getTopicName() but you shouldn't be using them for anything if you are looking for portability should you? No, and you shouldnt really use session.createQueue() either...but, its what lots of people do. Yes, and looking at the JavaDoc it seems like it is indirectly implied but not actually defined, that Queue q2 = session.createQueue(q1.getQueueName()); should result in q1.equals(q2) returning true. So, can you think of any case where prefix + some sort of exclusion (prefix) pattern would not work? Depending on what makes a valid name in the other systems you are aware of we could maybe even fix the black/white list of addresses that do(n't) get prefixed. Certainly I think we'd want to avoid prefixing anything that began / or $ ... but we might want to try to restrict as many characters as possible if this doesn't interfere with existing systems which need prefixing that we know about However I do take your point that you would potential want to have a demangling function so that getQueueName() could be computed from the AMQP address. the AMQP address is the real identity as far as AMQP is concerned. Moreover there may be some addresses (even within systems which have distinct queue and topic domains) which exist within other domains, or which live outside the domains ($management for example) Sure, but the JMS objects wont necessarily know about the exact AMQP address unless we always make the application provide the full AMQP address or decide on a single fixed prefix that can be applied/removed within the destination objects themselves. Huh? If you have a name mangling function that turns X - f(X) (where f(X) is the AMQP address) then createQueue( X ) can know f(X) and messages that come from the wire are going to be aware of f(X) (the AMQP address) since that is what they are built from. You shouldn't need to know the JMS name in order to test equality. When do you think that the JMS objects would not know (be able to calculate) the AMQP address? The only funkiness might be if you were bridging between two JMS over
Re: How to create a Destination to RabbitMQ custom exchange using qpid-client-0.30
Thanks Nathan for your information. I tried with: destination.myDest1 = BURL:direct://ex_test1/rk_test1/ .. but I have not get to publish message in RabbitMQ queue. When I use the below destinations, using *amq.direct* exchange (internal and default exchanges in rabbitmq), I can publish messages in the queue successfully. destination.myDest2 = BURL:direct://amq.direct//q_test1 (publish msg w/ routingkey=q_test1) destination.myDest3 = BURL:direct://amq.direc/q_test1/q_test1 (publish msg w/ routingkey=q_test1) destination.myDest4 = BURL:direct://amq.direc//q_test1?routingkey='rk_test1'(publish msg w/ routingkey=rk_test1) destination.myDest5 = BURL:direct://amq.direct//?routingkey='rk_test1' (publish msg w/ routingkey=rk_test1) ...but i would try with this custom preconfigured exchange (ex_test1). any idea will be welcome. regards.
Re: How to create a Destination to RabbitMQ custom exchange using qpid-client-0.30
On 12/17/2014 01:15 PM, Wayna Runa wrote: Thanks Nathan for your information. I tried with: destination.myDest1 = BURL:direct://ex_test1/rk_test1/ .. but I have not get to publish message in RabbitMQ queue. When I use the below destinations, using *amq.direct* exchange (internal and default exchanges in rabbitmq), I can publish messages in the queue successfully. destination.myDest2 = BURL:direct://amq.direct//q_test1 (publish msg w/ routingkey=q_test1) destination.myDest3 = BURL:direct://amq.direc/q_test1/q_test1 (publish msg w/ routingkey=q_test1) destination.myDest4 = BURL:direct://amq.direc//q_test1?routingkey='rk_test1'(publish msg w/ routingkey=rk_test1) destination.myDest5 = BURL:direct://amq.direct//?routingkey='rk_test1' (publish msg w/ routingkey=rk_test1) ...but i would try with this custom preconfigured exchange (ex_test1). any idea will be welcome. regards. Hi, Setup a loop to send about 10 messages in about 10 seconds. Watch the RabbitMQ management page. Do you see traffic coming into the exchange? Any traffic out through any queues? AMQP is rather odd in that an exchange does not hold messages. Queues hold messages. So, if a message arrives at an exchange but there are no queues bound with the matching routing key, it drops the message. For a direct exchange, upon receiving a message with routing key that matches a binding, the message is then stored in the queue. Hope that helps, Nathan This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Compiling qpid on aix 6.1 with xlc 13.1.0
Hi Chris, In your makeAllOutput.txt file you are getting boost (1_57) warnings right off the bat. I've never used any boost beyond 1_53 on linux or windows but 1_53 works on both of those platforms. Could you try downgrading your boost to 1_53, a known good on Windows and Linux version? -Chuck - Original Message - From: Chris Whelan chris.whe...@systemsandsoftware.net To: users@qpid.apache.org Sent: Wednesday, December 17, 2014 9:31:35 AM Subject: Compiling qpid on aix 6.1 with xlc 13.1.0 Hi, We have abandoned using gcc on aix to compile qpid and have now moved on to our next problem child, xlc. Boost compiled successfully, but when we try to compile qpid, an argument mismatch apparently occurs. The environment description and details are below. The associated files are attached. If anyone can offer any insight into what is wrong or has any suggestions on what we should try to resolve this, your assistance will be gratefully accepted. Regards, Chris Whelan # environment export CC=/opt/IBM/xlC/13.1.0/bin/xlc export CXX=/opt/IBM/xlC/13.1.0/bin/xlc++ export BOOST_ROOT=/home/dbapi/enquesta_5_0/boost_1_57_0 # for xlC: export PATH=/opt/IBM/xlC/13.1.0/bin:$PATH # for other dependencies built locally export PATH=/home/dbapi/enquesta_5_0/usr/local/bin:$PATH Email attachments: cmakeOutput.txt is the output from running cmake makeAllOutput.txt is the output from the compile (make all) vector.t is an IBM source file, /opt/IBM/xlC/13.1.0/include/vector.t InlineVector.h is from qpid source, $QPID_HOME/src/qpid/InlineVector.h The error from makeAllOutput.txt (make all command) /opt/IBM/xlC/13.1.0/include/vector.t, line 41.55: 1540-0215 (S) The wrong numb er of arguments has been specified for qpid::InlineAllocatorstd::allocatorqpi d::Rangeqpid::framing::SequenceNumber ,3::allocate(size_type). /opt/IBM/xlC/13.1.0/include/vector.t, line 37.6: 1540-0700 (I) The previous me ssage was produced while processing std::vectorqpid::Rangeqpid::framing::Sequ enceNumber,qpid::InlineAllocatorstd::allocatorqpid::Rangeqpid::framing::Sequ enceNumber ,3 ::reserve(size_type). /home/dbapi/enquesta_5_0/qpid-cpp-0.30/src/qpid/InlineVector.h, line 50.13: 15 40-0700 (I) The previous message was produced while processing qpid::InlineVect orqpid::Rangeqpid::framing::SequenceNumber,3,std::allocatorqpid::Rangeqpid: :framing::SequenceNumber ::InlineVector(const allocator_type ). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Compiling qpid on aix 6.1 with xlc 13.1.0
I don't think the boost warnings are pertinent in this case, and boost is tough to get built with xlC, so for the time being, I'd let that dog lie. It smells like a mismatch between std::vector arguments between xlC and what the code expects. I'd chase that one down first. If I get done with customer commitments today I will check into it later. -Steve -Original Message- From: Chuck Rolke [mailto:cro...@redhat.com] Sent: Wednesday, December 17, 2014 3:00 PM To: users@qpid.apache.org Subject: Re: Compiling qpid on aix 6.1 with xlc 13.1.0 Hi Chris, In your makeAllOutput.txt file you are getting boost (1_57) warnings right off the bat. I've never used any boost beyond 1_53 on linux or windows but 1_53 works on both of those platforms. Could you try downgrading your boost to 1_53, a known good on Windows and Linux version? -Chuck - Original Message - From: Chris Whelan chris.whe...@systemsandsoftware.net To: users@qpid.apache.org Sent: Wednesday, December 17, 2014 9:31:35 AM Subject: Compiling qpid on aix 6.1 with xlc 13.1.0 Hi, We have abandoned using gcc on aix to compile qpid and have now moved on to our next problem child, xlc. Boost compiled successfully, but when we try to compile qpid, an argument mismatch apparently occurs. The environment description and details are below. The associated files are attached. If anyone can offer any insight into what is wrong or has any suggestions on what we should try to resolve this, your assistance will be gratefully accepted. Regards, Chris Whelan # environment export CC=/opt/IBM/xlC/13.1.0/bin/xlc export CXX=/opt/IBM/xlC/13.1.0/bin/xlc++ export BOOST_ROOT=/home/dbapi/enquesta_5_0/boost_1_57_0 # for xlC: export PATH=/opt/IBM/xlC/13.1.0/bin:$PATH # for other dependencies built locally export PATH=/home/dbapi/enquesta_5_0/usr/local/bin:$PATH Email attachments: cmakeOutput.txt is the output from running cmake makeAllOutput.txt is the output from the compile (make all) vector.t is an IBM source file, /opt/IBM/xlC/13.1.0/include/vector.t InlineVector.h is from qpid source, $QPID_HOME/src/qpid/InlineVector.h The error from makeAllOutput.txt (make all command) /opt/IBM/xlC/13.1.0/include/vector.t, line 41.55: 1540-0215 (S) The wrong numb er of arguments has been specified for qpid::InlineAllocatorstd::allocatorqpi d::Rangeqpid::framing::SequenceNumber ,3::allocate(size_type). /opt/IBM/xlC/13.1.0/include/vector.t, line 37.6: 1540-0700 (I) The previous me ssage was produced while processing std::vectorqpid::Rangeqpid::framing::Sequ enceNumber,qpid::InlineAllocatorstd::allocatorqpid::Rangeqpid::fra enceNumberming::Sequ enceNumber ,3 ::reserve(size_type). /home/dbapi/enquesta_5_0/qpid-cpp-0.30/src/qpid/InlineVector.h, line 50.13: 15 40-0700 (I) The previous message was produced while processing qpid::InlineVect orqpid::Rangeqpid::framing::SequenceNumber,3,std::allocatorqpid::Ra ngeqpid: :framing::SequenceNumber ::InlineVector(const allocator_type ). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Compiling qpid on aix 6.1 with xlc 13.1.0
Thanks Steve and Chuck. I will hold off on downgrading boost. I don't know if it will help at all, but I am also trying to get approval to lease a clean AIX 7.1 environment to try the compile in, but I am not sure what the timeline will be for that. Regards, Chris -Original Message- From: Steve Huston [mailto:shus...@riverace.com] Sent: Wednesday, December 17, 2014 3:08 PM To: users@qpid.apache.org Subject: RE: Compiling qpid on aix 6.1 with xlc 13.1.0 I don't think the boost warnings are pertinent in this case, and boost is tough to get built with xlC, so for the time being, I'd let that dog lie. It smells like a mismatch between std::vector arguments between xlC and what the code expects. I'd chase that one down first. If I get done with customer commitments today I will check into it later. -Steve -Original Message- From: Chuck Rolke [mailto:cro...@redhat.com] Sent: Wednesday, December 17, 2014 3:00 PM To: users@qpid.apache.org Subject: Re: Compiling qpid on aix 6.1 with xlc 13.1.0 Hi Chris, In your makeAllOutput.txt file you are getting boost (1_57) warnings right off the bat. I've never used any boost beyond 1_53 on linux or windows but 1_53 works on both of those platforms. Could you try downgrading your boost to 1_53, a known good on Windows and Linux version? -Chuck - Original Message - From: Chris Whelan chris.whe...@systemsandsoftware.net To: users@qpid.apache.org Sent: Wednesday, December 17, 2014 9:31:35 AM Subject: Compiling qpid on aix 6.1 with xlc 13.1.0 Hi, We have abandoned using gcc on aix to compile qpid and have now moved on to our next problem child, xlc. Boost compiled successfully, but when we try to compile qpid, an argument mismatch apparently occurs. The environment description and details are below. The associated files are attached. If anyone can offer any insight into what is wrong or has any suggestions on what we should try to resolve this, your assistance will be gratefully accepted. Regards, Chris Whelan # environment export CC=/opt/IBM/xlC/13.1.0/bin/xlc export CXX=/opt/IBM/xlC/13.1.0/bin/xlc++ export BOOST_ROOT=/home/dbapi/enquesta_5_0/boost_1_57_0 # for xlC: export PATH=/opt/IBM/xlC/13.1.0/bin:$PATH # for other dependencies built locally export PATH=/home/dbapi/enquesta_5_0/usr/local/bin:$PATH Email attachments: cmakeOutput.txt is the output from running cmake makeAllOutput.txt is the output from the compile (make all) vector.t is an IBM source file, /opt/IBM/xlC/13.1.0/include/vector.t InlineVector.h is from qpid source, $QPID_HOME/src/qpid/InlineVector.h The error from makeAllOutput.txt (make all command) /opt/IBM/xlC/13.1.0/include/vector.t, line 41.55: 1540-0215 (S) The wrong numb er of arguments has been specified for qpid::InlineAllocatorstd::allocatorqpi d::Rangeqpid::framing::SequenceNumber ,3::allocate(size_type). /opt/IBM/xlC/13.1.0/include/vector.t, line 37.6: 1540-0700 (I) The previous me ssage was produced while processing std::vectorqpid::Rangeqpid::framing::Sequ enceNumber,qpid::InlineAllocatorstd::allocatorqpid::Rangeqpid::f enceNumberra enceNumberming::Sequ enceNumber ,3 ::reserve(size_type). /home/dbapi/enquesta_5_0/qpid-cpp-0.30/src/qpid/InlineVector.h, line 50.13: 15 40-0700 (I) The previous message was produced while processing qpid::InlineVect orqpid::Rangeqpid::framing::SequenceNumber,3,std::allocatorqpid::R a ngeqpid: :framing::SequenceNumber ::InlineVector(const allocator_type ). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P \Y \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ \Y \X K ܙ B B - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
How to auto-reconnect from java.net.SocketException: Connection reset
Hello i need to handle this exception java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at sun.security.ssl.InputRecord.readFully(Unknown Source) at sun.security.ssl.InputRecord.read(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source) at sun.security.ssl.AppInputStream.read(Unknown Source) at java.io.InputStream.read(Unknown Source) at org.apache.qpid.amqp_1_0.client.TCPTransportProvier.doRead(TCPTransportProvier.java:207) at org.apache.qpid.amqp_1_0.client.TCPTransportProvier.access$000(TCPTransportProvier.java:43) at org.apache.qpid.amqp_1_0.client.TCPTransportProvier$1.run(TCPTransportProvier.java:158) at java.lang.Thread.run(Unknown Source) and reconnect to the server. any idea? Thx in advance. -- View this message in context: http://qpid.2158936.n2.nabble.com/How-to-auto-reconnect-from-java-net-SocketException-Connection-reset-tp7617695.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
