[jira] [Created] (PROTON-492) proton-c: Messenger should allow custom link name to be specificied
Dominic Evans created PROTON-492: Summary: proton-c: Messenger should allow custom link name to be specificied Key: PROTON-492 URL: https://issues.apache.org/jira/browse/PROTON-492 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.6 Reporter: Dominic Evans Priority: Minor # Abstract The proton-c messenger currently enforces hard-coded link names on attachment. # Description In certain scenarios it would be useful to be able to specify an explicit link-name to use for the attach when performing a subscribe (and possible also associated with a message address), so it would be useful if Messenger exposed a way of setting these. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Protocol detection
Hi Saggi Sounds like you need to handle all the socket i/o directly, rather than having Proton do it under the covers, right? To do this, you'll need to avoid using the Driver and Connector and Listener classes from the Python binding - these classes perform all socket management and I/O, for those apps which want to let proton handle it. What you'll need to do is use the proton Transport class to pass network data into and out of the Proton protocol Engine. There are no callbacks - you'll have to call into Proton, sending it bytes you've pulled from the network, and asking Proton if it has any data to send. You then have to perform the socket I/O yourself. I've written some python code that does exactly that - you might find it a useful example. See: https://github.com/kgiusti/fusion And, specifically on how to do socket I/O, take a look here: https://github.com/kgiusti/fusion/blob/master/python/sockets.py The connection in the read/write_socket* methods in sockets.py is an instance of the Connection object from here: https://github.com/kgiusti/fusion/blob/master/python/connection.py Which contains an instance of the Proton::Transport. You can see how I use the Transport API to feed/read bytes to/from Proton. Let me know if that helps, Also, here's a couple of docs describing Proton's architecture and the engine model, if you're interested. https://cwiki.apache.org/confluence/display/qpid/Protocol+Engines https://cwiki.apache.org/confluence/display/qpid/Proton+Architecture - Original Message - From: Saggi Mizrahi smizr...@redhat.com To: proton@qpid.apache.org Cc: Piotr Kliczewski pklic...@redhat.com, Barak Azulay bazu...@redhat.com Sent: Wednesday, January 22, 2014 7:03:37 AM Subject: Protocol detection Hi, I'm from the VDSM project which is part of oVirt. We are in the process of adding multiple protocol support one of which is AMQP 1.0 though the proton library. We want to keep only requiring one port so our solution is to peek at the stream, detect the protocol and then pass it to the proper protocol implementation. So, in order to support SSL we have to do the SSL negotiation ourselves and pass read\write callbacks since we keep the SSL state of the session. We've been trying to get this to work with the proton-python bindings but there doesn't seem to be a way to pass our own read\write callbacks. Is there something were missing, is it something that's even planned\wanted? Thanks -- -K
Re: Finding available channels on a pn_connection_t
Hi Alan, I think you're correct. I don't think there is any attempt to limit the number of channels used. I'll add some API to make the max number of channels available. --Rafael On Wed, Jan 22, 2014 at 4:38 PM, Alan Conway acon...@redhat.com wrote: I'm trying to solve a problem for HA on the Qpid C++ broker. I need to figure out, for a given connection, will an attempt to open another channel at the other end exceed the channel-max for this connection? To do that I figure I need to know the number of currently open channels (easy) and the negotiated channel-max for the connection. How can I find that? Based on a novice reading of transport.c, it looks like the channel-max field of the open performative is ignored. Am I reading this wrong? If not, what is proton assuming - that it can always open 64k channels on any connection? This would violate the limit imposed by the Qpid C++ broker and client of 32k channels (I don't know why they impose that limit but they do.) Any pointers much appreciated! Alan.
[jira] [Updated] (PROTON-417) Remove/optionalize bouncycastle dependency
[ https://issues.apache.org/jira/browse/PROTON-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-417: --- Fix Version/s: (was: 0.6) 0.7 Remove/optionalize bouncycastle dependency -- Key: PROTON-417 URL: https://issues.apache.org/jira/browse/PROTON-417 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rafael H. Schloming Fix For: 0.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora
[ https://issues.apache.org/jira/browse/PROTON-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-287: --- Fix Version/s: (was: 0.6) 0.7 Fix Qpid Proton-C build with MinGW on Fedora Key: PROTON-287 URL: https://issues.apache.org/jira/browse/PROTON-287 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.4 Environment: mingw32-gcc-4.7.2-7.fc18.x86_64 Reporter: Robin Lee Assignee: Cliff Jansen Labels: build, patch Fix For: 0.7 This is my first submit on ASF JIRA. Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided: Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff Description: %z format specifier is not provided by MSVCRT, use MinGW version of *printf to get it. Otherwise build failed with: proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character 'z' in format [-Werror=format] Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff Description: Libraries and header files should be written in small cases, otherwise build failed in cross build environment of Unix-like platforms: proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file or directory Patch 3: http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build failed with: proton-c/src/windows/driver.c:785:11: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Patch 4: http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff Description: Commented unimplemented functions. Otherwise build failed with proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared 'static' but never defined [-Werror=unused-function] Patch 5: http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff Description: 1. ID is not used, build failed with ../wincompat/internal/getopt.c:43:20: error: 'ID' defined but not used [-Werror=unused-variable] 2. Corrected getopt signiture, otherwise build failed with proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' but argument is of type 'const char *' 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so #include wincompat/getopt.h in .c files instead of .h, otherwise build failed with multiple definitions. Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff Description: WIN32 macro is not defined with -std=c99 but defined with -std=gnu99. Use _WIN32 macro in all places. Built on Fedora and examples of recv and send are tested on Windows 7. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-476) Support a user-context for SASL and SSL objects.
[ https://issues.apache.org/jira/browse/PROTON-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-476: --- Fix Version/s: (was: 0.6) 0.7 Support a user-context for SASL and SSL objects. Key: PROTON-476 URL: https://issues.apache.org/jira/browse/PROTON-476 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Fix For: 0.7 For consistency and convenience, I'd like to add an API that would allow an application-defined context be associated with the pn_sasl_t, pn_ssl_domain_t, and pn_ssl_t objects. This api would follow the convention used by other proton classes (eg, pn_connection_get_context(), pn_connection_set_context()). ex: void *pn_sasl_get_context(pn_sasl_t); void pn_sasl_set_context(pn_sasl_t *, void *context); -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-439) Support for dynamic reply-to address in Messenger
[ https://issues.apache.org/jira/browse/PROTON-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-439: --- Fix Version/s: (was: 0.6) 0.7 Support for dynamic reply-to address in Messenger - Key: PROTON-439 URL: https://issues.apache.org/jira/browse/PROTON-439 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ted Ross Assignee: Rafael H. Schloming Fix For: 0.7 Messenger has no support for creating dynamic receivers for reply-to addresses. Please refer to the following email thread for prior discussion on the topic. http://qpid.2158936.n2.nabble.com/Proton-Messenger-and-the-Request-Response-pattern-tp7586653.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-462) Documentation: Add doxygen overview file for Proton C API
[ https://issues.apache.org/jira/browse/PROTON-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-462: --- Fix Version/s: (was: 0.6) 0.7 Documentation: Add doxygen overview file for Proton C API - Key: PROTON-462 URL: https://issues.apache.org/jira/browse/PROTON-462 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Fix For: 0.7 If possible, have the web page link to the *public header files* as the start page - that's were the meat of the API documentation exists. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-445) Binding installation ignores prefix
[ https://issues.apache.org/jira/browse/PROTON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-445: --- Fix Version/s: (was: 0.6) 0.7 Binding installation ignores prefix --- Key: PROTON-445 URL: https://issues.apache.org/jira/browse/PROTON-445 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Justin Ross Assignee: Darryl L. Pierce Fix For: 0.7 Attachments: what-a-mess.txt It allows you *prepend* to the install prefix, but it gives you no way afaict to actually change the prefix. This is the opposite of nice. If you set a prefix for your build *and* you try to get your bindings slotted in with them, via DESTDIR, you get this: # cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace /var/tmp/jross/baker/proton/source # make install DESTDIR=/opt/myplace /opt/myplace/usr/lib/python/*python files* /opt/myplace/opt/myplace/lib/*c files* ^^ Note /opt/myplace/opt/myplace, the first from DESTDIR, the second from CMAKE_INSTALL_PREFIX What it is doing now is simply abuse of DESTDIR. DESTDIR is intended to be a mechanism for staged installs (packaging systems use this), and it cannot function correctly as an override for prefix. http://www.gnu.org/prep/standards/html_node/DESTDIR.html My proposed solution to this is to stop this madness: make the binding install honor CMAKE_INSTALL_PREFIX. Let the developer be responsible for choosing the right location for his or her distribution. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-494) remove JNI binding
[ https://issues.apache.org/jira/browse/PROTON-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880120#comment-13880120 ] ASF subversion and git services commented on PROTON-494: Commit 1560765 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1560765 ] PROTON-494: removed JNI binding remove JNI binding -- Key: PROTON-494 URL: https://issues.apache.org/jira/browse/PROTON-494 Project: Qpid Proton Issue Type: Task Reporter: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PROTON-495) fix proton constructors to not be so brittle
Rafael H. Schloming created PROTON-495: -- Summary: fix proton constructors to not be so brittle Key: PROTON-495 URL: https://issues.apache.org/jira/browse/PROTON-495 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rafael H. Schloming Currently it is ridiculously easy to get exceptions like the one below. Given that we are providing an API, not an SPI, this should never be able to happen. Caused by: java.lang.IllegalStateException: Can't find service loader for org.apache.qpid.proton.messenger.MessengerFactory for implementation type ANY at org.apache.qpid.proton.ProtonFactoryLoader.loadFactory(ProtonFactoryLoader.java:107) at org.apache.qpid.proton.ProtonFactoryLoader.loadFactory(ProtonFactoryLoader.java:84) at org.apache.qpid.proton.Proton.clinit(Proton.java:55) ... 84 more java.lang.ExceptionInInitializerError: java.lang.ExceptionInInitializerError -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Protocol detection
On Thu, Jan 23, 2014 at 12:07 PM, Barak Azulay bazu...@redhat.com wrote: Thanks ken, This looks very helpful - we will try it. In addition - who can we talk to about the java binding for qpid-proton (AMQP 1.0), What would you like to know? --Rafael
[jira] [Updated] (PROTON-200) Credit distribution by messenger is not balanced across all links
[ https://issues.apache.org/jira/browse/PROTON-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-200: --- Fix Version/s: (was: 0.7) 0.6 Credit distribution by messenger is not balanced across all links - Key: PROTON-200 URL: https://issues.apache.org/jira/browse/PROTON-200 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.6 Attachments: proton-200.patch, upstream-credit.patch The method used to distribute credit to receiving links may lead to starvation when the number of receiving links is the available credit. The distribution algorithm always starts with the same link - see messenger.c::pn_messenger_flow() -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PROTON-200) Credit distribution by messenger is not balanced across all links
[ https://issues.apache.org/jira/browse/PROTON-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-200. Resolution: Fixed Credit distribution by messenger is not balanced across all links - Key: PROTON-200 URL: https://issues.apache.org/jira/browse/PROTON-200 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.6 Attachments: proton-200.patch, upstream-credit.patch The method used to distribute credit to receiving links may lead to starvation when the number of receiving links is the available credit. The distribution algorithm always starts with the same link - see messenger.c::pn_messenger_flow() -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880309#comment-13880309 ] Chuck Rolke commented on PROTON-488: I never let cmake decide which compiler to use. Even with the x64 Win64 Command Prompt cmake is building a 32-bit solution. Try forcing a 64-bit solution with cmake -G Visual Studio 10 Win64 . Getting the correct solution generated by cmake makes changing properties (steps 3-6) unnecessary. Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
I can reproduce the problem even when using cmake as recommended. The problem is proton's fast and loose use of binary data in the codec. The assumption that a struct will be placed on the stack a certain way falls apart in 64bit Visual Studio, so that it is no longer OK to use either a single argument (pn_data_t struct) or two separate ones (a size_t and char*), depending on what's convenient at the time. The va_arg macro works very differently in 32bit versus 64bit in this case. I will have a work-around patch soon and will separately work an official fix through review board and PROTON-488 Cliff On Thu, Jan 23, 2014 at 12:15 PM, Chuck Rolke (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880309#comment-13880309 ] Chuck Rolke commented on PROTON-488: I never let cmake decide which compiler to use. Even with the x64 Win64 Command Prompt cmake is building a 32-bit solution. Try forcing a 64-bit solution with cmake -G Visual Studio 10 Win64 . Getting the correct solution generated by cmake makes changing properties (steps 3-6) unnecessary. Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
