Re: Java failover manager
Arnaud, That is a bug as the failover should reset itself each time a connection is made. It would be nice though at some point to separate retry strategy from failover, but that is potentially a much larger piece of work. Cheers Martin 2009/3/3 Rajith Attapattu rajit...@gmail.com: I too agree with Arnaud. By default it makes sense to keep retrying the list of brokers until all nodes are down. Regards, Rajith - Show quoted text - On Tue, Mar 3, 2009 at 11:17 AM, Arnaud Simon asi...@redhat.com wrote: Hello, I have been playing with our 0.10 cluster. When testing it I used a java client and 2 brokers. I quickly ran into this issue: org.apache.qpid.transport.ConnectionException: connection closed at org.apache.qpid.transport.Connection.send(Connection.java:294) at org.apache.qpid.transport.Session.send(Session.java:455) at org.apache.qpid.transport.Session.invoke(Session.java:599) It appears that this is an expected behaviour of our default Java failover manager. The default heuristic is to go roundrobin through the list of brokers. This is fine really but our implementation does not reset the cursor position after a successful failover. This means that if you failover from A to B you will never failover from B to A anymore (assuming that our list of broker only contains two brokers A and B). So, there is an optional parameter cyclecount that can be used to define the number of times to loop through the list of available brokers before failure. If this parameter can be used to solve the issue of failing over to A after a successful failover from A to B, it does solve this issue only for cyclecount times :( Moreover, I believe that we don't really want to cycle through all the brokers more than once when all the nodes of the broker are down. We rather want to define a kind of back-retry mechanism. I would suggest that default implementation of our roundrobin failover manbager should be changed to reset the cursor position within the broker list to the current broker. Moreover, I believe that some people are currently implementing a failover manager that uses a failover exchange. I am wondering whether this manager shouldn't the default manager for our 0.10 client? Please let me know what you think. Should we open a JIRA? Thanks Arnaud - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Show quoted text - - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1711) Federation bridging sessions get command id sequence out of sync
Federation bridging sessions get command id sequence out of sync Key: QPID-1711 URL: https://issues.apache.org/jira/browse/QPID-1711 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: M5 general symptom is something like: invalid-argument: confirmed (65535+0) but only sent (65533+0) (qpid/SessionState.cpp:150) seen when running a federation link with acknowledgements turned on for a long period (i.e. lots of messages, exact number depends on the ack frequency selected). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1609) Heartbeat support for java client
[ https://issues.apache.org/jira/browse/QPID-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678672#action_12678672 ] Jan Sarenik commented on QPID-1609: --- IIRC the future is commonly referred to as keepalive. Heartbeat support for java client - Key: QPID-1609 URL: https://issues.apache.org/jira/browse/QPID-1609 Project: Qpid Issue Type: New Feature Components: Java Client Affects Versions: M5 Reporter: Rajith Attapattu Assignee: Rafael H. Schloming Fix For: M5 Attachments: QPID-1609-test.patch, QPID-1609.patch Add heartbeat support for the java client as defined in the AMQP spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1673) Dynamic Library Build on Windows (DLL)
[ https://issues.apache.org/jira/browse/QPID-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678682#action_12678682 ] shan wang commented on QPID-1673: - the qpid-1673 branch built successfully. Thanks for your help. My next question is: how can I get the necessary header files? Unlike building on linux, visual studio doesn't generate a include directory with header files. I only need the headers for client. Dynamic Library Build on Windows (DLL) -- Key: QPID-1673 URL: https://issues.apache.org/jira/browse/QPID-1673 Project: Qpid Issue Type: New Feature Reporter: Danushka Menikkumbura Assignee: Steve Huston Attachments: create_dir_struct.bat, QPID-1673-examples-solution.patch, QPID-1673-examples-solution.v2.patch, QPID-1673-examples.patch, QPID-1673-INSTALL-WINDOWS.patch, QPID-1673-INSTALL-WINDOWS.v2, QPID-1673-qpid-solution.patch, QPID-1673-qpid-solution.v2.patch, QPID-1673-rubygen.patch, QPID-1673-rubygen.v2.patch, QPID-1673-src-qpid-amqp_0_10.patch, QPID-1673-src-qpid-amqp_0_10.v2.patch, QPID-1673-src-qpid-broker.patch, QPID-1673-src-qpid-client.patch, QPID-1673-src-qpid-client.v2.patch, QPID-1673-src-qpid-console.patch, QPID-1673-src-qpid-framing.patch, QPID-1673-src-qpid-framing.v2.patch, QPID-1673-src-qpid-log.patch, QPID-1673-src-qpid-log.v2.patch, QPID-1673-src-qpid-management.patch, QPID-1673-src-qpid-management.v2.patch, QPID-1673-src-qpid-sys.patch, QPID-1673-src-qpid-sys.v2.patch, QPID-1673-src-qpid.patch, QPID-1673-src-qpid.v2.patch, QPID-1673-src.patch, QPID-1673-src.v2.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1711) Federation bridging sessions get command id sequence out of sync
[ https://issues.apache.org/jira/browse/QPID-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-1711. -- Resolution: Fixed Fixed by r750002. Federation bridging sessions get command id sequence out of sync Key: QPID-1711 URL: https://issues.apache.org/jira/browse/QPID-1711 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: M5 general symptom is something like: invalid-argument: confirmed (65535+0) but only sent (65533+0) (qpid/SessionState.cpp:150) seen when running a federation link with acknowledgements turned on for a long period (i.e. lots of messages, exact number depends on the ack frequency selected). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r749473 - in /qpid/trunk/qpid/cpp: src/ src/qpid/cluster/ src/qpid/framing/ src/tests/ xml/
On Tue, Mar 3, 2009 at 5:58 PM, Gordon Sim g...@redhat.com wrote: Aidan Skinner wrote: Stil broken for me, I'm at 749627: Try 749669. That fixed it, thanks! :) - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: make check failure -- CPP broker svn pull
Adam Chase wrote: Make check was flawless on 32 bit linux with g++ 4.3.2. Got errors on a 64 bit linux g++ 3.4.4. It crashes pretty regularly on this platform. Is this platform supported? Thanks, Adam - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org Have you got a backtrace on the core file? Carl.
[jira] Created: (QPID-1712) Roundrobin failover policy does not reset the cursor position after a successful failover.
Roundrobin failover policy does not reset the cursor position after a successful failover. --- Key: QPID-1712 URL: https://issues.apache.org/jira/browse/QPID-1712 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4 Reporter: Arnaud Simon Fix For: M5 Description: The default roundrobin failover policy does not reset the cursor position after a successful failover. This means that if you failover from A to B you will never failover from B to A anymore (assuming that our list of broker only contains two brokers A and B). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1712) Roundrobin failover policy does not reset the cursor position after a successful failover.
[ https://issues.apache.org/jira/browse/QPID-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Simon reassigned QPID-1712: -- Assignee: Arnaud Simon Roundrobin failover policy does not reset the cursor position after a successful failover. --- Key: QPID-1712 URL: https://issues.apache.org/jira/browse/QPID-1712 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4 Reporter: Arnaud Simon Assignee: Arnaud Simon Fix For: M5 Description: The default roundrobin failover policy does not reset the cursor position after a successful failover. This means that if you failover from A to B you will never failover from B to A anymore (assuming that our list of broker only contains two brokers A and B). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Qpid Graduation release
We're live: http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104STORY=/www/story/03-04-2009/0004982759EDATE= --- On Mon, 3/2/09, Sally Khudairi s...@haloworldwide.com wrote: From: Sally Khudairi s...@haloworldwide.com Subject: Re: Qpid Graduation release To: cctriel...@redhat.com, dev@qpid.apache.org Cc: ASF PRC Team p...@apache.org Date: Monday, March 2, 2009, 11:46 PM Thanks, Carl. The PRC plans to release the Qpid announcement over the news wire on Wednesday. We'll be happy to forward the link once it's live. Again, congratulations on becoming a TLP! Cheers, Sally --- On Mon, 3/2/09, Carl Trieloff cctriel...@redhat.com wrote: From: Carl Trieloff cctriel...@redhat.com Subject: Re: Qpid Graduation release To: s...@haloworldwide.com Cc: ASF PRC Team p...@apache.org Date: Monday, March 2, 2009, 9:51 AM Sally, John is also fine with the edits. thanks for spotting them. If you can give us a day notice before it is released, and link once it is that would be great. thank you, Carl. Sally Khudairi wrote: Thanks so much, Carl. We look forward to hearing from you :-) Kind regards, Sally --- On Sun, 3/1/09, Carl Trieloff cctriel...@redhat.com wrote: From: Carl Trieloff cctriel...@redhat.com Subject: Re: Qpid Graduation release To: s...@haloworldwide.com Cc: ASF PRC Team p...@apache.org Date: Sunday, March 1, 2009, 9:31 PM Both edits are great, I will confirm with John tomorrow. Thanks Carl. Sally Khudairi wrote: Thanks, Carl. I've made some slight adjustments to the draft, which I've just forwarded to the the PRC for their review. I'm attaching a Word version of this as a heads-up to you, and am happy to send over line-by-line diffs to both you and dev@qpid.apache.org once the PRC gets a chance to review my edits. Please note that I'm suggesting a slight tweak to your quote to read: On the heels of its recent graduation, Qpid has also reached the completion of the major Qpid M4 release. We're thrilled to have our project's growth and maturity recognized by the Apache Software Foundation, said Carl Trieloff, Chair of the Apache Qpid Project Management Committee (PMC) and Senior Consulting Software Engineer at Red Hat. With the promotion to an Apache Top-Level Project, Qpid is recognized for outstanding development based on our vibrant, rapidly expanding community, infrastructure and for collaborative development. ... this was primarily to clarify positioning, make the capitalization of everyone's titles consistent (yours were lowercase), and alleviate some of the words repeated elsewhere. Also -- and this is important -- can you please follow through with John O'Hara the following suggested correction to his quote: John O'Hara, Chairman of the AMQP Working Group and Executive Director at JPMorgan said, I am delighted that the Apache Software Foundation has graduated the Qpid Project... (his original quote states ...has graduated the Qpid AMQP server..., but that's not what graduated, the Project did.) Thanks in advance for this. Also, if we receive the go-ahead from the PRC, we are aiming to release this on the wire on Tuesday, 3 March. I'll keep you posted. Again, many thanks for your kind patience :-) Warm regards, Sally --- On Fri, 2/27/09, Carl Trieloff cctriel...@redhat.com wrote: From: Carl Trieloff cctriel...@redhat.com Subject: Re: Qpid Graduation release To: s...@haloworldwide.com Cc: ASF PRC Team p...@apache.org Date: Friday, February 27, 2009, 10:21 AM Sally, thank you, it will be good to have the proof, make sure I had everything in the right tone etc. will watch for the edits kind regards, Carl. Sally Khudairi wrote: Hello Carl, Thanks for your note. I'll be forwarding some suggested edits to the team tomorrow. Hopefully we can issue the announcement early next week if all is clear. Kind regards, Sally --- On Thu, 2/26/09, Carl Trieloff cctriel...@redhat.com wrote: From: Carl Trieloff cctriel...@redhat.com Subject: Re: Qpid Graduation release To: ASF PRC Team p...@apache.org Date: Thursday, February 26, 2009, 2:22 PM Sally, Any eta on when we would
[jira] Resolved: (QPID-1712) Roundrobin failover policy does not reset the cursor position after a successful failover.
[ https://issues.apache.org/jira/browse/QPID-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Simon resolved QPID-1712. Resolution: Fixed The value of _cycleRetries was 0 as a default hence resulting in the failoverAllowed method returning false once the last broker within the list was reached. Roundrobin failover policy does not reset the cursor position after a successful failover. --- Key: QPID-1712 URL: https://issues.apache.org/jira/browse/QPID-1712 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4 Reporter: Arnaud Simon Assignee: Arnaud Simon Fix For: M5 Description: The default roundrobin failover policy does not reset the cursor position after a successful failover. This means that if you failover from A to B you will never failover from B to A anymore (assuming that our list of broker only contains two brokers A and B). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1673) Dynamic Library Build on Windows (DLL)
[ https://issues.apache.org/jira/browse/QPID-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678747#action_12678747 ] shan wang commented on QPID-1673: - I built qpid.sln with broker, client and common projects, all the libs are fine but no deploy folder created. Which should the deploy residence? From the outpu of visual studio it didn't try to copy files or create new directories. Do I need to set up something in solution config to make it work? Dynamic Library Build on Windows (DLL) -- Key: QPID-1673 URL: https://issues.apache.org/jira/browse/QPID-1673 Project: Qpid Issue Type: New Feature Reporter: Danushka Menikkumbura Assignee: Steve Huston Attachments: create_dir_struct.bat, QPID-1673-examples-solution.patch, QPID-1673-examples-solution.v2.patch, QPID-1673-examples.patch, QPID-1673-INSTALL-WINDOWS.patch, QPID-1673-INSTALL-WINDOWS.v2, QPID-1673-qpid-solution.patch, QPID-1673-qpid-solution.v2.patch, QPID-1673-rubygen.patch, QPID-1673-rubygen.v2.patch, QPID-1673-src-qpid-amqp_0_10.patch, QPID-1673-src-qpid-amqp_0_10.v2.patch, QPID-1673-src-qpid-broker.patch, QPID-1673-src-qpid-client.patch, QPID-1673-src-qpid-client.v2.patch, QPID-1673-src-qpid-console.patch, QPID-1673-src-qpid-framing.patch, QPID-1673-src-qpid-framing.v2.patch, QPID-1673-src-qpid-log.patch, QPID-1673-src-qpid-log.v2.patch, QPID-1673-src-qpid-management.patch, QPID-1673-src-qpid-management.v2.patch, QPID-1673-src-qpid-sys.patch, QPID-1673-src-qpid-sys.v2.patch, QPID-1673-src-qpid.patch, QPID-1673-src-qpid.v2.patch, QPID-1673-src.patch, QPID-1673-src.v2.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: make check failure -- CPP broker svn pull
On Tue, 2009-03-03 at 21:43 -0500, Adam Chase wrote: Make check was flawless on 32 bit linux with g++ 4.3.2. Got errors on a 64 bit linux g++ 3.4.4. It crashes pretty regularly on this platform. Is this platform supported? You're going to have to be a little more specific than that! What are the platforms you are talking about? OS/Version valgrind version We test on 64 bit Linux (Red Hat 4/5, Fedora 9,10) all the time so these platforms should definitely work From a cursory look at your output I'd say it is what we'd expect from a platform we'd not tested before - we commonly see different valgrind complaints (many valid some not) when we use a platform we've not tested on before. BTW the it that is crashing is the unit test not the broker or client themselves. A crash in the unit_test like that will cause a lot of leak records because the program will be interrupted before cleaning up normally, so take the leaks with a grain of salt. The fact that the rest of the test fails to run makes me suspicious something funny is going on though with the make could ti be because you are using NFS for your build directory? Hope that helps/sheds some light. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: make check failure -- CPP broker svn pull
It is definitely possible that the build could have caused some of the issues. That's why I listed the compiler version. valgrind = 3.3. The OS and version is rare: Linux version 2.6.24.7-9.smp.gcc3.4.x86_64 (rap-master.rpath@rpath:linux-1-devel) (gcc version 3.4.4) #1 SMP Tue Jul 15 12:23:51 EDT 2008 But I have been able to get M4 to build on it with minor finagling. Also now it builds more easily just --enable-warnings=no. Would it help to send a log of the compile? I can try and dig into this more deeply if that would help. Unfortunately I am not able to convince people to upgrade our version of g++ and I think this is the most likely suspect (though I have no evidence of this). The broker definitely does crash regularly. The last point I log a message from my client, I had queried for a queue and was about to declare, bind, send some messages, start a subscriptionManager etc. I can try and pinpoint the client action that causes the crash if needed. Here is a stacktrace: SEG FAULT: (gdb) where #0 0x2ad3c74f6c88 in main_arena () from /lib64/tls/libc.so.6 #1 0x2ad3c671a9ed in qpid::framing::AMQFrame::decode ( this=0x7fffe489dc90, buff...@0x7fffe489de10) at intrusive_ptr.hpp:125 #2 0x2ad3c63f74dc in qpid::amqp_0_10::Connection::decode (this=0x538ec0, buffer=0x7fffe489de10 d, size=40) at memory:285 #3 0x2ad3c6743cc9 in qpid::sys::AsynchIOHandler::readbuff (this=0x538dd0, buff=0x530a00) at qpid/sys/AsynchIOHandler.cpp:103 #4 0x2ad3c64efc61 in boost::detail::function::function_obj_invoker2boost::_bi::bind_tbool, boost::_mfi::mf2bool, qpid::sys::AsynchIOHandler, qpid::sys::AsynchIO, qpid::sys::AsynchIOBufferBase*, boost::_bi::list3boost::_bi::valueqpid::sys::AsynchIOHandler*, boost::arg1 (*)(), boost::arg2 (*)() , bool, qpid::sys::AsynchIO, qpid::sys::AsynchIOBufferBase*::invoke ( function_obj_p...@0x57e890, a...@0x7fffe489de10, a1=0x530a00) at mem_fn_template.hpp:273 #5 0x2ad3c66e2467 in boost::function2bool, qpid::sys::AsynchIO, qpid::sys::AsynchIOBufferBase*, std::allocatorboost::function_base ::operator() ( this=0x57e890, a...@0x7fffe489de10, a1=0x28) at function_template.hpp:824 #6 0x2ad3c66e1671 in qpid::sys::posix::AsynchIO::readable (this=0x5391f0, h...@0x5391f8) at qpid/sys/posix/AsynchIO.cpp:446 #7 0x2ad3c66e492d in boost::detail::function::void_function_obj_invoker1boost::_bi::bind_tvoid, boost::_mfi::mf1void, qpid::sys::posix::AsynchIO, qpid::sys::DispatchHandle, boost::_bi::list2boost::_bi::valueqpid::sys::posix::AsynchIO*, boost::arg1 (*)() , void, qpid::sys::DispatchHandle::invoke ( ---Type return to continue, or q return to quit--- function_obj_p...@0x57e890, a...@0x7fffe489de10) at mem_fn_template.hpp:162 #8 0x2ad3c67485e7 in boost::function1void, qpid::sys::DispatchHandle, std::allocatorboost::function_base ::operator() (this=0x57e890, a...@0x7fffe489de10) at function_template.hpp:824 #9 0x2ad3c67479f5 in qpid::sys::DispatchHandle::processEvent ( this=0x5391f8, type=qpid::sys::Poller::READABLE) at qpid/sys/DispatchHandle.cpp:443 #10 0x2ad3c66f3b7c in qpid::sys::Poller::run (this=0x52c670) at Poller.h:122 #11 0x2ad3c63ff1fe in qpid::broker::Broker::run (this=0x) at qpid/broker/Broker.cpp:318 #12 0x0040bb5d in QpiddBroker::execute (this=0x57e890, options=0x525fc0) at intrusive_ptr.hpp:125 #13 0x00408ce1 in main (argc=1, argv=0x7fffe489ef58) at memory:301 Thanks, Adam On Wed, Mar 4, 2009 at 10:36 AM, Andrew Stitcher astitc...@redhat.com wrote: On Tue, 2009-03-03 at 21:43 -0500, Adam Chase wrote: Make check was flawless on 32 bit linux with g++ 4.3.2. Got errors on a 64 bit linux g++ 3.4.4. It crashes pretty regularly on this platform. Is this platform supported? You're going to have to be a little more specific than that! What are the platforms you are talking about? OS/Version valgrind version We test on 64 bit Linux (Red Hat 4/5, Fedora 9,10) all the time so these platforms should definitely work From a cursory look at your output I'd say it is what we'd expect from a platform we'd not tested before - we commonly see different valgrind complaints (many valid some not) when we use a platform we've not tested on before. BTW the it that is crashing is the unit test not the broker or client themselves. A crash in the unit_test like that will cause a lot of leak records because the program will be interrupted before cleaning up normally, so take the leaks with a grain of salt. The fact that the rest of the test fails to run makes me suspicious something funny is going on though with the make could ti be because you are using NFS for your build directory? Hope that helps/sheds some light. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1673) Dynamic Library Build on Windows (DLL)
[ https://issues.apache.org/jira/browse/QPID-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678797#action_12678797 ] shan wang commented on QPID-1673: - Aha...then is there anyway I can extract necessary headers myself? Is the include folder generated by Linux build the same as windows one? Dynamic Library Build on Windows (DLL) -- Key: QPID-1673 URL: https://issues.apache.org/jira/browse/QPID-1673 Project: Qpid Issue Type: New Feature Reporter: Danushka Menikkumbura Assignee: Steve Huston Attachments: create_dir_struct.bat, QPID-1673-examples-solution.patch, QPID-1673-examples-solution.v2.patch, QPID-1673-examples.patch, QPID-1673-INSTALL-WINDOWS.patch, QPID-1673-INSTALL-WINDOWS.v2, QPID-1673-qpid-solution.patch, QPID-1673-qpid-solution.v2.patch, QPID-1673-rubygen.patch, QPID-1673-rubygen.v2.patch, QPID-1673-src-qpid-amqp_0_10.patch, QPID-1673-src-qpid-amqp_0_10.v2.patch, QPID-1673-src-qpid-broker.patch, QPID-1673-src-qpid-client.patch, QPID-1673-src-qpid-client.v2.patch, QPID-1673-src-qpid-console.patch, QPID-1673-src-qpid-framing.patch, QPID-1673-src-qpid-framing.v2.patch, QPID-1673-src-qpid-log.patch, QPID-1673-src-qpid-log.v2.patch, QPID-1673-src-qpid-management.patch, QPID-1673-src-qpid-management.v2.patch, QPID-1673-src-qpid-sys.patch, QPID-1673-src-qpid-sys.v2.patch, QPID-1673-src-qpid.patch, QPID-1673-src-qpid.v2.patch, QPID-1673-src.patch, QPID-1673-src.v2.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1709) configure.ac: make output when no specs are present more friendly?
[ https://issues.apache.org/jira/browse/QPID-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston resolved QPID-1709. Resolution: Fixed Fixed; svn r750155. Will issue an error if there's no spec and no src/gen directory - good idea, Danushka. configure.ac: make output when no specs are present more friendly? -- Key: QPID-1709 URL: https://issues.apache.org/jira/browse/QPID-1709 Project: Qpid Issue Type: Improvement Components: Build Tools Affects Versions: M4 Environment: Linux Reporter: Steve Huston Priority: Trivial Fix For: M5 This came up on the users list... if a user with a released version of the C++ kit (say, M4) runs configure and it detects that there's no xml spec, all that shows in the output is the error from 'ls' saying there's no xml file. I think it may be better to inform the user of what's going on, with output such as: ... checking for rpmlint... no checking for ruby... ruby configure: AMQP specs not present; source code will not be generated. checking boost/shared_ptr.hpp usability... yes ... This is with the following patch to configure.ac: Index: configure.ac === --- configure.ac(revision 749505) +++ configure.ac(working copy) @@ -150,8 +150,9 @@ specdir=`pwd`/$srcdir/../specs AMQP_FINAL_XML=$specdir/amqp.0-10-qpid-errata.xml +test -f $AMQP_FINAL_XML || AC_MSG_NOTICE([AMQP specs not present; source code will not be generated.]) AC_SUBST(AMQP_FINAL_XML) -AM_CONDITIONAL([GENERATE], [ls $AMQP_FINAL_XML /dev/null]) +AM_CONDITIONAL([GENERATE], [test -f $AMQP_FINAL_XML]) # URL and download URL for the package. URL=http://rhm.et.redhat.com/qpidc What do you think about this in general, and about commiting it for M5? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1713) Error in FailoverExchangeRetry mechanism
Error in FailoverExchangeRetry mechanism Key: QPID-1713 URL: https://issues.apache.org/jira/browse/QPID-1713 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: M5 The FailoverExchangeMethod's retry mechanism is flawed as it was extending FailoverRoundRobinServers and there was a in the retry mechanism there QPID-1712 Also the retry mechanism for the failover exchange is actually different from FailoverRoundRobinServers therefore it is wrong to extend it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
JMX Version for QMan
Andrea, What version of JMX is required/supported by QMan? Thanks, -Ted - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: JMX Version for QMan
While I haven't tried Qman, afaik Andrea has simply targeted JDK5's built in JMX abilities, so that means JMX v1.2 JMX Remote 1.0 which are included in JDK5 and 6 with some additional functionality, or a compatible implementation. Any particular reason for asking?:) Robbie -Original Message- From: Ted Ross [mailto:tr...@redhat.com] Sent: 04 March 2009 22:28 To: dev@qpid.apache.org Subject: JMX Version for QMan Andrea, What version of JMX is required/supported by QMan? Thanks, -Ted - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: RFC (Was About socklen_t )
Hi Andrew, I've now fixed this issue (i think) by removing the use of socklen_t from the Socket class API completely. Ok. Manuel - confirm this fixes your issue. Steve - does this allow you to simplify the windows version of IntegerTypes.h? Yes, I removed the socklen_t typedef and aligned windows/Socket.cpp with your changes to Socket.h - the Windows build is good now. Thanks, -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: JMX Version for QMan
Hi Ted, Robbie's right. Regards Andrea On 3/5/09, Robbie Gemmell robbie.gemm...@gmail.com wrote: While I haven't tried Qman, afaik Andrea has simply targeted JDK5's built in JMX abilities, so that means JMX v1.2 JMX Remote 1.0 which are included in JDK5 and 6 with some additional functionality, or a compatible implementation. Any particular reason for asking?:) Robbie -Original Message- From: Ted Ross [mailto:tr...@redhat.com] Sent: 04 March 2009 22:28 To: dev@qpid.apache.org Subject: JMX Version for QMan Andrea, What version of JMX is required/supported by QMan? Thanks, -Ted - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Sent from my mobile device - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
