[jira] [Created] (PROTON-491) proton-c: Messenger uses hard-coded link names of sender-xxx & receiver-xxx
Dominic Evans created PROTON-491: Summary: proton-c: Messenger uses hard-coded link names of sender-xxx & receiver-xxx Key: PROTON-491 URL: https://issues.apache.org/jira/browse/PROTON-491 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Dominic Evans # Abstract The qpid-proton 'messenger' implementation currently uses hard-coded receiver-xxx and sender-xxx link names for all attachments. # Description I believe the AMQP 1.0 spec says here that:- although client-ids do not need to be unique, the triplet of , and *is* guaranteed to be unique. http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp298752 However, the qpid-proton Messenger code seems to have all link-name's hard-coded to sender-xxx and receiver-xxx As an easyfix, I would suggest that by default the topicname part of the address should be appended to the link-name (instead of -xxx) e.g., amqp://localhost/topicName --> sender-topicName / receiver-topicName However, that would still cause a clash if the same messenger wanted to make two subscriptions to the same topic, so perhaps the Messenger implementation needs to track what link names it has allocated and ensure a unique name is assigned each time? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[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" > To: proton@qpid.apache.org > Cc: "Piotr Kliczewski" , "Barak Azulay" > > 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
[jira] [Assigned] (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:all-tabpanel ] Cliff Jansen reassigned PROTON-488: --- Assignee: Cliff Jansen > 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: 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 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] [Created] (PROTON-493) channel max is not exposed
Rafael H. Schloming created PROTON-493: -- Summary: channel max is not exposed Key: PROTON-493 URL: https://issues.apache.org/jira/browse/PROTON-493 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-453) OpenSSL libraries are not Valgrind clean
[ https://issues.apache.org/jira/browse/PROTON-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-453: --- Fix Version/s: (was: 0.6) 0.7 > OpenSSL libraries are not Valgrind clean > > > Key: PROTON-453 > URL: https://issues.apache.org/jira/browse/PROTON-453 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Trivial > Fix For: 0.7 > > > OpenSSL will trigger errors under Valgrind. This is expected, as OpenSSL > uses uninitialized memory to increase its randomness. > http://www.openssl.org/support/faq.html#PROG14 > These errors can be suppressed by using a Valgrind suppression file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-474) Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer
[ https://issues.apache.org/jira/browse/PROTON-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-474: --- Fix Version/s: (was: 0.6) 0.7 > Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer > --- > > Key: PROTON-474 > URL: https://issues.apache.org/jira/browse/PROTON-474 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.5 >Reporter: Timothy Bish > Fix For: 0.7 > > Attachments: JMSExpiration-patch.txt > > > The inbound message transformation of AMQP message to JMS message incorrectly > sets the JMSExpiration to message TTL which is defined in milliseconds while > the JMSExpiration value is a sum of the Message Timestamp and the producers > TTL. The transformation should probably map the message creation time + the > TTL to the setJMSExpiration method. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[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-343) Add a pluggable Proton logging layer
[ https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-343: --- Fix Version/s: (was: 0.6) 0.7 > Add a pluggable Proton logging layer > > > Key: PROTON-343 > URL: https://issues.apache.org/jira/browse/PROTON-343 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Reporter: Philip Harvey >Assignee: Philip Harvey > Fix For: 0.7 > > Attachments: > 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch > > > Applications that use Proton sometimes want Proton to produce logging. > Goals > > * Proton should provide a default logging implementation. > * It should be easy for Proton client code to provide custom logging > implementation, e.g. one that uses the same third party logging framework as > their application code. > * Proton should not have a compile-time dependency on a third party logging > framework > * Proton's log output is considered to be part of its public interface. > Therefore, in the spirit of Proton's cross-language consistency goals, this > output should be consistent between proton-c and proton-j. > * The goals that general-purpose logging frameworks try to meet - > performance, ease of use etc - also apply. -- 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-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.6) 0.7 > 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.7 > > 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] [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)
Re: Protocol detection
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), Thanks Barak Azulay - Original Message - > From: "Ken Giusti" > To: proton@qpid.apache.org, "Saggi Mizrahi" > Cc: "Piotr Kliczewski" , "Barak Azulay" > > Sent: Thursday, January 23, 2014 4:24:00 PM > Subject: 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" > > To: proton@qpid.apache.org > > Cc: "Piotr Kliczewski" , "Barak Azulay" > > > > 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 >
[jira] [Created] (PROTON-494) remove JNI binding
Rafael H. Schloming created PROTON-494: -- Summary: 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] [Commented] (PROTON-494) remove JNI binding
[ https://issues.apache.org/jira/browse/PROTON-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.(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 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-tabpanel&focusedCommentId=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) wrote: > > [ > https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
