Re: Review Request: Keep better track of threads avoiding deadlocks at process rundown
On 2011-06-16 12:56:46, Alan Conway wrote: /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp, line 85 https://reviews.apache.org/r/904/diff/1/?file=21139#file21139line85 Why the pointer? Just declare std::mapunsigned, ThreadPrivate::shared_ptr pQpidThreads; and let std::map take care of the memory management. Andrew Stitcher wrote: I'd also add that we don't use the hungarian variable notation either so the 'p' should be stripped (possibly from other places too) OK... this was previously invisible because I missed the Publish step :-( The intended logic was that Thread::current() should have defined behavior, even if called from a static destructor. Otherwise, you need a way to guarantee the std:map destructor is never called too soon. The original JIRA's deadlock was in the context of a static destructor calling Thread::join(). On re-examiniation, the use of a non-POD lock mechanism is inconsistent with the stated goal. Thank-you for the heads up. I will work with Steve to address this and the naming problem. I have a fixed version I will upload to a separate review... coming soon. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/904/#review849 --- On 2011-06-15 01:08:18, Steve Huston wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/904/ --- (Updated 2011-06-15 01:08:18) Review request for qpid. Summary --- Keeps track of Qpid runnable threads and other threads, ensuring that rundown doesn't deadlock. This addresses bug QPID-3256. https://issues.apache.org/jira/browse/QPID-3256 Diffs - /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1132733 Diff: https://reviews.apache.org/r/904/diff Testing --- Qpid regression test suite. Thanks, Steve
Re: Review Request: Keeps track of Qpid runnable threads and other threads, ensuring that rundown doesn't deadlock.
On 2011-07-01 11:44:51, Steve Huston wrote: My concern with DllMain is that it precludes building qpid as static libraries (and having this logic still work). Good point. I was so focused on the bug as presented I lost complete sight of this valid use case. I suppose I could do away with locks and maps altogether with use of TLS storage. In this case the only leaked resource would be the TLS slot on multiple uses of LoadLibrary/FreeLibrary, which is obviously not relevant in the static build case. So I should be able to use logic to free the slot in DllMain and comment out that code in a static build. Does this seem reasonable? - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/#review947 --- On 2011-07-01 03:08:08, Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/ --- (Updated 2011-07-01 03:08:08) Review request for qpid. Summary --- This is the same logic as the preceding version with naming fixes and refinements to DLL cleanup. Cleanup now uses Windows DllMain function to allows cleanup after C++ runtime static destructors. This addresses bug qpid-3256. https://issues.apache.org/jira/browse/qpid-3256 Diffs - /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1141687 Diff: https://reviews.apache.org/r/987/diff Testing --- Qpid cmake run_tests Thanks, Cliff
Re: Review Request: Keeps track of Qpid runnable threads and other threads, ensuring that rundown doesn't deadlock.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/ --- (Updated 2011-07-05 17:54:17.154114) Review request for qpid. Changes --- Now uses Thread local storage (TLS) instead of a std::map to locate the ThreadPrivate structure. DllMain baggage still there to manage the FreeLibrary case. Summary --- This is the same logic as the preceding version with naming fixes and refinements to DLL cleanup. Cleanup now uses Windows DllMain function to allows cleanup after C++ runtime static destructors. This addresses bug qpid-3256. https://issues.apache.org/jira/browse/qpid-3256 Diffs (updated) - /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1143151 Diff: https://reviews.apache.org/r/987/diff Testing --- Qpid cmake run_tests Thanks, Cliff
Re: 0.12 release update - release branch created, beta available
Also related to QPID-2905 problems is QPID-3338. I am trying to do a test mingw build on Linux to test the patch (all new to me). It works in the case of Windows CMake and the Visual Studio toolchain. Cliff On Tue, Jul 12, 2011 at 7:45 AM, Justin Ross jr...@redhat.com wrote: Chuck, would you create a new jira for this? I looked at using QPID-2905, but it's a little overloaded. Once we have a dedicated jira, I'll get it approved and we can merge the fix over. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.12 release update - release branch created, beta available
I have tested the patch for QPID-3338 against qpid-0.12-beta on Linux and it appears to do the right thing for mingw and cmake. I would like to request approval for this patch. cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.12 release update - RC1 is out
The WCF client builds and runs fine also. This also required building and using C++ broker and client components too (on Windows). Cliff On Thu, Jul 14, 2011 at 12:11 PM, Justin Ross jr...@redhat.com wrote: Greetings, everyone. Today I produced RC1 from revision 1146605: http://people.apache.org/~jross/qpid-0.12-rc1/ Thanks to everyone who has tested and prodded. RC2 is due this time next week, and the final RC is planned for the end of this month. See all the details at the release page. Justin --- 0.12 release page: https://cwiki.apache.org/confluence/display/qpid/0.12+Release - 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: Review Request: QPID-2643 Building QPID with Visual Studio 2010
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1291/#review1296 --- Ship it! - Cliff On 2011-08-04 17:17:32, Chug Rolke wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1291/ --- (Updated 2011-08-04 17:17:32) Review request for qpid, Gordon Sim, Steve Huston, Andrew Stitcher, and Cliff Jansen. Summary --- QPID-2643 Building QPID with Visual Studio 2010 This patch changes: List.h - add a typedef from the original post IntegerTypes.h - adds 'signed' to int_8 to avoid MSVC complaint SessionState.cpp, qpid-perftest.cpp - adds explicit boost:: to disambiguate methods recently defined by 'using std'. CMakeLists.txt - Adds a CMake option that allows user to include '#define _WIN32_WINNT=0x0502' or not. Linux users see no change. This replaces CMake code that includes a similar definition when the build system _has VS2005 installed_. Even if the Generator is VS2010 the def was added because VS2005 is installed. This in not right. Without this definition several components define _WIN32_WINNT=0x0501 to target network and system api components. Those components will still work correctly with 0x0502. Defining _WIN32_WINNT=0x0501 across the board causes a build error in cpp\qpid\store that 0x0502 avoids. This patch will move the minimum required version of Windows from WinXP to WinXP-SP3. Diffs - /trunk/qpid/cpp/include/qpid/framing/List.h 1153911 /trunk/qpid/cpp/include/qpid/sys/windows/IntegerTypes.h 1153911 /trunk/qpid/cpp/src/CMakeLists.txt 1153911 /trunk/qpid/cpp/src/tests/SessionState.cpp 1153911 /trunk/qpid/cpp/src/tests/qpid-perftest.cpp 1153911 Diff: https://reviews.apache.org/r/1291/diff Testing --- Thanks, Chug
Re: [VOTE] Release 0.12
On Tue, Aug 9, 2011 at 12:35 PM, Justin Ross jr...@redhat.com wrote: Howdy, all. The last-minute blocker, QPID-3394, has been fixed, and there are no open blocker jiras against 0.12. The proposed final RC, from revision 1154981 of the 0.12 release branch, is available here: http://people.apache.org/~jross/qpid-0.12/ If you favor releasing this distribution as Qpid 0.12, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. If the release proceeds, I'll take the final steps to publicize and distribute the release. That should take one or two days. --- 0.12 release page: https://cwiki.apache.org/qpid/012-release.html - +1 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Welcome Keith as committer
Welcome Keith! On Thu, Aug 18, 2011 at 6:23 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Aug 17, 2011 at 01:22:29PM -0400, Carl Trieloff wrote: Keith has been nominated and voted onto Qpid as a committer and has accepted. Please welcome him Congrats. :) -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Remove autotools? [Was: Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found]
+1 An additional sub-task would be to rework the separate powershell and sh scripts within cmake/ctest to a single base (python is a likely candidate), so that contributers don't need to wear multiple hats. On Fri, Nov 11, 2011 at 7:53 AM, Andrew Stitcher astitc...@redhat.com wrote: On Fri, 2011-11-11 at 15:24 +, Robbie Gemmell wrote: This kind of thing seems like a good reason to add a CMake build project to Jenkins (or, you know, just have 1 build system :p) in addition to the autotools build Keith set up. Any takers? Personally I go for the 1 build system - Cmake. At present Cmake is very nearly at parity with autotools (given the recent work I checked in from Jan-Marek Glogowski) and I'd say it would be feasible (given the available time) to remove autotools and shift to cmake in the 0.16 time frame. I think the only remaining work is to make the tests on cmake be at parity with autotools. [There's also tidying work we should do, because neither of the build systems is very pretty or very maintainable at this point, but having just one would help a lot] Andrew - 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
Fwd: C++ broker compilation on Sparc Solaris 10
Oops, missed the dev list... Martin: please see QPID-3620 and QPID-3621 for comparison to the work you have done separately, and provide comments as to anything you think is missing or should be done differently. I will review board these as well later on Wednesday. Cliff -- Forwarded message -- From: Cliff Jansen cliffjan...@gmail.com Date: 2011/11/15 Subject: Re: C++ broker compilation on Sparc Solaris 10 To: MartiN Beneš martinben...@gmail.com Hi Martin, Your timing is excellent. I have been active at my end, mainly running the client code. I will post my changes later today and get the appropriate bits up on review board. Once it has had a few more community eyes on it, I will move it into 0.16 development trunk. I expect at least two new Jiras. From those, or new ones if needed, we should be able to coordinate any ongoing testing and fixes. Thanks for your feedback. Cliff 2011/11/15 MartiN Beneš martinben...@gmail.com: Hi, recently i managed to send millions of messages using this poller with no crashes at all, so to me the patch seems to be correct. I would like to get the trunk to the state, where it is possible to compile it on solaris with no changes. I'm new to qpid, so i ask: would you suggest creating new Jira with patches to the build system (some compiler and linker flags were necessary for me to build with gcc 4.6) + those few casts, and wait for your poller till it gets into the trunk? On Wed, Nov 2, 2011 at 09:18, Cliff Jansen cliffjan...@gmail.com wrote: Please see https://issues.apache.org/jira/browse/QPID-3571 I can sometimes send a million messages between qpid-perftest and qpidd, but usually I get random core dumps. Debugging looks sufficiently strange that I am not confident my base build is sensible. I am looking at my compile and link directives primarily. I believe all changes used for the build are in trunk, but not necessarily in 0.14. These changes are just a handful of casts or other syntax changes to unruffle the compiler when processing templates or boost-isms. 2011/11/1 MartiN Beneš martinben...@gmail.com: I am trying to compile qpid c++ broker and client libraries on Solaris 10. The easiest way seems to be using g++ and cmake. I was able to compile everything with just mild touches to the build system, however the Solaris implementation of Poller, the ECFPoller.cpp, seems to be broken and fails to link for the lack of Poller::monitorHandle(), Poller::unmonitorHandle() and couple more methods. Is there another way to compile qpid on Solaris, perhaps some fallback version of Poller based on select(), or do I need to fix the ECFPoller.cpp to get it working? thx, Martin - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0.14 release update - RC1 is available
False alarm. My apologies to all. This TR1 feature was added after VS 2008 shipped, and I am missing the later feature pack from Microsoft on my usual test box. Cliff On Mon, Nov 21, 2011 at 4:24 PM, Cliff Jansen cliffjan...@gmail.com wrote: The Windows build fails tripping over qpid/sys/unordered_map.h. I'm pretty sure this is just a simple cmake/autotools thing. I will create a patch and Jira in a little while. Cliff On Mon, Nov 21, 2011 at 2:44 PM, Justin Ross jr...@redhat.com wrote: Hi. I've completed by smoke testing with no unwanted surprises. C++ autotools build okay C++ autotools test okay C++ autotools install okay C++ cmake build okay Java ant build okay Java ant test okay Python build okay Python test okay Python install okay Tools build okay Tools install okay Qmf build okay Qmf install okay I ran all my tests using Fedora 15 x86_64, GCC 4.6.1, Java 1.6.0_22, and Python 2.7.1. Justin On Mon, 21 Nov 2011, Justin Ross wrote: Greetings, everyone. I've produced our first release candidate at revision 1203721: http://people.apache.org/~jross/qpid-0.14-rc1/ I haven't completed my normal smoke testing, so I'll follow up later with my results. Try it out! Thanks, Justin --- 0.14 release page: https://cwiki.apache.org/qpid/014-release.html - 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 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Review Request: QPID-3193 .NET Binding - handling disposed objects
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3239/#review4020 --- Ship it! Nice work. - Cliff On 2011-12-19 22:00:08, Chug Rolke wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3239/ --- (Updated 2011-12-19 22:00:08) Review request for qpid, Andrew Stitcher, Gordon Sim, Ted Ross, Steve Huston, and Cliff Jansen. Summary --- QPID-3193 .NET Binding - proper handling of disposed objects. This addresses bug QPID-3193. https://issues.apache.org/jira/browse/QPID-3193 Diffs - trunk/qpid/cpp/bindings/qpid/dotnet/src/BindingCommon.h PRE-CREATION trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.h 1215245 trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.cpp 1215245 trunk/qpid/cpp/bindings/qpid/dotnet/src/msvc10/org.apache.qpid.messaging.vcxproj 1215245 trunk/qpid/cpp/bindings/qpid/dotnet/src/msvc9/org.apache.qpid.messaging.vcproj 1215245 Diff: https://reviews.apache.org/r/3239/diff Testing --- Thanks, Chug
Re: Review Request: QPID-3571 Portable Poller implememtation for Posix systems
On 2012-01-05 00:41:30, Steve Huston wrote: Nit... there are a few trailing spaces, noted by red in the review diff. There's a qpid/sys/PipeHandle.h that you may be able to use in the SignalPipe class, though there may not be too much benefit to that. In EventStream::next, does the wait on serializer decrease the timeout? If not, the wait may end up longer than the caller requested. Other than that, it's good! Steve, thanks very much for your time reviewing this code... several times! I will fix the spaces :-) The timeout (qpid::sys::Duration) is converted to an absolute time (targetTimeout) prior to entering the loop. The targetTimeout does not need further adjusting from within the loop. The pre-existing PipeHandle class exposes read and write calls on the pipe whereas the poller's SignalPipe hides them (in order to minimize them). The remaining overlap between them is very small, so I don't think there is much to be gained by trying to re-jig either one. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3386/#review4192 --- On 2012-01-04 20:12:57, Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3386/ --- (Updated 2012-01-04 20:12:57) Review request for qpid, Andrew Stitcher, Ted Ross, and Steve Huston. Summary --- Portable qpid::sys::Poller implementation for Posix systems. Modelled as closely as possible to the EpollPoller implementation. This addresses bug QPID-3571. https://issues.apache.org/jira/browse/QPID-3571 Diffs - /svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/posix/PosixPoller.cpp PRE-CREATION Diff: https://reviews.apache.org/r/3386/diff Testing --- linux solaris (x86, sparc, gcc, native sunstudio compilers) Thanks, Cliff
Review Request: Heartbeat timeout in Windows does not lead to timely reconnect
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4383/ --- Review request for qpid, Andrew Stitcher, Ted Ross, Chug Rolke, and Steve Huston. Summary --- The cause of the hang was an outstanding read side completion when the AsynchIO object in charge of the socket was in the queuedClose state. The completion handler drains outstanding async requests before closing the socket. Since the cable had been pulled, the async read would never complete until Windows gave up on the socket altogether (some time much later). This patch remembers the last aio read and will cancel it if in the queuedClose state before blocking again. Aside from the basic description from the Jira, I also removed an unused test for restartRead, which doesn't change the logic of the section, but may indicate an intention that wasn't fully coded or something left over from a previous change. This addresses bug QPID-3759. https://issues.apache.org/jira/browse/QPID-3759 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1301636 Diff: https://reviews.apache.org/r/4383/diff Testing --- qpid-perftest, qpid-send, qpid-receive, cable pulls, broker pause/resumes Thanks, Cliff
Re: Review Request: Heartbeat timeout in Windows does not lead to timely reconnect
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4383/ --- (Updated 2012-03-26 18:26:34.827957) Review request for qpid, Andrew Stitcher, Ted Ross, Chug Rolke, and Steve Huston. Changes --- This patch follows the same logic of the previous while avoiding CancelIoEx. CancelIo as a substitution for CancelIoEx was considered but has thread restrictions that would have required a major rewrite of the base code. I have substituted a much blunter instrument to achieve the completion, namely a full closesocket to unstick the read. It forces all pending overlapped operations to completions, which is the last read in our case. Summary --- The cause of the hang was an outstanding read side completion when the AsynchIO object in charge of the socket was in the queuedClose state. The completion handler drains outstanding async requests before closing the socket. Since the cable had been pulled, the async read would never complete until Windows gave up on the socket altogether (some time much later). This patch remembers the last aio read and will cancel it if in the queuedClose state before blocking again. Aside from the basic description from the Jira, I also removed an unused test for restartRead, which doesn't change the logic of the section, but may indicate an intention that wasn't fully coded or something left over from a previous change. This addresses bug QPID-3759. https://issues.apache.org/jira/browse/QPID-3759 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1301636 Diff: https://reviews.apache.org/r/4383/diff Testing --- qpid-perftest, qpid-send, qpid-receive, cable pulls, broker pause/resumes Thanks, Cliff
Re: Review Request: Heartbeat timeout in Windows does not lead to timely reconnect
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4383/ --- (Updated 2012-04-11 02:57:20.281375) Review request for qpid, Andrew Stitcher, Ted Ross, Chug Rolke, and Steve Huston. Changes --- The cancelled read usually results in an aborted status, but depending on how far the socketclose has progressed at the time the completion is posted, you can get a number of other statuses such as connection reset and several others. This results in a spurious notifyDisconnect() and general mayhem from the deleted Socket. Since closesocket() is a relatively long operation and the cancel operation occurred outside the completionQueue loop, the dislodged read completion could be processed in a separate thread resulting in a concurrent Socket::close() which, on occasion, yielded an exception. This was fixed by moving the cancel inside the completionQueue loop so that the resulting completion would be serialized after the cancel. So round three involves: 1. just using queuedClose to indicate a drained read 2. moving the socket.close() to serialize the read completion 3. adding a queuedDelete check before using a non-existent socket Presumably #2 would never have occurred with CancelIoEx. But it is probable that #1 would have been lurking, just occurring very rarely (depending on whether the other side closed its connection at just the right/wrong time). #3 can be attributed solely to my paranoia. Summary --- The cause of the hang was an outstanding read side completion when the AsynchIO object in charge of the socket was in the queuedClose state. The completion handler drains outstanding async requests before closing the socket. Since the cable had been pulled, the async read would never complete until Windows gave up on the socket altogether (some time much later). This patch remembers the last aio read and will cancel it if in the queuedClose state before blocking again. Aside from the basic description from the Jira, I also removed an unused test for restartRead, which doesn't change the logic of the section, but may indicate an intention that wasn't fully coded or something left over from a previous change. This addresses bug QPID-3759. https://issues.apache.org/jira/browse/QPID-3759 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1301636 Diff: https://reviews.apache.org/r/4383/diff Testing --- qpid-perftest, qpid-send, qpid-receive, cable pulls, broker pause/resumes Thanks, Cliff
Re: Review Request: Heartbeat timeout in Windows does not lead to timely reconnect
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4383/ --- (Updated 2012-04-19 06:52:43.361572) Review request for qpid, Andrew Stitcher, Ted Ross, Chug Rolke, and Steve Huston. Changes --- Load tests over a period of time reveal a threading bug when closing a connection. The testing for opsInprogress == 0 and the states of queuedDelete and queuedClose occurs outside the lock. If an IO thread suspends right after releasing the lock (opsInProgress == 1) and resumes some time later, when another IO thread has decremented opsInProgress to zero, both threads will conclude that they are the last IO completion. This results variously in double deletes of the underlying socket or the AsynchIO object itself. This patch moves the test inside the lock. It also uses the same lock to protect the setting of either queuedDelete or queuedClose and the handoff (if any) to the IO thread. This has the effect of adding two additional locks over the life of the connection, but should have no effect on throughput or latency. Summary --- The cause of the hang was an outstanding read side completion when the AsynchIO object in charge of the socket was in the queuedClose state. The completion handler drains outstanding async requests before closing the socket. Since the cable had been pulled, the async read would never complete until Windows gave up on the socket altogether (some time much later). This patch remembers the last aio read and will cancel it if in the queuedClose state before blocking again. Aside from the basic description from the Jira, I also removed an unused test for restartRead, which doesn't change the logic of the section, but may indicate an intention that wasn't fully coded or something left over from a previous change. This addresses bug QPID-3759. https://issues.apache.org/jira/browse/QPID-3759 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1327776 Diff: https://reviews.apache.org/r/4383/diff Testing --- qpid-perftest, qpid-send, qpid-receive, cable pulls, broker pause/resumes Thanks, Cliff
Re: [VOTE] Release 0.16
+1 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: SSL Connection under Windows [Was: Qpid Enquiry]
Andrew: Note that there are pending changes to client side SSL on Windows in QPID-3914. I haven't examined it, but it seems related to some of the expanded functionality you are looking for. Cliff On Mon, May 21, 2012 at 12:40 PM, Steve Huston shus...@riverace.com wrote: -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Monday, May 21, 2012 3:20 PM To: dev@qpid.apache.org Subject: RE: SSL Connection under Windows [Was: Qpid Enquiry] On Mon, 2012-05-21 at 14:08 -0500, Steve Huston wrote: Hi Andrew, I wrote the code originally, so I'll chime in. As for the why questions, they may have been misinformed, bad decisions. I was most likely thinking broker instead of client, which is why I chose to open the store for local machine, not current user. It was also before running the broker as a service was really worked on seriously. I may have misunderstood advice on MSDN re that arg and the store path. I might have just gotten it wrong. A point of clarification - I'm haven't considered the client side at all in any of this, I've only been working to get a broker up with ssl. I've actually been connecting to it from linux. In fact if I read the code correctly the client side doesn't open the certificate store at all (at least explicitly). Ok. I didn't really emphasise this, but I think that using LocalMachine store is probably more insecure than necessary in that it allows anyone with access to the machine access to the certificate to impersonate the broker. So I'd like to change the default, however that wouldn't be backward compatible - would that be an issue do you think? If you're closing a security hole, I'd say to change it as long as the release notes mention the change. -Steve - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Proton JIRA project
[X] Yes, create a JIRA project for Proton. [ ] No, bah, humbug, Proton can suck it. Cliff - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Proton mailing list
[ X] Yes, create pro...@qpid.apache.org [ ] No, people who don't follow dev@qpid.apache.org shouldn't get a say. Cliff On Wed, Jul 25, 2012 at 12:05 PM, Rafael Schloming rafa...@redhat.com wrote: Hi Everyone, There's been a lot of good discussion about proton on the dev list, however, despite my encouragement, many interested parties do not follow the qpid dev list and instead email me directly as a matter of convenience. It's my belief that a proton mailing list would help encourage these parties to participate more openly and foster better communication between all the various users of proton both inside and outside of qpid. To that end I'd like to propose creating pro...@qpid.apache.org. [ ] Yes, create pro...@qpid.apache.org [ ] No, people who don't follow dev@qpid.apache.org shouldn't get a say. --Rafael - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: patches for mingw
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake -G MinGW Makefiles -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe c:\cj\work\amqp\proton\mingw4\trunk\proton-c mingw32-make python ..\..\tests\proton-test This addresses bug QPID-4181. https://issues.apache.org/jira/browse/QPID-4181 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/CMakeLists.txt 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/framing/framing.c 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/message/message.c 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/network.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/posix/time.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/uuid.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/driver.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/time.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/uuid.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1368240 http://svn.apache.org/repos/asf/qpid/proton/trunk/tests/proton_tests/messenger.py 1368240 Diff: https://reviews.apache.org/r/6302/diff/ Testing --- Fedora, Windows Thanks, Cliff Jansen
Re: Review Request: patches for mingw
On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt, line 39 https://reviews.apache.org/r/6302/diff/1/?file=132723#file132723line39 Perhaps it makes sense to move src/driver.c into src/sys/posix/driver.c? I meant to state in the notes that I would do so in a separate patch, depending on whether there was an alternate suggestion to managing the platform specific code. On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h, line 40 https://reviews.apache.org/r/6302/diff/1/?file=132727#file132727line40 I think it might be better to keep pn_socket_t out of a header file that will be widely included by arbitrary client code if it is going to include a windows system header file (with their name space polluting ways and general large size). Perhaps pn_socket_t is defined with the driver API? The latter is the problem. pn_listen_fd() allows the application to pass in a socket to use. I am not sure there is a way to avoid pollution and gain access to the Winsock SOCKET definition. Thoughts? On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/uuid.h, line 29 https://reviews.apache.org/r/6302/diff/1/?file=132736#file132736line29 It seems likely to me that you don't need to #include windows.h in this header file - just including it in the actual implementation file would stop it contaminating everything with windows symbols. I can do that. On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c, line 27 https://reviews.apache.org/r/6302/diff/1/?file=132740#file132740line27 Note that strings.h is a purely Unix thing not in the C standard library. So the there should be a test like #ifdef __unix__ around it, something like: #ifdef __unix__ # include strings.h #elif defined(_WIN32) # define strcasecmp(a,b) _stricmp((a), (b)) #else # error #endif Although it might be simply better to avoid these not very standard calls and use tolower() and strcmp(). In fact since I can see you've done that work lower down these lines can probably be removed completely. Oops. This is cruft left behind when I switched to the plan B you noted. Will do. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/#review9728 --- On Aug. 1, 2012, 9:23 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- (Updated Aug. 1, 2012, 9:23 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake
Re: Review Request: patches for mingw
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- (Updated Aug. 6, 2012, 8:16 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Changes --- pn_socket_t moved to driver.h; pn_connector_fd references fixed. uuid.h: windows.h removed. util.c: unneeded strings.h and _stricmp removed. proton-dump.c: perror replaced with custom fatal_error() function. windows.h or winsock2.h were pulled in to just the source files needing them. The posix driver.c move to the sys/posix directory will be done separately. Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake -G MinGW Makefiles -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe c:\cj\work\amqp\proton\mingw4\trunk\proton-c mingw32-make python ..\..\tests\proton-test This addresses bug QPID-4181. https://issues.apache.org/jira/browse/QPID-4181 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/CMakeLists.txt 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/php/php.i 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/driver.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/framing/framing.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/message/message.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/network.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/posix/time.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/uuid.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/driver.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/time.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/uuid.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/tests/proton_tests/messenger.py 1369190 Diff: https://reviews.apache.org/r/6302/diff/ Testing --- Fedora, Windows Thanks, Cliff Jansen
Re: Review Request: patches for mingw
On Aug. 7, 2012, 1:37 p.m., Kenneth Giusti wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h, line 192 https://reviews.apache.org/r/6302/diff/1-2/?file=132726#file132726line192 Minor artistic flourish - how about we change this api to substitute socket for fd? I think that makes it's intent clearer. E.g: pn_connector_socket( pn_driver_t *driver, pn_socket_t sock, void *context) Just wonderin' Rafael Schloming wrote: Sorry if I'm missing some context here, still catching up on the details, but wouldn't that simply shift the inaccuracy from windows to unix, i.e. it would be called _socket_, but fd's would also work? Or are you suggesting a separate API for windows and it would remain the same on unix? Kenneth Giusti wrote: I'm not recommending separate windows/unix api, but the type pn_socket_t seems likely to imply the intent of that parameter, no? And to a windows programmer, a file descriptor (fd) wouldn't be the correct argument. Would it be more appropriate to typedef the parameter as pn_network_handle_t, or a more generic pn_io_handle_t? Rafael Schloming wrote: I think my question was more whether we're trying to shoehorn two concepts into one by having one type that is both the generic notion of fd on unix, but is restricted to a socket on windows. It seems like we have the following options: (1) restrict the unix usage to socket only (in which case the naming you suggest is appropriate) (2) allow generic fds on unix and sockets only on windows and be vague/fuzzy about the naming (3) split this portion of API according to platform, e.g. have a windows include and a unix include (4) introduce a more sophisticated facade layer akin to OpenSSL's BIOs that could represent both socket and non socket sources of I/O on any platform We also have the option to omit this portion of the API for now as I don't think it's currently used, and defer the decision till later. Is the API intended to work on non-sockets, such as pipes? In that case a Windows HANDLE would be the common denominator. Windows SOCKETs are essentially OS HANDLEs from our perspective. The overlapped I/O implementation in the C++ code should be compatible with this usage. I would second pn_io_handle_t. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/#review9957 --- On Aug. 6, 2012, 8:16 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- (Updated Aug. 6, 2012, 8:16 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake -G MinGW Makefiles -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe c:\cj\work\amqp\proton\mingw4\trunk\proton-c
Re: Review Request: patches for mingw
On Aug. 7, 2012, 3:58 p.m., Andrew Stitcher wrote: I think this is pretty much what I was thinking. I don't really like the actual client file doing the #include winsock2 but in the circumstances it's better than the previous alternative. Another possibility is to move the pn_connector_fd()/pn_listener_fd() APIs to their own file say driver_extras.h as currently these APIs aren't actually used by anything as far as anyone can tell me. Rafael Schloming wrote: I like the idea of splitting them out into a separate .h file, although we could do that in a separate patch if it's more convenient. I am happy to rework the patch this way. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/#review9964 --- On Aug. 6, 2012, 8:16 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- (Updated Aug. 6, 2012, 8:16 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake -G MinGW Makefiles -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe c:\cj\work\amqp\proton\mingw4\trunk\proton-c mingw32-make python ..\..\tests\proton-test This addresses bug QPID-4181. https://issues.apache.org/jira/browse/QPID-4181 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/CMakeLists.txt 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/php/php.i 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/driver.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/framing/framing.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/message/message.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/network.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/posix/time.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/uuid.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows
Re: Review Request: patches for mingw
On Aug. 10, 2012, 3:10 p.m., Rafael Schloming wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c, line 327 https://reviews.apache.org/r/6302/diff/2/?file=134512#file134512line327 Is there a way to do the equivalent of 0.0.0.0 on windows? This is intended to allow remote incoming connections, so the 127.0.0.1 default isn't an ideal choice here. We should at least make the default platform dependent if we have no better option at the moment. Windows is OK with 0.0.0.0 for listening, but returns an error when connecting (complaining that it is a meaningless destination). I believe that Linux converts it to the loopback, or it defaults to the loopback for the majority of routing tables. I think I left all listening addresses as they were and only changed the outbound connections. On Aug. 10, 2012, 3:10 p.m., Rafael Schloming wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c, line 24 https://reviews.apache.org/r/6302/diff/2/?file=134514#file134514line24 What's the #include winsock2.h for? Offhand I can't spot what part of the code would need that. It is needed for gethostname(), perhaps others. On Aug. 10, 2012, 3:10 p.m., Rafael Schloming wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/driver.c, line 1 https://reviews.apache.org/r/6302/diff/2/?file=134518#file134518line1 Is this just a wholesale copy + mod of src/driver.c? Essentially yes. It came from Ken's branch which had select() substituted for poll. I first tried WSAPoll() but mingw kicked up a fuss. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/#review10122 --- On Aug. 6, 2012, 8:16 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- (Updated Aug. 6, 2012, 8:16 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake -G MinGW Makefiles -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe c:\cj\work\amqp\proton\mingw4\trunk\proton-c mingw32-make python ..\..\tests\proton-test This addresses bug QPID-4181. https://issues.apache.org/jira/browse/QPID-4181 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/CMakeLists.txt 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/php/php.i 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h 1369190 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1369190 http://svn.apache.org/repos/asf/qpid
Re: [VOTE] Release 0.18
+1 On Mon, Aug 27, 2012 at 8:22 AM, Justin Ross jr...@redhat.com wrote: I had planned to close the vote last week, but so far I've receieved only four votes. Anyone else care to cast his or her ballot? Justin On Mon, 20 Aug 2012, Justin Ross wrote: Hi, folks. It's time again to vote on our release. The proposed final RC (same revision as RC3, minus the -rc3 version suffix) is available here: http://people.apache.org/~jross/qpid-0.18/ If you favor releasing the RC3 bits as 0.18, vote +1. If you have a reason to think that RC3 is not ready for frelease, vote -1. I'll close the vote on Friday. Thank you, Alex, Gordon, and Darryl, for testing the RC3 bits and posting what you found. And thanks again to Robbie for picking up release tasks when I could not. Thanks! Justin --- 0.18 release page: https://cwiki.apache.org/qpid/018-release.html - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: qpid-4330 windows client hang/fault
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7179/ --- Review request for qpid, Andrew Stitcher, Chug Rolke, and Steve Huston. Description --- This patch introduces a primitive qpid::sys::SystemInfo::threadSafeShutdown(). It always returns true on Linux and Solaris. On Windows, it returns true for FreeLibrary and false if exit() has been called, main() returns, or the Qpid libraries have been statically linked. It is used to fix the noted static destructor problems in the main Jira. Most of the work is plumbing related to obtain knowledge of how the module is terminated in time to be useful to the consumer of the threadSafeShutdown call. This addresses bug qpid-4330. https://issues.apache.org/jira/browse/qpid-4330 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/include/qpid/sys/SystemInfo.h 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/CMakeLists.txt 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/Makefile.am 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/ConnectionImpl.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/ClientDllMain.cpp PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/posix/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/solaris/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/QpidDllMain.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Socket.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1387463 Diff: https://reviews.apache.org/r/7179/diff/ Testing --- Thanks, Cliff Jansen
Re: Review Request: qpid-4330 windows client hang/fault
On Sept. 19, 2012, 8:42 p.m., Andrew Stitcher wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/QpidDllMain.h, line 48 https://reviews.apache.org/r/7179/diff/1/?file=158587#file158587line48 Shouldn't this be defined in the .cpp file? If the functionality is needed in future in qpidmessaging or qpidbroker, then the code can be pulled in to an analogous MessagingDllMain.cpp or BrokerDllMain.cpp without duplicating the code (which is already sadly duplicated in Thread.cpp). On Sept. 19, 2012, 8:42 p.m., Andrew Stitcher wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/QpidDllMain.h, line 59 https://reviews.apache.org/r/7179/diff/1/?file=158587#file158587line59 Currently all exits return TRUE so this line is superfluous. True, but that is the sole dangerous code path of the four. My paranoia tells me to leave it as is so that someone has to take an extra step to fall through to some shared code in the future (and add some descriptive warning comment just before the return. Granted, people regularly put all sorts of code in their DllMain routines. It can be done, but its easy to get wrong. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7179/#review11717 --- On Sept. 19, 2012, 8:32 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7179/ --- (Updated Sept. 19, 2012, 8:32 p.m.) Review request for qpid, Andrew Stitcher, Chug Rolke, and Steve Huston. Description --- This patch introduces a primitive qpid::sys::SystemInfo::threadSafeShutdown(). It always returns true on Linux and Solaris. On Windows, it returns true for FreeLibrary and false if exit() has been called, main() returns, or the Qpid libraries have been statically linked. It is used to fix the noted static destructor problems in the main Jira. Most of the work is plumbing related to obtain knowledge of how the module is terminated in time to be useful to the consumer of the threadSafeShutdown call. This addresses bug qpid-4330. https://issues.apache.org/jira/browse/qpid-4330 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/include/qpid/sys/SystemInfo.h 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/CMakeLists.txt 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/Makefile.am 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/ConnectionImpl.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/ClientDllMain.cpp PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/posix/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/solaris/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/QpidDllMain.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Socket.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1387463 Diff: https://reviews.apache.org/r/7179/diff/ Testing --- Thanks, Cliff Jansen
Re: Review Request: qpid-4330 windows client hang/fault
On Sept. 21, 2012, 7:22 p.m., Chug Rolke wrote: I ran this patch with extra OutputDebugString calls when the new logic checks threadSafeShutdown. In a typical client program like drain threadSafeShutdown is false every time as expected for IOThreads and for WinSockSetup. On the windows broker only ~WinSockSetup checks the threadSafeShutdown. Should the broker threads check for safe shutdown too? No. The broker code creates and destroys these resources in the context of main(), before main() returns or exit(). threadSafeShutdown() only returns meaningful info if called after the C++ runtime has started its housecleaning for the DLL. In practice that means if called from an atexit() routine (not used in Qpid), or from a static destructor. Unlike the broker, the client library uses a static destructor (static IOThread io...) to know when to clean up. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7179/#review11796 --- On Sept. 19, 2012, 8:32 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7179/ --- (Updated Sept. 19, 2012, 8:32 p.m.) Review request for qpid, Andrew Stitcher, Chug Rolke, and Steve Huston. Description --- This patch introduces a primitive qpid::sys::SystemInfo::threadSafeShutdown(). It always returns true on Linux and Solaris. On Windows, it returns true for FreeLibrary and false if exit() has been called, main() returns, or the Qpid libraries have been statically linked. It is used to fix the noted static destructor problems in the main Jira. Most of the work is plumbing related to obtain knowledge of how the module is terminated in time to be useful to the consumer of the threadSafeShutdown call. This addresses bug qpid-4330. https://issues.apache.org/jira/browse/qpid-4330 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/include/qpid/sys/SystemInfo.h 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/CMakeLists.txt 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/Makefile.am 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/ConnectionImpl.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/ClientDllMain.cpp PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/posix/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/solaris/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/QpidDllMain.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Socket.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SystemInfo.cpp 1387463 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1387463 Diff: https://reviews.apache.org/r/7179/diff/ Testing --- Thanks, Cliff Jansen
Re: Review Request: Fix for Thread object's operator bool()
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8072/#review13485 --- I am going to disagree (with the proposed patch, and agree with Andrew). I managed to reproduce (took closer to 15 minutes on my laptop) and get a similar stack trace. I see a shared_ptr with non-null value and use_count of 3. impl-get() would also return true and trigger the assert. On a separate thread, I see the same PollableQueue instance in dispatch()/process(), waiting to reacquire the lock after line 152. I think the explanation is more likely that differences in the poller implementations expose a different scheduling opportunity for the bug on Windows compared to Linux. - Cliff Jansen On Nov. 15, 2012, 3:05 a.m., Steve Huston wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8072/ --- (Updated Nov. 15, 2012, 3:05 a.m.) Review request for qpid, Andrew Stitcher, Chug Rolke, and Cliff Jansen. Description --- The assert in QPID-4424 was a check for a Thread object not set. This change resolves that problem, but could it really be that easy? Why doesn't the Linux code fail the same way? This addresses bug QPID-4424. https://issues.apache.org/jira/browse/QPID-4424 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1409628 Diff: https://reviews.apache.org/r/8072/diff/ Testing --- Original reproducing test case in QPID-4424 (run broker quiet for 15 seconds). I set a breakpoint at the assert and stepped across it without error. Thanks, Steve Huston
Re: Review Request: Fix for Thread object's operator bool()
On Nov. 15, 2012, 9:17 p.m., Cliff Jansen wrote: I am going to disagree (with the proposed patch, and agree with Andrew). I managed to reproduce (took closer to 15 minutes on my laptop) and get a similar stack trace. I see a shared_ptr with non-null value and use_count of 3. impl-get() would also return true and trigger the assert. On a separate thread, I see the same PollableQueue instance in dispatch()/process(), waiting to reacquire the lock after line 152. I think the explanation is more likely that differences in the poller implementations expose a different scheduling opportunity for the bug on Windows compared to Linux. Speculating further: on Linux, the PollableCondition has a pipe fd plugged into the poller, and the poller can't see a second event to dispatch until the pipe is re-enabled after the first callback completes. On Windows, perhaps there are two async poke's, allowing two dispatches to occur and enabling the window of opportunity. That's just a wild guess, but I think the main clue is that there are two dispatches running on the same PollableQueue in separate threads. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8072/#review13485 --- On Nov. 15, 2012, 3:05 a.m., Steve Huston wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8072/ --- (Updated Nov. 15, 2012, 3:05 a.m.) Review request for qpid, Andrew Stitcher, Chug Rolke, and Cliff Jansen. Description --- The assert in QPID-4424 was a check for a Thread object not set. This change resolves that problem, but could it really be that easy? Why doesn't the Linux code fail the same way? This addresses bug QPID-4424. https://issues.apache.org/jira/browse/QPID-4424 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1409628 Diff: https://reviews.apache.org/r/8072/diff/ Testing --- Original reproducing test case in QPID-4424 (run broker quiet for 15 seconds). I set a breakpoint at the assert and stepped across it without error. Thanks, Steve Huston
Re: Review Request: QPID-4424 - prevent multiple threads from processing PollableQueue events simultaneously
On Nov. 21, 2012, 2:57 p.m., Andrew Stitcher wrote: This is not an acceptable change to me. The problem is purely a windows one and the assert provides a valuable check for the Unix platform. Basically I think the windows implementation of PollableQueue is just wrong - or rather (given that it is implemented purely as a header file) that the Poller it sits on does not do the correct thing on Windows. Essentially the problem it seems to me is that the code called Poller on Windows does not actually perform the Poller functionality, it merely performs a useful service to the AsynchIO code that sits on top of it. If the name was changed then there would have been no confusion and it couldn't have been used as the basis for the Windows implementation of PollableQueue, which would have needed a different implementation on Windows. Andrew Stitcher wrote: Looking at this a bit more - I think essentially the issue is that PollableCondition (a completely dreadful name which tells you nothing about what the class is supposed to do) needs to ensure that it doesn't dispatch multiple times to PollableQueue. Perhaps there needs to be an equivalent to the completionQueue/working serializing mechanism in windows::AsynchIO here for the PollableConditionPrivate implementation. I always assumed that this mechanism was there so that the concurrency assumptions could be matched between Linux epoll and the philosophically differing Windows overlapped IO and completion port concepts. The Linux/Posix poller implementations imposes the one thread per IOHandle rule, whereas the Windows poller is agnostic and leaves it up to the derived IOHandle classes. Presumably all Windows IOHandle classes need this serializing ability, or it needs to be moved into IOHandle or the poller itself. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8147/#review13669 --- On Nov. 21, 2012, 12:54 a.m., Steve Huston wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8147/ --- (Updated Nov. 21, 2012, 12:54 a.m.) Review request for qpid, Andrew Stitcher, Chug Rolke, and Cliff Jansen. Description --- This change prevents multiple threads from processing events at the same time. They can be enqueued by multiple threads but not dispatched. This addresses bug QPID-4424. https://issues.apache.org/jira/browse/QPID-4424 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/PollableQueue.h 1411491 Diff: https://reviews.apache.org/r/8147/diff/ Testing --- Original test case from QPID-4424. Thanks, Steve Huston
Review Request: Patch to allow proton to compile in C++
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8223/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, and Rafael Schloming. Description --- See PROTON-159. Note: this edited patch will not compile and run. See the JIRA for the full patch and important background notes. This addresses bug PROTON-159. https://issues.apache.org/jira/browse/PROTON-159 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/CMakeLists.txt 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/CMakeLists.txt 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/recv.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/engine.h 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/ssl.h 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/util.h 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/buffer.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/driver.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/message/message.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/scanner.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/io.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/posix/io.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/types.c 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1413444 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1413444 Diff: https://reviews.apache.org/r/8223/diff/ Testing --- RHEL 6.3 (64 bit) gcc and g++ each in Release and Debug cmake builds. proton-test, send/recv. Thanks, Cliff Jansen
Re: Review Request: QPID-4424 - prevent multiple threads from processing PollableQueue events simultaneously
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8147/#review13748 --- Ship it! Ship It! - Cliff Jansen On Nov. 23, 2012, 11:43 p.m., Steve Huston wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8147/ --- (Updated Nov. 23, 2012, 11:43 p.m.) Review request for qpid, Andrew Stitcher, Chug Rolke, and Cliff Jansen. Description --- This change prevents multiple threads from processing events at the same time. They can be enqueued by multiple threads but not dispatched. This addresses bug QPID-4424. https://issues.apache.org/jira/browse/QPID-4424 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/PollableCondition.cpp 1412730 Diff: https://reviews.apache.org/r/8147/diff/ Testing --- Original test case from QPID-4424. Thanks, Steve Huston
Re: Review Request: Address some portability issues with BSD based systems especially FreeBSD and OS X
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8321/#review13983 --- The changes in platform.h and platform.c will be multiplied for mingw and Visual Studio. In https://reviews.apache.org/r/6302, a separate sys directory was proposed with uuid.h and time.h (and eventually driver components). Instead of ifdefs, the CMakeLists.txt file would pull in the appropriate sys/XXX/time.c file. This is more the way it is done in the qpid cpp tree. The volume of these changes (including going forward) is probably much less than in the qpid/cpp tree, so I do not foresee unamanageble nested ifdef hell in this approach. Since you are more ready for a commit, I can adjust if the chosen path is to go the ifdef route. - Cliff Jansen On Dec. 3, 2012, 6:33 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8321/ --- (Updated Dec. 3, 2012, 6:33 p.m.) Review request for qpid. Description --- These changes move in the direction of abstracting away some portability problems with the current proton code base: - Detection of correct API for uuids; - Detection of correct API for clock_gettime()/gettimeofday() - Handling ignoring SIGPIPE on writing to closed sockets - Allowing warnings to be turned of whilst building (but having them on is still the default) You can also see (and comment) on these changes at github: https://github.com/astitcher/qpid-proton/commits/portability This addresses bugs proton-104, proton-105, proton-106, and proton-168. https://issues.apache.org/jira/browse/proton-104 https://issues.apache.org/jira/browse/proton-105 https://issues.apache.org/jira/browse/proton-106 https://issues.apache.org/jira/browse/proton-168 Diffs - /proton/trunk/proton-c/CMakeLists.txt 1415142 /proton/trunk/proton-c/include/proton/driver.h 1415142 /proton/trunk/proton-c/src/driver.c 1415142 /proton/trunk/proton-c/src/messenger.c 1415142 /proton/trunk/proton-c/src/platform.h PRE-CREATION /proton/trunk/proton-c/src/platform.c PRE-CREATION Diff: https://reviews.apache.org/r/8321/diff/ Testing --- Compiles and passes the proton-test suite on both Fedora 17 and FreeBSD Thanks, Andrew Stitcher
Re: Review Request: Address some portability issues with BSD based systems especially FreeBSD and OS X
On Dec. 3, 2012, 8:01 p.m., Cliff Jansen wrote: The changes in platform.h and platform.c will be multiplied for mingw and Visual Studio. In https://reviews.apache.org/r/6302, a separate sys directory was proposed with uuid.h and time.h (and eventually driver components). Instead of ifdefs, the CMakeLists.txt file would pull in the appropriate sys/XXX/time.c file. This is more the way it is done in the qpid cpp tree. The volume of these changes (including going forward) is probably much less than in the qpid/cpp tree, so I do not foresee unamanageble nested ifdef hell in this approach. Since you are more ready for a commit, I can adjust if the chosen path is to go the ifdef route. Andrew Stitcher wrote: I'm not at all opposed to introducing a more thorough change than this and I'd even say that this change could be a stepping stone to that, however for the present this was simple enough to cover nearly all the Unix bases. If adding windows adds a lot more complexity then by all means add a platform directory instead of a simple file with different implementations. [I prefer the terminology platform because we used sys before and it was sufficiently ambiguous to not help keep the platform only aspects isolated there]. Andrew Stitcher wrote: As an aside I'd say the point to introduce extra files is when the #ifdefs start getting nested as you indicate in your comment. Then I say Ship it! I should have the mingw availabe real soon now. The review for that can revisit the ifdef question if someone voices an alternate preference. +1 on platform versus sys. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8321/#review13983 --- On Dec. 3, 2012, 8:16 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8321/ --- (Updated Dec. 3, 2012, 8:16 p.m.) Review request for qpid. Description --- These changes move in the direction of abstracting away some portability problems with the current proton code base: - Detection of correct API for uuids; - Detection of correct API for clock_gettime()/gettimeofday() - Handling ignoring SIGPIPE on writing to closed sockets - Allowing warnings to be turned of whilst building (but having them on is still the default) You can also see (and comment) on these changes at github: https://github.com/astitcher/qpid-proton/commits/portability This addresses bugs proton-104, proton-105, proton-106, and proton-168. https://issues.apache.org/jira/browse/proton-104 https://issues.apache.org/jira/browse/proton-105 https://issues.apache.org/jira/browse/proton-106 https://issues.apache.org/jira/browse/proton-168 Diffs - /proton/trunk/proton-c/CMakeLists.txt 1415142 /proton/trunk/proton-c/include/proton/driver.h 1415142 /proton/trunk/proton-c/src/driver.c 1415142 /proton/trunk/proton-c/src/messenger.c 1415142 /proton/trunk/proton-c/src/platform.h PRE-CREATION /proton/trunk/proton-c/src/platform.c PRE-CREATION Diff: https://reviews.apache.org/r/8321/diff/ Testing --- Compiles and passes the proton-test suite on both Fedora 17 and FreeBSD Thanks, Andrew Stitcher
Re: Review Request: Patch to allow proton to compile in C++
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8223/ --- (Updated Dec. 5, 2012, 10:04 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, and Rafael Schloming. Changes --- Changes just for -Wc++-compat. Still to come, separate patches for each of -Wvla -Wsign-compare -Wwrite-strings Description --- See PROTON-159. Note: this edited patch will not compile and run. See the JIRA for the full patch and important background notes. This addresses bug PROTON-159. https://issues.apache.org/jira/browse/PROTON-159 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/buffer.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/openssl.c 1417563 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1417563 Diff: https://reviews.apache.org/r/8223/diff/ Testing --- RHEL 6.3 (64 bit) gcc and g++ each in Release and Debug cmake builds. proton-test, send/recv. Thanks, Cliff Jansen
Re: Review Request: Avoid using ntohl()/ntohs()/htonl()/htons()
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8385/#review14146 --- This looks good from a portability perspective. But it must present a performance penalty on big endian hardware, though I can't quantify the amount. Are these functions not available on some platform? - Cliff Jansen On Dec. 6, 2012, 11:10 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8385/ --- (Updated Dec. 6, 2012, 11:10 p.m.) Review request for qpid, Cliff Jansen and Rafael Schloming. Description --- Removed the use of [nh]to[hn][ls] in the ANSI only part of the code as they are part of BSD sockets API not in ANSI C. There is now some duplication of code which should be removed, but nothing serious in my opinion. This addresses bug PROTON-121. https://issues.apache.org/jira/browse/PROTON-121 Diffs - /proton/trunk/proton-c/src/codec/codec.c 1417656 /proton/trunk/proton-c/src/framing/framing.c 1417656 Diff: https://reviews.apache.org/r/8385/diff/ Testing --- Compiled under Fedora and run proton-test against the built code. Thanks, Andrew Stitcher
Re: Review Request: Avoid using ntohl()/ntohs()/htonl()/htons()
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8385/#review14171 --- Ship it! Ship It! - Cliff Jansen On Dec. 6, 2012, 11:10 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8385/ --- (Updated Dec. 6, 2012, 11:10 p.m.) Review request for qpid, Cliff Jansen and Rafael Schloming. Description --- Removed the use of [nh]to[hn][ls] in the ANSI only part of the code as they are part of BSD sockets API not in ANSI C. There is now some duplication of code which should be removed, but nothing serious in my opinion. This addresses bug PROTON-121. https://issues.apache.org/jira/browse/PROTON-121 Diffs - /proton/trunk/proton-c/src/codec/codec.c 1417656 /proton/trunk/proton-c/src/framing/framing.c 1417656 Diff: https://reviews.apache.org/r/8385/diff/ Testing --- Compiled under Fedora and run proton-test against the built code. Thanks, Andrew Stitcher
Re: Please welcome Phil Harvey as committer
+1. Welcome! On Fri, Dec 14, 2012 at 9:42 AM, Carl Trieloff cctriel...@redhat.com wrote: Phil was nominated for committer and has accepted. Please join me in welcoming him. Phil, you will need to recheck out using https, and if you have any issues let me know. more info on committership can be found here: http://www.apache.org/dev/new-committers-guide.html Welcome Carl. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: patches for mingw
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- (Updated Dec. 17, 2012, 9:37 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Changes --- Updated for trunk and reworked to use the platform.h/platform.c structure. Headers now generate automatically thanks to a prior fix from Ken. If approved, I will follow this with an additional change to move the existing src/driver.c to src/posix/driver.c to match the tree structure of the new src/windows/driver.c. This plus the C++ related patches should get us 98% of the way to a Visual Studio build. Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake -G MinGW Makefiles -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe c:\cj\work\amqp\proton\mingw4\trunk\proton-c mingw32-make python ..\..\tests\proton-test This addresses bug QPID-4181. https://issues.apache.org/jira/browse/QPID-4181 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/error.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/framing/framing.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.h 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/ssl_stub.c 1423094 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/driver.c PRE-CREATION Diff: https://reviews.apache.org/r/6302/diff/ Testing --- Fedora, Windows Thanks, Cliff Jansen
Re: Build Error for Qpid 0.18 under Solaris x86
Hi Jeremy, Several people have worked towards completing a port of Qpid to Solaris, including myself, but no one yet has followed through completely. I have found that the client code is in good shape talking to a Linux C++ broker, but the broker code is largely untested. You should be able to build it from cmake if you exclude some bits (including HA, where you saw the failure): CC=cc CXX=CC cmake -DBUILD_RDMA=OFF -DBUILD_HA=OFF -DBUILD_PROBES=OFF -DPYTHON_EXECUTABLE=/path/to/bin/python path/to/qpid/cpp You may find this to your liking if you just need clients and a basic broker that uses PosixPoller.cpp (based on poll()) and lacking a file storage module. If you need a higher performance broker, persistence, or HA on Solaris, additional work to finish the solaris/ECFPoller.cpp and port the HA module and/or a file store would be needed. We would welcome any contributions you wish to make in this regard (but note that new HA and File store modules are in the works). Also Steve Huston has previously offered his services if someone wished to fund new Qpid functionality. You also have the option of running the Qpid Java broker. I hope this helps. Cliff On Mon, Dec 17, 2012 at 8:14 PM, LEUNG, Jeremy jeremy.le...@hk.daiwacm.com wrote: Hi Qpid Team, I'm getting error when I'm trying to build Qpid 0.18 under Solaris x86 with Sun Studio Compiler 10. Making all in managementgen make[1]: Entering directory `/scratch/fobuild/leungj/src/qpidc-0.18/managementgen' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/scratch/fobuild/leungj/src/qpidc-0.18/managementgen' Making all in etc make[1]: Entering directory `/scratch/fobuild/leungj/src/qpidc-0.18/etc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/scratch/fobuild/leungj/src/qpidc-0.18/etc' Making all in src make[1]: Entering directory `/scratch/fobuild/leungj/src/qpidc-0.18/src' make all-recursive make[2]: Entering directory `/scratch/fobuild/leungj/src/qpidc-0.18/src' Making all in . make[3]: Entering directory `/scratch/fobuild/leungj/src/qpidc-0.18/src' source='qpid/ha/BrokerInfo.cpp' object='qpid/ha/BrokerInfo.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \ /bin/bash ../libtool --tag=CXX --mode=compile CC -DHAVE_CONFIG_H -I. -I../include -I../include -I. -I=. -I/prod/deriv/imagine/ThirdPartyDirs/boost_1_34_1/include -DQPID_LIBEXEC_DIR=\/usr/local/libexec/qpid\ -DBOOST_FILESYSTEM_VERSION=2 -g -library=stlport4 -mt -c -o qpid/ha/BrokerInfo.lo qpid/ha/BrokerInfo.cpp libtool: compile: CC -DHAVE_CONFIG_H -I. -I../include -I../include -I. -I=. -I/prod/deriv/imagine/ThirdPartyDirs/boost_1_34_1/include -DQPID_LIBEXEC_DIR=\/usr/local/libexec/qpid\ -DBOOST_FILESYSTEM_VERSION=2 -g -library=stlport4 -mt -c qpid/ha/BrokerInfo.cpp -KPIC -DPIC -o qpid/ha/.libs/BrokerInfo.o qpid/ha/types.cpp, line 35: Error: Multiple declaration for QPID_REPLICATE. qpid/ha/types.cpp, line 55: Error: qpid::ha::Enumqpid::ha::ReplicateLevel::N is initialized twice. qpid/ha/types.cpp, line 61: Error: qpid::ha::Enumqpid::ha::BrokerStatus::N is initialized twice. 3 Error(s) detected. make[3]: *** [qpid/ha/BrokerInfo.lo] Error 1 make[3]: Leaving directory `/scratch/fobuild/leungj/src/qpidc-0.18/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/scratch/fobuild/leungj/src/qpidc-0.18/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/scratch/fobuild/leungj/src/qpidc-0.18/src' make: *** [all-recursive] Error 1 Regards, Jeremy DISCLAIMER: This email and any attachment(s) are intended solely for the person(s) named above, and are or may contain information of a proprietary or confidential nature. If you are not the intended recipient(s), you should delete this message immediately. Any use, disclosure or distribution of this message without our prior consent is strictly prohibited. This message may be subject to errors, incomplete or late delivery, interruption, interception, modification, or may contain viruses. Neither Daiwa Capital Markets Hong Kong Limited, its subsidiaries, affiliates nor their officers or employees represent or warrant the accuracy or completeness, nor accept any responsibility or liability whatsoever for any use of or reliance upon, this email or any of the contents hereof. The contents of this message are for information purposes only, and subject to change without notice. This message is not and is not intended to be an offer or solicitation to buy or sell any securities or financial products, nor does any recommendation, opinion or advice necessarily reflect those of Daiwa Capital Markets Hong Kong Limited, its subsidiaries or affiliates.
Re: Review Request: patches for mingw
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6302/ --- (Updated Dec. 24, 2012, 8:55 p.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and Rafael Schloming. Changes --- Hopefully, this follows all of Andrew's suggestions... Description --- This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 2.0.7. A push-button build is still a ways off. The custom_commands in the cmake script to generate the protocol headers don't work yet on Windows. The most intrusive change was the introduction of a pn_socket_t type to hold a socket on both Windows and Posix platforms. An attempt was made to minimize the use of #ifdefs and split platform code into separate posix and windows directories, as is done for the C++ code. There is so little needed at the moment, this may be overkill. The qpid-proton-posix library was ditched and combined with the main qpid-proton library. Instead, the work is done in CMake to assemble the correct shared and platform specific sources as is done in the C++ tree. The driver.c implementation is proof of concept using Winsock select(). Future work would most likely replace this with an I/O completion port implementation. 1. mkdir ...\trunk\proton-c\build 2. set env vars as per trunk\config.sh set PATH=C:\Program Files (x86)\CMake 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build set PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk 3. generate the headers: cd trunk\proton-c\build python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py encodings.h python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py protocol.h 4. build cmake -G MinGW Makefiles -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe c:\cj\work\amqp\proton\mingw4\trunk\proton-c mingw32-make python ..\..\tests\proton-test This addresses bug QPID-4181. https://issues.apache.org/jira/browse/QPID-4181 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/php/php.i 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/cproton.i 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver_extras.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/error.h 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/driver.c 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/error.c 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.h 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.c 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1425672 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/driver.c PRE-CREATION Diff: https://reviews.apache.org/r/6302/diff/ Testing --- Fedora, Windows Thanks, Cliff Jansen
Re: Review Request: Patch to allow proton to compile in C++
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8223/ --- (Updated Jan. 24, 2013, 8:14 a.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, and Rafael Schloming. Changes --- Same, but updated to reflect changes on trunk. Description --- See PROTON-159. Note: this edited patch will not compile and run. See the JIRA for the full patch and important background notes. This addresses bug PROTON-159. https://issues.apache.org/jira/browse/PROTON-159 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/buffer.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/openssl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1435762 Diff: https://reviews.apache.org/r/8223/diff/ Testing --- RHEL 6.3 (64 bit) gcc and g++ each in Release and Debug cmake builds. proton-test, send/recv. Thanks, Cliff Jansen
Review Request: part 2 of gcc flags for C++ compatibility
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9085/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- gcc flag -write-strings that provides c++ checking This addresses bug proton-159. https://issues.apache.org/jira/browse/proton-159 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/recv.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/send.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/util.h 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.h 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/openssl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1435762 Diff: https://reviews.apache.org/r/9085/diff/ Testing --- compiles on linux and runs proton test. Along with other patches, also compiles in Visual Studio. Thanks, Cliff Jansen
Review Request: part 3 of gcc flags for C++ compatibility
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9086/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- gcc flag -sign-compare that provides c++ checking This addresses bug proton-159. https://issues.apache.org/jira/browse/proton-159 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/buffer.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/posix/driver.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/openssl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1435762 Diff: https://reviews.apache.org/r/9086/diff/ Testing --- compiles on linux and runs proton test. Along with other patches, also compiles in Visual Studio. Thanks, Cliff Jansen
Review Request: part 4 of gcc flags for C++ compatibility
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9088/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- gcc flag -Wvla that checks for variable length array usage This addresses bugs proton-159 and proton-57. https://issues.apache.org/jira/browse/proton-159 https://issues.apache.org/jira/browse/proton-57 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/recv.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1435762 Diff: https://reviews.apache.org/r/9088/diff/ Testing --- compiles on linux and runs proton test. Along with other patches, also compiles in Visual Studio. Thanks, Cliff Jansen
Re: Review Request: part 4 of gcc flags for C++ compatibility
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9088/ --- (Updated Jan. 24, 2013, 8:49 a.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- gcc flag -Wvla that checks for variable length array usage This addresses bugs proton-159 and proton-57. https://issues.apache.org/jira/browse/proton-159 https://issues.apache.org/jira/browse/proton-57 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/recv.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1435762 Diff: https://reviews.apache.org/r/9088/diff/ Testing --- compiles on linux and runs proton test. Along with other patches, also compiles in Visual Studio. Thanks, Cliff Jansen
Re: Review Request: part 4 of gcc flags for C++ compatibility
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9088/ --- (Updated Jan. 24, 2013, 8:49 a.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- gcc flag -Wvla that checks for variable length array usage This addresses bugs proton-159 and proton-57. https://issues.apache.org/jira/browse/proton-159 https://issues.apache.org/jira/browse/proton-57 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/recv.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1435762 Diff: https://reviews.apache.org/r/9088/diff/ Testing --- compiles on linux and runs proton test. Along with other patches, also compiles in Visual Studio. Thanks, Cliff Jansen
Re: Review Request: part 4 of gcc flags for C++ compatibility
On Jan. 25, 2013, 1:23 a.m., Mary Hinton wrote: Patch 1 makes the needed change to PN_ENSURE PN_ENSUREZ in util.h. Also makes the changes for these macros in messenger.c and engine.c. Patch 4 adds new PN_ENSURE macros in proton.c and codec.c, but is using the old PN_ENSURE macro. Thank-you for your feedback. You are correct, but that is intentional. Each of the 4 patches currently for review is self contained and addresses a separate issue. When combining the patches, they conflict and need to be resolved to include all the relevant fixes. It can't be helped but assists with keeping the conceptual bits separate. As I post the other incremental patches I will also provide cumulative ones that can be used to easily build the final result should anyone wish to kick the tires. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9088/#review15669 --- On Jan. 24, 2013, 8:49 a.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9088/ --- (Updated Jan. 24, 2013, 8:49 a.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- gcc flag -Wvla that checks for variable length array usage This addresses bugs proton-159 and proton-57. https://issues.apache.org/jira/browse/proton-159 https://issues.apache.org/jira/browse/proton-57 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/recv.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1435762 Diff: https://reviews.apache.org/r/9088/diff/ Testing --- compiles on linux and runs proton test. Along with other patches, also compiles in Visual Studio. Thanks, Cliff Jansen
Review Request: part5 changes for g++
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9124/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- Changes for C++ not handled by other flags. Basically: inttypes.h issues aggregate assignment late declaration of auto vars in the middle of a switch statement explicit casts of void* to xyz* minor const fussiness Note that the next step to VC++ on Windows has no additional language syntax issues. It is all about missing C99 headers and library support. This addresses bug proton-159. https://issues.apache.org/jira/browse/proton-159 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/CMakeLists.txt 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/CMakeLists.txt 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/engine.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/ssl.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/message/message.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform_fmt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/scanner.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/types.c 1439550 Diff: https://reviews.apache.org/r/9124/diff/ Testing --- This compiles and runs, but only if you stitch the previous 4 related patches together. It does not work standalone. Thanks, Cliff Jansen
Re: Review Request: part 2 of gcc flags for C++ compatibility
On Jan. 25, 2013, 7:01 p.m., Kenneth Giusti wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c, line 717 https://reviews.apache.org/r/9085/diff/1/?file=251495#file251495line717 If/when possible, I'd prefer declaring these as pointer-to-const, rather than casting away the const-ness. That probably requires more changes to any functions that take them as arguments (like parse_url), but that's for the best. IMHO the proton-c codebase doesn't use 'const' correctly in a lot of cases. I created a separate issue to fix this. https://issues.apache.org/jira/browse/PROTON-206 - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9085/#review15700 --- On Jan. 24, 2013, 8:24 a.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9085/ --- (Updated Jan. 24, 2013, 8:24 a.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- gcc flag -write-strings that provides c++ checking This addresses bug proton-159. https://issues.apache.org/jira/browse/proton-159 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/recv.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/examples/messenger/c/send.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/util.h 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.h 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/openssl.c 1435762 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1435762 Diff: https://reviews.apache.org/r/9085/diff/ Testing --- compiles on linux and runs proton test. Along with other patches, also compiles in Visual Studio. Thanks, Cliff Jansen
Review Request: Reconcile C99 and C++ inconsistencies within proton
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9169/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Description --- This patch relies on earlier patches https://reviews.apache.org/r/8223/ https://reviews.apache.org/r/9085/ https://reviews.apache.org/r/9086/ https://reviews.apache.org/r/9088/ https://reviews.apache.org/r/9124/ Combined with the others it builds and runs in Visual Studio 2008 32 bit, provided you build qpid-proton static (no external symbol defines yet). There are 5 proton-test failures left to investigate. platform_fmt.h is reproduced in its entirety since I wasn't sure how to show the delta compared to the previous version. type_compat.h is special because it is indirectly exposed to the API, (so that the API can be consumed at all) . It is structured as it is because the lack of these C99 types is driving everybody crazy. Boost has their own definitions, as do the python libs we use in swig. It gets more complicated since Microsoft is introducing some of these types over time, but are not backporting them to older Visual Studio versions. The middle part of type_compat.h tries to do the right thing for 99% of the cases. If the user runs into a conflict with a third party library there are positive and negative overrides to allow proton to get along with other 3rd party libs. Note that ssize_t is an odd duck in that it isn't actually part of C99. This addresses bug PROTON-213. https://issues.apache.org/jira/browse/PROTON-213 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/codec.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/engine.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/framing.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/message.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/sasl.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/ssl.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/type_compat.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/buffer.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/parser.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform_fmt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/scanner.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 1439550 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/driver.c 1439550 Diff: https://reviews.apache.org/r/9169/diff/ Testing --- code compiles on gcc/linux, gcc/mingw, Visual Studio Thanks, Cliff Jansen
Re: Review Request: symbol import/export
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9299/ --- (Updated Feb. 5, 2013, 2:33 a.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, Rafael Schloming, and Mary Hinton. Changes --- Clarified the first half ... refers to import_export.h Description (updated) --- Changes for specifying symbol import/export needed for Visual Studio. Copied with minor variances from the qpid/cpp tree. The first half of import_export.h is generic, the second half specific to the qpid-proton library. If in future, additional libraries come into existence, this include file can be split (or perhaps expanded), without requiring any changes to files outside of proton-c/include/proton. This addresses bug proton-68. https://issues.apache.org/jira/browse/proton-68 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/buffer.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/codec.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/cproton.i 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver_extras.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/engine.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/error.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/framing.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/import_export.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/message.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/messenger.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/parser.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/sasl.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/scanner.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/ssl.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h 1442452 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/util.h 1442452 Diff: https://reviews.apache.org/r/9299/diff/ Testing --- gcc on linux, and Visual Studio on Windows Thanks, Cliff Jansen
Review Request: optionally set warning flags only if gcc version supports them
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9394/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, Keith Wall, and Rafael Schloming. Description --- test gcc version and set flags based on that. Code stolen from the large qpid/cpp/src/CMakeLists.txt file. I poked around the gcc docs and determined that they all showed up at the same time in 4.3.0. Please comment if you find the warning message too scary or too pip-squeaky. I tried to use CMake's CHECK_C_COMPILER_FLAG() to test each flag and add it separately (oh, so elegant), but it didn't work at all, and the function definition changtes a lot between 2.6 and 2.8. So I opted for the simpler solution you see here. This addresses bug PROTON-221. https://issues.apache.org/jira/browse/PROTON-221 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1444335 Diff: https://reviews.apache.org/r/9394/diff/ Testing --- Just on rhel6. I clearly need a test rhel5 VM to augment my Windows and Solaris VMs. Thanks, Cliff Jansen
Review Request: Initial CTest support
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9433/ --- Review request for qpid and Mary Hinton. Description --- The smallest useful example I could devise to illustrate the possibilities. See https://issues.apache.org/jira/browse/PROTON-238 for more info This addresses bug PROTON-238. https://issues.apache.org/jira/browse/PROTON-238 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/CMakeLists.txt 1445761 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1445761 Diff: https://reviews.apache.org/r/9433/diff/ Testing --- linux only so far. Minimally the PYTHONPATH will require a ';' separator in Windows. Thanks, Cliff Jansen
Re: Review Request: Initial CTest support
I stated that the code only worked for Linux so far. Porting this to Windows up front would have a) made the example less clear and b) delayed getting initial feedback. I already know about the ';', a bad call to env.py, a portability bug in env.py (after fixing the former), and the need to deal with different library locations such as RelWithDebInfo. Presumably after addressing those, a little more quicksand will need wading through too. I'm working on it. On Thu, Feb 14, 2013 at 10:54 AM, Mary Hinton m.hin...@nc.rr.com wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9433/#review16596 --- I put your changes in my code and ran it. I was trying to figure out why it is failing, but haven't had any success, so I'll just include the result here. c:\proton\trunkctest -V UpdateCTestConfiguration from :C:/proton/trunk/DartConfiguration.tcl Parse Config file:C:/proton/trunk/DartConfiguration.tcl UpdateCTestConfiguration from :C:/proton/trunk/DartConfiguration.tcl Parse Config file:C:/proton/trunk/DartConfiguration.tcl Test project C:/proton/trunk Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 1 Start 1: proton-c 1: Test command: c:\Python27\python.exe C:/proton/trunk/proton-c/env.py PYTHONPATH=C:/proton/trunk/te ts/python:C:/proton/trunk/proton-c/bindings/python:C:/proton/trunk/proton-c/bindings/python C:/proton/ runk/tests/python/proton-test 1: Test timeout computed to be: 1500 1: Traceback (most recent call last): 1: File C:/proton/trunk/proton-c/env.py, line 64, in module 1: sys.exit(main()) 1: File C:/proton/trunk/proton-c/env.py, line 60, in main 1: os.execvpe(args[0], args, new_env) 1: File c:\Python27\lib\os.py, line 353, in execvpe 1: _execvpe(file, args, env) 1: File c:\Python27\lib\os.py, line 368, in _execvpe 1: func(file, *argrest) 1: OSError: [Errno 2] No such file or directory 1/1 Test #1: proton-c .***Failed Required regular expression not found.Regex=[T tals:.*, 0 failed ] 0.44 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.69 sec The following tests FAILED: 1 - proton-c (Failed) Errors while running CTest I tried the python line substituting a ';' for the ':' in the PYTHONPATH, but same results. Not sure what is missing. - Mary Hinton On Feb. 13, 2013, 7:41 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9433/ --- (Updated Feb. 13, 2013, 7:41 p.m.) Review request for qpid and Mary Hinton. Description --- The smallest useful example I could devise to illustrate the possibilities. See https://issues.apache.org/jira/browse/PROTON-238 for more info This addresses bug PROTON-238. https://issues.apache.org/jira/browse/PROTON-238 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/CMakeLists.txt 1445761 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1445761 Diff: https://reviews.apache.org/r/9433/diff/ Testing --- linux only so far. Minimally the PYTHONPATH will require a ';' separator in Windows. Thanks, Cliff Jansen - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: Final Visual Studio build issues
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9489/ --- Review request for qpid and Rafael Schloming. Description --- These changes (against 0.4 rc1) allow a complete build of the C portions of proton-c in Visual Studio. Of main note is the addition of freegetopt as a 3rd party module and the change to the top level license file. This addresses bugs proton-236 and proton-237. https://issues.apache.org/jira/browse/proton-236 https://issues.apache.org/jira/browse/proton-237 Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/LICENSE 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/recv.c 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/send.c 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/getopt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/LICENSE PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.c PRE-CREATION Diff: https://reviews.apache.org/r/9489/diff/ Testing --- Tested on rhel6 and VS2008 Thanks, Cliff Jansen
Re: Review Request: Final Visual Studio build issues
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9489/ --- (Updated Feb. 19, 2013, 3:59 p.m.) Review request for qpid and Rafael Schloming. Changes --- Same as before, but with added README changes with Windows build instructions and use of ctest Description --- These changes (against 0.4 rc1) allow a complete build of the C portions of proton-c in Visual Studio. Of main note is the addition of freegetopt as a 3rd party module and the change to the top level license file. This addresses bugs proton-236 and proton-237. https://issues.apache.org/jira/browse/proton-236 https://issues.apache.org/jira/browse/proton-237 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/LICENSE 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/README 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/recv.c 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/send.c 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1446820 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/getopt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/LICENSE PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.c PRE-CREATION Diff: https://reviews.apache.org/r/9489/diff/ Testing --- Tested on rhel6 and VS2008 Thanks, Cliff Jansen
Re: Welcome Fraser as committer
Welcome Fraser! On Mon, Feb 25, 2013 at 10:57 AM, Carl Trieloff cctriel...@redhat.com wrote: Fraser Adams has been nominated for committer for qpid and has accepted. Please join me in welcoming him to the project!. Fraser, we are watching to see your first commit! kind regards Carl. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal: get rid of automake build system.
Not that this speaks directly to the issue of instant deletion versus a more dignified old-folks home retirement, but I would point out that CMake is the sole build mechanism for AMQP 1.0 support in C/C++. You can't avoid it going forward for at least part of your build. Also since a lot of the test infrastructure is tied to the build system, there will be an awful lot of holes showing up fast in the automake side. Finally, the effort to allow the automake side to continue to build (if only to a limping state) may consist of cruel and unusual punishment for an unlucky developer who is trying to add useful new features (async store perchance?). On Fri, Mar 8, 2013 at 10:36 AM, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: Hi Alan, Personally I'd rather cmake was given the heave ho ;- for all of it's pain automake is something of a defacto standard for a ton of projects. Re Anyone know of specific issues that need to be addressed in cmake? yeah, I don't have cmake installed :-D sorry. I'm just messing. Seriously though I've just reached a point with 0.20 where I didn't have to hack around with things to get Qpid to compile on my Ubuntu box, so if I'm honest I'm a little disinclined to change something that finally works to have things potentially break more again. If there are strong feelings that agree with your view to move to cmake can I suggest that deprecation rather than removal of automake is announced. I think just deleting it from 0.22 is a bit draconian and I think we should have a couple of releases at least where both exist but one is marked deprecated so that users get a chance to flag up where things break (plenty of users only work off official releases - imagine their surprise if they are forced to use cmake and either they don't have cmake installed or the cmake breaks for them). I'm clearly biased 'cause I haven't used cmake, but I'm very anti just deleting the automake build without a period of it being properly deprecated. All that said I do have sympathy with the view that having two build systems is probably not ideal. Oh and to follow on a thread that was started a little while back by Gordon I *really* think that this proposal should be flagged up on the qpid users mailing list too!! Frase On 08/03/13 14:56, Alan Conway wrote: Having 2 build systems is a waste of time and a source of confusion. We introduced the cmake build with the intent that it would replace the automake system, I think the time has come to say farewell to automake. The cmake system is ready: it covers the same ground as automake and more (esp. windows), and it is actively and successfully used by many developers. I propose that once we have branched for the 0.22 release, we delete the automake build system. That will give us plenty of time to find and fix any issues with the cmake system before the next release. I'm not aware of any major deficiencies in the cmake system, minor discrepancies will be quickly found and fixed once everyone has switched. I volunteer to help resolve issues that come up. Are there any strong opinions out there for or against? Anyone know of specific issues that need to be addressed in cmake? Cheers, Alan. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proton: What is environment variable M2_HOME for?
I am guilty for its inclusion and can't find a specific reason (from memory, or trying to force a failure) for its need. Note that there is no FindMaven.cmake equivalent available, so I cooked up a heuristic. I relied on maven being in the PATH. Also, based on my unfamiliarity with maven, I think I just read the install instructions to require M2_HOME being set on all platforms as well to signify a sane maven install. I have no objection to its removal if it works on your systems. I'll adjust to taste if things fail on windows (won't know until I can actually build the java bits... still a work in progress) Cliff On Thu, Mar 14, 2013 at 12:20 PM, Alan Conway acon...@redhat.com wrote: It's required by the proton CMakeLists.txt to run the JNI tests, but I can run them without this variable set no problem. I'd like to remove the requirement unless there's a good reason for it. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: swig java for windows proton - compile
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10076/
---
Review request for qpid and Keith Wall.
Description
---
More for proton-254.
Of note is the mechanism proton-c/bindings/java/checkmatch.py to ensure that
any changes to codec.h will cause a build failure if they aren't also included
in the corresponding java.i file. All proposed solutions on the list thus far
have not been particularly elegant. This attempts to address the main drawback
of this apporach (the two files getting out of sync).
I suspect that the solution for other swig languages will at least differ on
the %extend pn_atom_t {} section. I would prefer to defer a more generalized
solution (if any) until another example pops up.
The pieces all build, but ctest fails and I cannot get the equivalent to start
running from the command line, so I can't work backwards to a better cmake
build. By hand I must
- cp ./build/proton-c/bindings/java/proton-jni-0.4.jar
./build/proton-c/bindings/java/proton-jni.jar
- resolve PATH for finding maven in ctest (may not be an issue if set
globally).
Even after this, the maven test fails with
java.util.ServiceConfigurationError: org.apache.qpid.proton.codec.DataFactory:
Provider org.apache.qpid.proton.codec.jni.JNIDataFactory could not be
instantiated: java.lang.UnsatisfiedLinkError: no proton-jni in java.library.path
I'm not sure where to point fingers (the maven pom, the built files). I will
attempt a simple java test outside of maven to see if that works.
This addresses bug proton-254.
https://issues.apache.org/jira/browse/proton-254
Diffs
-
http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/java/CMakeLists.txt
1459606
http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/java/checkmatch.py
PRE-CREATION
http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/java/java.i
1459606
http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/ProtonUseJavaSourceFileList.cmake
1459606
Diff: https://reviews.apache.org/r/10076/diff/
Testing
---
rhel 6 and windows 8
Thanks,
Cliff Jansen
Review Request: resolve mixing of UUIDs and GUIDs on Windows
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10863/ --- Review request for qpid, Chug Rolke and Steve Huston. Description --- This fix makes explicit when GUIDs are in play. It asssumes that all values passed in from and back to the lower layer are UUIDs. It converts between the two binary formats as necessary. This addresses bug qpid-4792. https://issues.apache.org/jira/browse/qpid-4792 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/uuid.cpp 1477707 Diff: https://reviews.apache.org/r/10863/diff/ Testing --- Windows, uuids received from and sent to Linux, spout drain Thanks, Cliff Jansen
Re: [c++]: hello_world.cpp
I volunteer for the WCF version. I'll get to it as soon as I get QPID-2501 out of the way. I also plan to do some work on the WCF documentation side as soon as I can as well. I am going to be on vacation next week so I will try to squeeze in what I can. Cliff On Fri, Apr 16, 2010 at 6:27 AM, Jonathan Robie jonathan.ro...@redhat.com wrote: Thanks, Gordon - this is definitely an improvement. I applied the patch, committed it, and used this in the tutorial. I also created a Python example and check it in. I'll also do this for Java (pestering Rajith as needed). Anyone want to do a Hello World program for WCF? I'm not really set up in that environment. Jonathan - 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: [.net]: some debate please
Perhaps it would be useful for somebody to assist this debate by introducing the messaging API in the .NET context and addressing why, for example, .NET programmers need this API, but Java programmers don't. Or why a developer who might be inclined to use WCF should use this messaging API instead. Looking at the initial code drop, I have a very hard time imagining a .NET programmer who might feel remotely comfortable using it. This is not a comment on the quality or functionality of the module, just on the utter disregard for basic .NET conventions of the C++ API as transposed to .NET, i.e. the surface area of the library. I don't think it would take a lot of work to address this. The question remains whether this new client intends to ignore distributed transactions, including the new promotable transactions in AMQP 1.0. But compared to the existing dotnet client, from a practical point of view, a module whose heavy lifting is largely done in the C++ space will automatically benefit from bug fixes to that code base. This beats the current dotnet mechanism of running a code translator against a Java snapshot every other year. Carl Trieloff wrote: The current WCF uses the 0-10 API, I would suggest moving the WCF client to the updated C++ API. I believe this has been agreed to be done at some point before on the list which would then be consistent with this work Actually the current WCF implementation uses the 0-10 C++ API where convenient and bypasses it when necessary. The complete lack of distributed transaction support in the updated C++ API means that even more behind the scenes work will be required. But wherever possible, the new messaging API would be used. Regardless of recent events, the Interop layer of the WCF channel was known to need rewriting for AMQP 1.0. I had hoped that the rewrite would lead to a 0-10 and 1.0 friendly library which, surprise, looks much like this messaging API plus qpid-config. But, realistically, that would happen after many of the other TODO items in the WCF Reame file were done. Cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
Why would a user chose to use this binding instead
of the WCF client - I guess thats the key question ?
If I understand the previous posts in this thread, the answer is that
people who are comfortable with WCF paradigms will use WCF, and people
who like to think a little closer to AMQP on the wire will use the new
messaging libraries. (See Rafael's post regarding JMS).
Presumably people who have already written something to the python and
C++ apis may find it more natural to port their work to .NET using
this new binding too.
On Tue, May 18, 2010 at 7:37 AM, Marnie McCormack
marnie.mccorm...@googlemail.com wrote:
I'll confess that I'm fairly uncomfortable with any other new .Net API,
especially since the current situation is that we have no client which can
interop across both brokers with all the other clients successfully (with
the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
hoping we could get behind the new WCF client and build that out as the
replacement for the existing .Net components.
Are there a set of .Net use cases that we're seeking to support - or even a
set of minimal client use cases that this binding supports ? Does it support
interop testing in CI ? Why would a user chose to use this binding instead
of the WCF client - I guess thats the key question ?
Are there docs out there for the bindings ?
Another key point is that if we're going to produce 'bindings' we need to
get much better at backwards compatibility on Qpid. We have existing C++
clients stranded on an old Qpid build as a result of some of our previous
decisions, along with C# users who won't be able to interop. I'd like us to
start deprecating APIs in a consistent way going forward.
Thanks,
Marnie
On Mon, May 17, 2010 at 4:07 PM, Ted Ross tr...@redhat.com wrote:
I commented on the Jira but I'll jump in on this thread in case folks are
not reading the Jira comments.
The contribution in question is a thin .Net binding for the new C++
messaging API. This is why it was placed in the qpid/cpp/bindings area and
not in the qpid/{dotnet,wcf} areas or in its own new top-level-directory.
This is where several other-language bindings currently reside. I think we
should be developing bindings for the API in as many languages as we can
(Python, Ruby, PHP, Perl, Java, etc.).
This binding does not add any messaging value to the API. If new
features or new behavior are desired, the underlying C++ API should be
enhanced and the language bindings updated to reflect those enhancements.
The contribution simply allows .NET programs in C#, VB, Powershell, Excel,
etc. to access the Qpid C++ messaging API. It is not in the same category
as the qpid/wcf code which adds substantial value over and above basic
messaging.
The advantage of the thin-binding approach over the existing dotnet
full-client-implementation-in-C# is that it removes the need to support yet
another full-client implementation. The dotnet code is currently
unmaintained, we need a better way to support .NET users.
I apologize for committing this patch to trunk without sufficient debate.
I considered this to be more of an added feature to the C++ client and less
of a whole-new-direction for .NET. I see that I was wrong and will, of
course, abide by what the community decides is best.
-Ted
On 05/14/2010 04:38 PM, Marnie McCormack wrote:
I don't have a strong view on the 'correct' approach since I'm not
familiar
with the .Net components.
However, I agree wholeheartedly with Rafi's comments about dropping this
in
without a discussion beforehand (and apologies if I missed one?). If I was
an existing .Net contributer I'd be pretty hacked off I think !
What should we do now while the discussion on this takes place ?
Marnie
On Wed, May 12, 2010 at 11:59 AM, Rafael Schlomingrafa...@redhat.com
wrote:
Gordon Sim wrote:
On 05/10/2010 09:33 PM,tr...@apache.org wrote:
Author: tross
Date: Mon May 10 20:33:19 2010
New Revision: 942892
URL:http://svn.apache.org/viewvc?rev=942892view=rev
Log:
QPID-2589 - Applied patch from Chuck Rolke.
This commit adds a new component and yet another approach for .net,
specifically a .net wrapper around the c++ messaging API.
We also have a wcf client (this also uses some c++ code, but uses the
0-10
specific API plus some direct use of the internals of the client), and
two
different pure c# clients for 0-8 and 0-10 respectively.
Four different options each with its own codebase isn't sensible. We
can't
maintain them all and it is confusing for users.
While aspects of this latest approach certainly appeal to me personally
(the messaging API is better for a number of reasons than the older API
and
wrapping that also keeps the clients more aligned conceptually), I think
it
deserves a bit more debate. Specifically we have to explicitly decide as
a
community whether this new approach is a path we should pursue. I'm keen
Re: Need a Roadmap
I'm working on enhancing the WCF channel stack to make it easier to program with the binary binding and improve the interoperability with other clients. Cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Help with Windows app design
Hi Chuck,
I haven't seen that exact problem, but for me, 9 times out of 10 mysterious
problems between debug and release versions boiled down to build issues.
While the following rules of thumb can probably be relaxed in some
situations, I tried to always make sure:
Never mix debug and release DLLs created by the C++ compiler. All debug or
all release. (But OK to mix debug C# with release C++)
Make sure all C++ DLLs are compiled and linked the same. That means
examining the CMake builds of the common, client and messaging libraries and
using the defines, directives, and library paths as the master switches.
Then make sure your VS C++/CLI DLLs use the identical compile and link
switches. Note that this also means that your Boost libs need to be
compiled the same too. And since the switches or DLL names do change from
debug to release, it means careful squinting at two full sets of build logs
to be sure you didn't copy/paste the wrong stuff from debug to release
directives in your Visual Studio project file. Very tedious but very
important. Also be sure to verify that the expected DLLs were pulled in at
run time.
The other common culprit was due to MP bugs in my own code, but I would be
far more likely to see those on tear down (finalizers) than on startup.
Cliff
On Tue, Sep 21, 2010 at 9:00 AM, Chuck Rolke cro...@redhat.com wrote:
Hi,
I'm working with the qpid cpp messaging dotnet client. A quick review: user
programs are in a .NET managed language, say C#. They refer to an Interop
DLL that connects them to the unmanaged qpid messaging layer built by
qpid/cpp.
Running under debug things are fine. However, when I switch to Release or
RelWithDebInfo, the qpid messaging DLL functions crash in the function
prologue while it is trying to install it's exception handler. I've
reproduced that failing call chain below. It acts like the FS:[0] chain is
read-only.
From reading John Robbins I suspect that default exception handling being
synchronous in Debug and asynchronous in Release may be an issue but I can't
pinpoint it. All the qpid messaging dlls are linked the same (/EHsc,
Multi-threaded DLL) for Debug and Release. In Debug mode one can step
through writing to FS:[0] just fine.
I'd appreciate some discussion.
Regards,
Chuck
C# code
===
connection = new Connection(broker);
C++ Binding DLL
===
Connection::Connection(System::String ^ url) :
connectionp(new
::qpid::messaging::Connection(QpidMarshal::ToNative(url)))
{
}
Qpid Messaging DLL
==
qpid::messaging::Connection::Connection:
6264E580 push0h
6264E582 push626841EBh
6264E587 mov eax,dword ptr fs:[h]
6264E58D pusheax
6264E58E pushecx
6264E58F pushesi
6264E590 mov eax,dword ptr [___security_cookie (626A92D0h)]
6264E595 xor eax,esp
6264E597 pusheax
6264E598 lea eax,[esp+0Ch]
6264E59C mov dword ptr fs:[h],eax--- fails here
6264E5A2 mov esi,ecx
6264E5A4 push1F8h
6264E5A9 mov dword ptr [esi],0
6264E5AF calloperator new (62682202h)
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Building WCF Channel
Hi Steve, What version of Qpid are you using? There's no reference to boost_date_time in the interop project today. The boost include libraries contain fancy #pragmas to force linking against the (correct) library version. Daniel: Since you built the cpp tree first, it also needs the same library (for the same reason). Clearly it exists. Presumably should just need to tweak one of your env vars. I am away from my build environment for the next few hours but I will do a fresh build later today and see if I run into the same problem (I have the same OS and VS version). Cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Building WCF Channel
Hi Daniel, To confirm, I can build qpid/wcf libraries on Windows 7 and using VS 2008. I need to set BOOST_ROOT and BOOST_VERSION and QPID_BUILD_ROOT in my environment before building. At runtime, I need to make sure that all of the following are available from the PATH of subdirectories (often using dependency walker to check): Apache.Qpid.Channel.dll Apache.Qpid.Interop.dll boost_date_time-vc90-mt-gd-1_39.dll boost_filesystem-vc90-mt-gd-1_39.dll boost_program_options-vc90-mt-gd-1_39.dll boost_regex-vc90-mt-gd-1_39.dll boost_system-vc90-mt-gd-1_39.dll boost_thread-vc90-mt-gd-1_39.dll boost_unit_test_framework-vc90-mt-gd-1_39.dll qpidclientd.dll qpidcommond.dll qpidtypesd.dll or if running a release build: Apache.Qpid.Channel.dll Apache.Qpid.Interop.dll boost_date_time-vc90-mt-1_39.dll boost_filesystem-vc90-mt-1_39.dll boost_program_options-vc90-mt-1_39.dll boost_regex-vc90-mt-1_39.dll boost_system-vc90-mt-1_39.dll boost_thread-vc90-mt-1_39.dll boost_unit_test_framework-vc90-mt-1_39.dll qpidclient.dll qpidcommon.dll qpidtypes.dll qpidxarm.dll Cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Building WCF Channel
QPID_BUILD_ROOT is the build directory location that you choose in CMake to build the qpid/cpp libraries that WCF relies on. It is the top level directory that contains qpid-cpp.sln. On Mon, Oct 4, 2010 at 10:00 AM, Daniel Sack daniel.s...@techtalk.at wrote: For cross-checking can you send me which directory must be set for QPID_BUILD_ROOT Br, Daniel -Original Message- From: Cliff Jansen [mailto:cliffjan...@gmail.com] Sent: Montag, 04. Oktober 2010 18:36 To: Daniel Sack Cc: dev@qpid.apache.org Subject: Re: Building WCF Channel In your case, BOOST_VERSION=104000 On Mon, Oct 4, 2010 at 9:23 AM, Daniel Sack daniel.s...@techtalk.at wrote: Hi, Sry for the delay, didn't had the time to check. I have BOOST_ROOT and QPID_BUILD_ROOT set but not BOOST_VERSION. Haven't found it in the documentation yet. What do I have to set for BOOST_VERSION? I have installed boost version 1.40. Br, Daniel -Original Message- From: Cliff Jansen [mailto:cliffjan...@gmail.com] Sent: Montag, 04. Oktober 2010 17:51 To: dev@qpid.apache.org Cc: Daniel Sack Subject: Re: Building WCF Channel Hi Daniel, To confirm, I can build qpid/wcf libraries on Windows 7 and using VS 2008. I need to set BOOST_ROOT and BOOST_VERSION and QPID_BUILD_ROOT in my environment before building. At runtime, I need to make sure that all of the following are available from the PATH of subdirectories (often using dependency walker to check): Apache.Qpid.Channel.dll Apache.Qpid.Interop.dll boost_date_time-vc90-mt-gd-1_39.dll boost_filesystem-vc90-mt-gd-1_39.dll boost_program_options-vc90-mt-gd-1_39.dll boost_regex-vc90-mt-gd-1_39.dll boost_system-vc90-mt-gd-1_39.dll boost_thread-vc90-mt-gd-1_39.dll boost_unit_test_framework-vc90-mt-gd-1_39.dll qpidclientd.dll qpidcommond.dll qpidtypesd.dll or if running a release build: Apache.Qpid.Channel.dll Apache.Qpid.Interop.dll boost_date_time-vc90-mt-1_39.dll boost_filesystem-vc90-mt-1_39.dll boost_program_options-vc90-mt-1_39.dll boost_regex-vc90-mt-1_39.dll boost_system-vc90-mt-1_39.dll boost_thread-vc90-mt-1_39.dll boost_unit_test_framework-vc90-mt-1_39.dll qpidclient.dll qpidcommon.dll qpidtypes.dll qpidxarm.dll Cliff - 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: Installer which includes support for Persistence and WCF?
Hi Adam, In case it helps, note that the documentation in 0.7 for the WCF client also applies for the 0.6 version, with the exception of the section on security (SSL and SASL plain, new for 0.7). See http://qpid.apache.org/books/0.7/Programming-In-Apache-Qpid/html/ch04.html. Cliff On Tue, Nov 23, 2010 at 9:35 PM, adam_j_bradley adam_j_brad...@yahoo.com wrote: I'll run off and try now, thanks! Sincerely, Adam -- View this message in context: http://apache-qpid-developers.2158895.n2.nabble.com/Q-Installer-which-includes-support-for-Persistence-and-WCF-tp5768745p5769280.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - 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: Build Windows Broker without SSL
In CMake, there is a checkbox labeled BUILD_SSL that is selected by default. Presumably deselecting that and rebuilding (i.e. full clean and regenerate visual studio project files) should do it. I've never tried it though... Cliff On Thu, Nov 25, 2010 at 4:37 AM, Daniel Sack daniel.s...@techtalk.at wrote: Hi, Is it possible to build the windows broker without ssl, how? Br, Daniel - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release RC3 as Qpid 0.8
[X ] Yes, release RC3 as Qpid 0.8 [ ] No, I have an issue which I'll discuss in a new thread. Cliff On Wed, Dec 1, 2010 at 6:27 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: As RC3 has now been out for a week without call for blocking changes to be made, it seems like it is time for a vote. If you haven't already got it, RC3 can now be found for download at: http://people.apache.org/~robbie/qpid/0.8/RC3/ It was produced from r1037942 of the 0.8-release-candidates branch. The output from running RAT across the 'full release' archive can be found at the following URL: http://people.apache.org/~robbie/qpid/0.8/0.8rc3_rat_output.txt The changes since RC2 were: - Updates to various RELEASE_NOTES files - Updates to/addition of various README files - Remove a few redundant or out of date scripts/README files from Java tree - Update to avoid error in the cpp hello_xml example - Make the ruby hello example executable - QPID-2914: python address parser doesn't recognize None - QPID-2947: update slf4j to allow using the Java client package out-of-the-box - QPID-2948: Generated API docs have extraneous macro names in method signatures - QPID-2950: stop incorrectly logging an expected exception during DerbyMessageStore closure The rules for release voting are summarised as follows: based on majority approval but officially only that requires three +1 votes be cast in order to release, and it is not possible to veto a release. The process is covered at: http://www.apache.org/foundation/voting.html#ReleaseVotes This vote will close at 3pm GMT on Saturday 4th December 2010 (i.e. 72.5 hrs from now), after which I will tally the votes. Please indicate your response by replying to this email either with a '+1, 0, -1' type answer, or by checking a box in the below options: [ ] Yes, release RC3 as Qpid 0.8 [ ] No, I have an issue which I'll discuss in a new thread. Thanks, Robbie - 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: QPID-3199: Candidate for 0.10?
Gordon Sim wrote in the JIRA: fwiw: I see no risk in including this in 0.10 providing there is still time to do so. +1 Cliff On Mon, Apr 11, 2011 at 2:50 PM, Andrew Stitcher astitc...@redhat.com wrote: This is a potentially bad bug that would be hard to find if we ran into it. Technically it's not a regression so it shouldn't really be a blocker, however I feel it would be pretty hard to diagnose the symptoms of this bug and the fix seems self evidently safe (to me) so I'd like to include it in 0.10. Especially if we have to respin. Andrew - 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: [VOTE] Release 0.10
+1 Cliff On Thu, Apr 14, 2011 at 7:39 AM, Justin Ross jr...@redhat.com wrote: Hello, everyone. The blocker issue raised earlier this week has been resolved. There's more information, including release notes, at the release page[1]. The proposed final distribution of Qpid 0.10 is available from the link below. It's from revision 1091571 of the 0.10 branch. http://people.apache.org/~astitcher/dist/qpid-0.10/ Andrew has graciously generated and signed this distro. It therefore meets the requirements for a vote. If you favor releasing this distribution as Qpid 0.10, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. Thanks, Justin --- [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release - 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: [VOTE] Subversion to JIRA integration
QPID: Yes [ X ] No [ ] PROTON: Yes [ X ] No [ ] Cliff - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release 0.22 RC6 as 0.22 final
+1 On Sun, May 26, 2013 at 3:35 AM, Justin Ross jr...@apache.org wrote: RC6 contains the proposed final bits for Qpid 0.22. If you favor making the RC6 bits into our official release, vote +1. If you have reason to believe RC6 is not ready for release, vote -1. Thanks! Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Replace the Qpid website
[X] Yes, replace the existing site with the proposed site Cliff - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Remove autotools build for C++ build
[X] * When 0.25 opens after the 0.24 beta branch remove the C++ Cliff - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 12275: Platform neutral helper functions.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12275/ --- Review request for qpid, Andrew Stitcher, Kenneth Giusti, and Rafael Schloming. Bugs: proton-348 https://issues.apache.org/jira/browse/proton-348 Repository: qpid Description --- This patch tries to minimize the impact of incorporating platform neutral code into the examples and the native C++ tests. I dislike the thought of dragging around a compatibility library that needs to be linked to some examples and not others. I am also not keen to have the qpid-proton library expose non-core functionality that users start using in real code and expect to be around for all time. As a further wrinkle, we may wish to distribute examples with Visual Studio projects to Windows users without the benefit of CMake infrastructure. The implication being that some platform magic that works in the main build courtesy of CMake may need to be implemented differently. The proposed patch is not particularly pretty, but hopefully leaves light footprints when the helper functions are needed. The code needs to be included exactly once per executable when needed. A portable pragma weak directive, if it existed, could have made this simpler. * Usage for a single compilation unit: * * #include pncompat/misc_funcs.i * * Usage for multiple combined compilation units: chose one to include * pncompat/misc_funcs.i as above and in each other unit needing the * definitions use * * #include pncompat/misc_defs.h The include/pncompat directory is placed under trunk/examples since you can't build the examples without it and the examples might be packaged separately. However the tests and even proton.c can find them when they are normally built. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/internal/LICENSE PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/internal/getopt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/internal/getopt.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/misc_defs.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/misc_funcs.i PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/recv.c 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/send.c 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/object.h 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/getopt.h 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/LICENSE 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.h 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.c 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/tests/tools/apps/c/msgr-common.h 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/tests/tools/apps/c/msgr-common.c 1499652 Diff: https://reviews.apache.org/r/12275/diff/ Testing --- windows, rhel6 Thanks, Cliff Jansen
Re: Review Request 12275: Platform neutral helper functions.
On July 5, 2013, 2:50 p.m., Kenneth Giusti wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/internal/getopt.h, line 15 https://reviews.apache.org/r/12275/diff/1/?file=318334#file318334line15 I suspect that this condition conflicts with the ASL license. It is certainly more restrictive than the ASL. I'm not a lawyer, though. But as a layman, this seems like it would require all binary copies of proton to have to reproduce this license (how? via a text display? or include a text file?) Kenneth Giusti wrote: Maybe the solution is to include this license in a top-level NOTICE file? The ASL requires all derivative works (including binaries) to include the NOTICE file if present. Again, IANAL My recollection is that this license was on the ASL approved list (straight BSD and that's why we chose it), note that the license file is just being moved in the tree. The only platform that would ship it in binary form would be Windows. I don't know if msrg-send is to be shipped in binary form or just built on a test system, the examples shouldn't be precompiled. That leaves proton.c and I think Rafi wanted to retire it. Perhaps I should raise a JIRA to track windows packaging for this issue? - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12275/#review22782 --- On July 5, 2013, 6:17 a.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12275/ --- (Updated July 5, 2013, 6:17 a.m.) Review request for qpid, Andrew Stitcher, Kenneth Giusti, and Rafael Schloming. Bugs: proton-348 https://issues.apache.org/jira/browse/proton-348 Repository: qpid Description --- This patch tries to minimize the impact of incorporating platform neutral code into the examples and the native C++ tests. I dislike the thought of dragging around a compatibility library that needs to be linked to some examples and not others. I am also not keen to have the qpid-proton library expose non-core functionality that users start using in real code and expect to be around for all time. As a further wrinkle, we may wish to distribute examples with Visual Studio projects to Windows users without the benefit of CMake infrastructure. The implication being that some platform magic that works in the main build courtesy of CMake may need to be implemented differently. The proposed patch is not particularly pretty, but hopefully leaves light footprints when the helper functions are needed. The code needs to be included exactly once per executable when needed. A portable pragma weak directive, if it existed, could have made this simpler. * Usage for a single compilation unit: * * #include pncompat/misc_funcs.i * * Usage for multiple combined compilation units: chose one to include * pncompat/misc_funcs.i as above and in each other unit needing the * definitions use * * #include pncompat/misc_defs.h The include/pncompat directory is placed under trunk/examples since you can't build the examples without it and the examples might be packaged separately. However the tests and even proton.c can find them when they are normally built. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/internal/LICENSE PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/internal/getopt.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/internal/getopt.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/misc_defs.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/include/pncompat/misc_funcs.i PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/recv.c 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/send.c 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/object.h 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/getopt.h 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/LICENSE 1499652 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.h 1499652 http://svn.apache.org/repos/asf/qpid/proton
Review Request 10363: fix for non C99 compliant Windows functions
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10363/ --- Review request for qpid, Andrew Stitcher and Rafael Schloming. Bugs: proton-212 https://issues.apache.org/jira/browse/proton-212 Repository: qpid Description --- Provides wrapper functions for sprintf and vsprintf to do the right thing on overflow and argument checking. Despite the same names the Windows version only provides the same result in the sunny day scenario. Also includes cmake enforcement via a post build step to verify the qpid-proton library doesn't inadvertently use the non-wrapped versions. The first try checked for the symbols in the dll, but (some versions of) Visual Studio can insert vsnprintf callouts in the dll support runtime. This version checks each foo.obj. Sorry about the stray tariling whitespace. I'll fix that. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/error.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/object/object.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.h 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/WindowsC99CheckDef.cmake PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/WindowsC99SymbolCheck.py PRE-CREATION Diff: https://reviews.apache.org/r/10363/diff/ Testing --- windows and rhel 6 Thanks, Cliff Jansen
Re: Review Request 10363: fix for non C99 compliant Windows functions
On July 12, 2013, 1:43 p.m., Chug Rolke wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/WindowsC99SymbolCheck.py, line 46 https://reviews.apache.org/r/10363/diff/2/?file=320710#file320710line46 Is dumpbin automatically added to the path by the build process or must one run this with Visual Studio tools in the path from the start? There is no path setup required. Regardless of whether you launch the gui or use devenv, if the MS build tool can find the compiler it can also find dumpbin. cmake itself never invokes the python script and dumpbin. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10363/#review23086 --- On July 12, 2013, 12:20 a.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10363/ --- (Updated July 12, 2013, 12:20 a.m.) Review request for qpid, Andrew Stitcher and Rafael Schloming. Bugs: proton-212 https://issues.apache.org/jira/browse/proton-212 Repository: qpid Description --- Provides wrapper functions for sprintf and vsprintf to do the right thing on overflow and argument checking. Despite the same names the Windows version only provides the same result in the sunny day scenario. Also includes cmake enforcement via a post build step to verify the qpid-proton library doesn't inadvertently use the non-wrapped versions. The first try checked for the symbols in the dll, but (some versions of) Visual Studio can insert vsnprintf callouts in the dll support runtime. This version checks each foo.obj. Sorry about the stray tariling whitespace. I'll fix that. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/engine/engine.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/error.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/object/object.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.h 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/platform.c 1502397 http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/WindowsC99CheckDef.cmake PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/WindowsC99SymbolCheck.py PRE-CREATION Diff: https://reviews.apache.org/r/10363/diff/ Testing --- windows and rhel 6 Thanks, Cliff Jansen
Re: Request for inclusion in 0.24 - windows installation fixes
These patches look good. I am in favour. On Thu, Aug 1, 2013 at 11:07 AM, Chuck Rolke cro...@redhat.com wrote: The following are all small, windows, installation-related fixes: QPID-5017: WinSDK build leaves release executables stranded in \bin directory http://svn.apache.org/r1509016 QPID-5027: Windows examples installed to wrong directory http://svn.apache.org/r1508866 QPID-5028: Qmf2 examples install script error http://svn.apache.org/r1508967 QPID-5032: Windows install LICENSE and NOTICE files have moved http://svn.apache.org/r1509004 QPID-5034: WinSDK README contains stale web site URL http://svn.apache.org/r1509311 In addition to this flurry of fixes was QPID-5029: WinSDK handles removed components but that happened after the 0.24 branch point and so is not a part of this request. -Chuck - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 14408: Messaging example hello_world core dumps when given a bad connection option
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14408/#review26524 --- Ship it! - Cliff Jansen On Sept. 30, 2013, 6:56 p.m., Chug Rolke wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14408/ --- (Updated Sept. 30, 2013, 6:56 p.m.) Review request for qpid and Gordon Sim. Bugs: QPID-5196 https://issues.apache.org/jira/browse/QPID-5196 Repository: qpid Description --- If a misspelled connection option is present on the command line then hello_world.cpp throws. Since the connection constructor is outside the try-catch block the program core dumps. The fix is to move the connection constructor inside the try-catch. Diffs - trunk/qpid/cpp/examples/messaging/hello_world.cpp 1527685 Diff: https://reviews.apache.org/r/14408/diff/ Testing --- There is no test for hello_world. With this fix both linux and windows versions print useful error messages and exit with error status. Thanks, Chug Rolke
Review Request 14570: Revised patch for client SSL certificates on Windows
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14570/ --- Review request for qpid and Andrew Stitcher. Bugs: QPID-3914 https://issues.apache.org/jira/browse/QPID-3914 Repository: qpid Description --- This patch borrows much from the last submitted patch but takes it in a different direction. Wherever possible, similarities between Windows certificate handling and NSS certificate handling are emphasized and differences de-emphasized. For example, certificates are now specified by their Friendly Name which most closely resembles the NSS nickname. The password is now provided in a file rather than from the command line or environment variable (and using the same specifier). However, some differences cannot be glossed over. Microsoft's SChannel implementation severely restricts where the final trust for a server certificate may reside (either the self-signed certificate itself or the trusted root CA of a certificate chain). It cannot be specified from an arbitrary Windows store or file based store (unlike a client certificate). To make things worse, the tools available to install/manage certificates vary between Windows versions or the presence of optional packages not regularly installed on all target machines. So I am certainly sympathetic to the desire to provide a mechanism to simplify the installation of the server certificate. Nevertheless, I removed that capability for several reasons: Andrew's original objection is still valid regarding qpid intruding on normal system administration of certificates; the previous patch is too specific (handles self signed certs but not certificate chains); the solution is at the mercy of the user who may click in the wrong spot no matter how well he may be coaxed. As best I can tell, this is nuisance for anyone needing SSL validation of their product. Some combination of certutil.exe, certmgr.msc, or powershell wizardry is used but with a fallback description of how to import the certificate by browsing to the certificate in MMC or Windows Explorer. This patch also provides a revised store opening mechanism that doesn't create stray stores if the user species the name incorrectly. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/SSL 1530859 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/CMakeLists.txt 1530859 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/SaslFactory.cpp 1530859 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/SslConnector.cpp 1530859 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/util.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/util.cpp PRE-CREATION Diff: https://reviews.apache.org/r/14570/diff/ Testing --- Windows 7: Personal/MY store, user created store, pkcs#12 file. Self signed, chained certs. Thanks, Cliff Jansen
Re: Review Request 14570: Revised patch for client SSL certificates on Windows
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14570/ --- (Updated Oct. 17, 2013, 4:05 p.m.) Review request for qpid and Andrew Stitcher. Changes --- This updated patch tries to incorporate all the suggestions in the first review. Bugs: QPID-3914 https://issues.apache.org/jira/browse/QPID-3914 Repository: qpid Description --- This patch borrows much from the last submitted patch but takes it in a different direction. Wherever possible, similarities between Windows certificate handling and NSS certificate handling are emphasized and differences de-emphasized. For example, certificates are now specified by their Friendly Name which most closely resembles the NSS nickname. The password is now provided in a file rather than from the command line or environment variable (and using the same specifier). However, some differences cannot be glossed over. Microsoft's SChannel implementation severely restricts where the final trust for a server certificate may reside (either the self-signed certificate itself or the trusted root CA of a certificate chain). It cannot be specified from an arbitrary Windows store or file based store (unlike a client certificate). To make things worse, the tools available to install/manage certificates vary between Windows versions or the presence of optional packages not regularly installed on all target machines. So I am certainly sympathetic to the desire to provide a mechanism to simplify the installation of the server certificate. Nevertheless, I removed that capability for several reasons: Andrew's original objection is still valid regarding qpid intruding on normal system administration of certificates; the previous patch is too specific (handles self signed certs but not certificate chains); the solution is at the mercy of the user who may click in the wrong spot no matter how well he may be coaxed. As best I can tell, this is nuisance for anyone needing SSL validation of their product. Some combination of certutil.exe, certmgr.msc, or powershell wizardry is used but with a fallback description of how to import the certificate by browsing to the certificate in MMC or Windows Explorer. This patch also provides a revised store opening mechanism that doesn't create stray stores if the user species the name incorrectly. Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/SSL 1533100 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/CMakeLists.txt 1533100 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/SaslFactory.cpp 1533100 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/SslConnector.cpp 1533100 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/util.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/util.cpp PRE-CREATION Diff: https://reviews.apache.org/r/14570/diff/ Testing --- Windows 7: Personal/MY store, user created store, pkcs#12 file. Self signed, chained certs. Thanks, Cliff Jansen
Review Request 15854: Windows SSL client certificates should not be tied to SASL EXTERNAL
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15854/ --- Review request for qpid, Andrew Stitcher, Chug Rolke, and Steve Huston. Bugs: QPID-5375 https://issues.apache.org/jira/browse/QPID-5375 Repository: qpid Description --- Based on the JIRA, this patch decouples the certificate loading from the SASL mechanism and remembers any problem with client certificate loading in case there is a later failure in the connection attributable to the lack of a client certificate. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/client/windows/SslConnector.cpp 1545560 Diff: https://reviews.apache.org/r/15854/diff/ Testing --- Windows 7 client versus RHEL 6 client, broker requiring or not requiring client certificates, SASL mechanisms EXTERNAL, PLAIN, ANONYMOUS. Thanks, Cliff Jansen
Review Request 17418: va_arg processing on Visual Studio 64bit compiler
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17418/ --- Review request for qpid, Chug Rolke and Rafael Schloming. Bugs: PROTON-488 https://issues.apache.org/jira/browse/PROTON-488 Repository: qpid Description --- See the parent Jira comment description of the bug with the first patch. This patch achieves the same thing but by forcing all 'z' encodings to be passed as a single pn_bytes_t struct and retrieved as a single pn_bytes_t struct via va_arg(). The other patch is a single line but this one is fairly isolated too. I slightly prefer this one because a pn_bytes_t struct is used going the other way (in pn_data_vscan, but by a pointer to the struct on the stack). I don't see a performance difference either way. We just have to stick to one paradigm everywhere in the code, either struct in and out, or separate size_t and char* in and out. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 1561193 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c 1561193 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sasl/sasl.c 1561193 Diff: https://reviews.apache.org/r/17418/diff/ Testing --- 64 bit, windows and linux Thanks, Cliff Jansen
Review Request 17521: ssl-cert-name connection argument processing in AMQP 1.0.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17521/ --- Review request for qpid. Bugs: QPID-5524 https://issues.apache.org/jira/browse/QPID-5524 Repository: qpid Description --- Same logic as the 0-10 client once the connection option is located. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/messaging/amqp/SslTransport.cpp 1562658 Diff: https://reviews.apache.org/r/17521/diff/ Testing --- Linux. Thanks, Cliff Jansen
Re: Review Request 17592: QPID-5531 [C++ broker] Set timeout for every DTX transaction
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17592/#review33415 --- This builds fine on Windows. By inspection the code changes look correct to me. Sadly, I was not able to get ctest to cooperate on my system to run simplest tests, let alone the CLFS-specific tests. However, I believe the patch is useful and does no harm on the Windows side. - Cliff Jansen On Feb. 1, 2014, 2:47 p.m., Pavel Moravec wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17592/ --- (Updated Feb. 1, 2014, 2:47 p.m.) Review request for qpid, Chug Rolke, Cliff Jansen, Kim van der Riet, and Steve Huston. Bugs: QPID-5531 https://issues.apache.org/jira/browse/QPID-5531 Repository: qpid Description --- If a rogue external Transaction Manager forgets to commit/rollback a prepared DTX, Tpl store keeps an orphaned enqueue record. To prevent it, every DTX transaction should have a default timeout after that the broker automatically aborts the transaction. QPID-5531 adds broker option dtx-default-timeout for that. My concerns for review: - is 3600 seconds as default value proper? Isn't it too high? - ms-sql and/or ms-clfs store part of the patch (recoverTransaction method) has not been even compiled Diffs - /trunk/qpid/cpp/src/qpid/broker/Broker.h 1563386 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1563386 /trunk/qpid/cpp/src/qpid/broker/DtxManager.h 1563386 /trunk/qpid/cpp/src/qpid/broker/DtxManager.cpp 1563386 /trunk/qpid/cpp/src/tests/legacystore/OrderingTest.cpp 1563386 /trunk/qpid/cpp/src/tests/legacystore/SimpleTest.cpp 1563386 /trunk/qpid/cpp/src/tests/legacystore/TransactionalTest.cpp 1563386 /trunk/qpid/cpp/src/tests/legacystore/TwoPhaseCommitTest.cpp 1563386 Diff: https://reviews.apache.org/r/17592/diff/ Testing --- Thanks, Pavel Moravec
Re: Review Request 17521: ssl-cert-name connection argument processing in AMQP 1.0.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17521/ --- (Updated Feb. 4, 2014, 8:41 a.m.) Review request for qpid. Changes --- Changed as suggested. Bugs: QPID-5524 https://issues.apache.org/jira/browse/QPID-5524 Repository: qpid Description --- Same logic as the 0-10 client once the connection option is located. Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/messaging/amqp/ConnectionContext.h 1564226 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp 1564226 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/messaging/amqp/SslTransport.cpp 1564226 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/messaging/amqp/TransportContext.h 1564226 Diff: https://reviews.apache.org/r/17521/diff/ Testing --- Linux. Thanks, Cliff Jansen
Review Request 17857: Windows SSL client support for AMQP 1.0
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17857/ --- Review request for qpid, Andrew Stitcher, Chug Rolke, and Steve Huston. Bugs: QPID-5549 https://issues.apache.org/jira/browse/QPID-5549 Repository: qpid Description --- This implements the same thin shim mechanism used by the AMQP 0-10 implementation. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/amqp.cmake 1565749 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/messaging/amqp/TcpTransport.h 1565749 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/messaging/amqp/windows/SslTransport.cpp PRE-CREATION Diff: https://reviews.apache.org/r/17857/diff/ Testing --- Windows 32 and 64 bit Thanks, Cliff Jansen
Review Request 18893: Extending PROTON-525 to Windows platforms (selectors)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18893/ --- Review request for qpid and Rafael Schloming. Bugs: PROTON-529 https://issues.apache.org/jira/browse/PROTON-529 Repository: qpid Description --- This patch is a minimal port of the existing Windows code base to incorporate the refactored IO and selector mechanism of PROTON-525. It does not incorporate any changes to how the sockets and pipes operate but some thought was given to accommodating completion ports right after 0.7. Although there was a clear attempt in PROTON-525 to provide rich abstractions that would allow Posix and Windows implementations to optimize their low level IO for each OS, awkwardness remains. Windows sockets are outside the regular IO system, for a long time a bolt on third party implementation. For Posix, they are an extension of regular file descriptors and things like close(socket_fd) makes sense. This short term Windows fix hides the above. Because the sockets only select() call in the Windows api was the easiest to work with initially, it was necessary to fake a socket-based pipe for the control port. Since everything is sockets anyway, we can mix the control fd with other fds. If we used Windows pipes, we couldn't. But we definitely don't want to use select() long term and we may not want to use fake socket pipes, or even any pipes at all. Note that the pipe control mechanism is not needed on Windows if you use completion ports and is not used in the Qpid C++ Windows implementation. Even though it is probable that the existing new api could be made to work without penalizing Windows significantly, I would prefer to stop mingling sockets with non socket io objects in proton. Perhaps some interrupt interface could be added to the selector, implemented with pipes on (some) Posix systems and optimized in other ways on other platforms. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/cproton.i 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/io.h 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/selectable.h 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger/messenger.c 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/posix/driver.c 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/posix/io.c 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/selectable.h 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/selectable.c 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/ssl-internal.h 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/ssl_stub.c 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/driver.c 1573021 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/io.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/selector.c PRE-CREATION Diff: https://reviews.apache.org/r/18893/diff/ Testing --- rhel 6, Win7, all 64 bit for now Thanks, Cliff Jansen
Re: Review Request 18893: Extending PROTON-525 to Windows platforms (selectors)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18893/ --- (Updated March 10, 2014, 4:04 p.m.) Review request for qpid and Rafael Schloming. Changes --- fixes 1,2, and 4. driver.c does not contain any use of selectors. So I will have to rework it to do that before it can be OS agnostic. I'm not sure that will be ready later today for the first RC. I'm also unsure how to test the change now that messenger doesn't use it. Bugs: PROTON-529 https://issues.apache.org/jira/browse/PROTON-529 Repository: qpid Description --- This patch is a minimal port of the existing Windows code base to incorporate the refactored IO and selector mechanism of PROTON-525. It does not incorporate any changes to how the sockets and pipes operate but some thought was given to accommodating completion ports right after 0.7. Although there was a clear attempt in PROTON-525 to provide rich abstractions that would allow Posix and Windows implementations to optimize their low level IO for each OS, awkwardness remains. Windows sockets are outside the regular IO system, for a long time a bolt on third party implementation. For Posix, they are an extension of regular file descriptors and things like close(socket_fd) makes sense. This short term Windows fix hides the above. Because the sockets only select() call in the Windows api was the easiest to work with initially, it was necessary to fake a socket-based pipe for the control port. Since everything is sockets anyway, we can mix the control fd with other fds. If we used Windows pipes, we couldn't. But we definitely don't want to use select() long term and we may not want to use fake socket pipes, or even any pipes at all. Note that the pipe control mechanism is not needed on Windows if you use completion ports and is not used in the Qpid C++ Windows implementation. Even though it is probable that the existing new api could be made to work without penalizing Windows significantly, I would prefer to stop mingling sockets with non socket io objects in proton. Perhaps some interrupt interface could be added to the selector, implemented with pipes on (some) Posix systems and optimized in other ways on other platforms. Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/cproton.i 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/io.h 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/selectable.h 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger/messenger.c 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/posix/driver.c 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/posix/io.c 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/selectable.h 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/selectable.c 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/ssl-internal.h 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/ssl/ssl_stub.c 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/driver.c 1575326 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/io.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/selector.c PRE-CREATION Diff: https://reviews.apache.org/r/18893/diff/ Testing --- rhel 6, Win7, all 64 bit for now Thanks, Cliff Jansen
