Re: [doc] I will check these in on Friday the 4th...

Comments in-line below... A general question/comment: Is the single-threaded nature of this API clearly spelled out somewhere? There's a lot of the use of the "returns X associated with the most recent call to Y" pattern, which isn't multi-thread-friendly. Then, there are calls like pn_mes

Re: Proton 0.6 RC2

QPID-439 seems to have reverted in this RC. Here's my client code: self.M.route("amqp:/*", "amqp://%s/$1" % host) self.subscription = self.M.subscribe("amqp:/#") self.reply = self.subscription.address print "REPLY:", self.reply The output is: REPLY: None

Re: Proton 0.6 RC2

Digging further into this, I see that Messenger is providing the subscription and the address before the dynamic-attach handshake is completed. It was my understanding that one or both of those calls would block until the name was resolved. -Ted On 12/18/2013 05:25 PM, Ted Ross wrote: QPID

Re: Proton 0.6 RC2

Yes, it's fixed on trunk. Thanks! -Ted On 12/19/2013 05:52 AM, Rafael Schloming wrote: I believe I've fixed this on trunk. Let me know if you still see the problem there. --Rafael On Wed, Dec 18, 2013 at 5:44 PM, Ted Ross wrote: Digging further into this, I see that Me

Re: improving cross language maintainability

On 12/20/2013 01:49 PM, Rafael Schloming wrote: On Fri, Dec 20, 2013 at 11:43 AM, Fraser Adams < fraser.ad...@blueyonder.co.uk> wrote: I've been following this thread with interest and I guess that Rob's comment " However I think that would require us to be organised differently with a reco

Re: [VOTE]: Release Proton 0.6 RC3 as 0.6 final

+1, release RC3 as final. -Ted On 01/02/2014 02:17 PM, Rafael Schloming wrote: Hi Everyone, It looks like there haven't been any major issues reported so far with 0.6 RC3, so I guess it's about time to call for a formal vote. Source is here: http://people.apache.org/~rhs/qpid-proton-0.6

Re: engine API improvements

Both of these proposals sound like improvements to me. I'll point out one consideration that I've had to deal with in Dispatch. The Engine data structures are such that it can be used in a multi-threaded application as long as no two threads are handling the same connection at the same time.

Re: Qpid Proton messenger on 32 bit linux

I routinely run tests using Messenger in a 32-bit Linux environment and I've never had a problem with it. Are you building on a 64-bit machine or in a complete 32-bit environment? -Ted On 01/27/2014 03:43 PM, serega wrote: Does the messenger work on 32 bit linux? I build the 32 bit messenger

Re: Qpid Proton messenger on 32 bit linux

I haven't had a change to try it yet. I think we typically use "-m32 -march=i686" -Ted On 01/29/2014 09:56 AM, serega wrote: The attached example is a send.c slightly modified send.c example. It works in 64 bit environment, but crashe

Re: error when building proton

There's one other thing to be careful of... Once CMake determines that it's not there, it will not reconsider after you've installed the dependency. Make sure you delete your whole build directory and re-configure. -Ted On 02/05/2014 12:02 PM, Roberto Pagliari wrote: Hi Alan, I have uuid-d

Source/Target Question

I'm working on a feature for Dispatch Router that will allow it to intermediate between clients and brokers. This raises a question about how Proton Messenger handles targets and sources in links. Consider a subscriber using Messenger: from proton import Messenger M = Messenger()

Re: Source/Target Question

Based on a discussion with Gordon, I'm not going to use source vs. target to infer any intent on the part of the peer node. I am, however, still interested in the answer to the question. -Ted On 02/21/2014 03:02 PM, Ted Ross wrote: I'm working on a feature for Dispatch Router that

Re: Proton 0.7 RC1

I tested this RC standalone and against Dispatch trunk. Everything worked as I expected. One note on the README: I tested on a stripped down Fedora 20 image and I had to install two additional packages to those listed in the README: - rubygem-minitest - maven -Ted On 03/14/2014 04

Re: Anonymous Producers

You have the option of leaving the target of a producer link empty and putting the destination in the "to" field of each message sent on the link. -Ted On 03/20/2014 11:36 PM, Clebert Suconic wrote: A common JMS feature is to have a Producer being anonymous and define the address only when th

Re: new team working with AMQP and Apache Qpid Proton

Rob and team, Thanks for the introduction and welcome to the project. The mission of Qpid Proton is to encourage adoption of AMQP and to make it as easy as possible to integrate AMQP into anything and everything. As such, I think your goals are in alignment with the project's goals. I'll address

Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final

+1 On 04/22/2014 07:12 AM, Rafael Schloming wrote: > Hi Everyone, > > I haven't heard of any issues in RC4, so I'm going to put this to a formal > vote now: > > Source artifacts are here: > > - http://people.apache.org/~rhs/qpid-proton-0.7rc4/ > > Java binaries are here: > > - https://repo

Re: landing events branch

Another heads-up... I've updated dispatch-router to use the newly landed events in Proton. If you are building dispatch from source, you will need the latest Proton trunk. -Ted On 07/10/2014 12:41 PM, Rafael Schloming wrote: > Hi Everyone, > > I wanted to give people a quick heads up. I would l

Re: proton engine performance: two strong credit management effects

On 08/27/2014 02:55 PM, Andrew Stitcher wrote: > On Wed, 2014-08-27 at 13:39 -0400, Michael Goulish wrote: >> >> conclusion >> = >> >> >> Using the proton engine interface (in C) I am seeing two >> aspects of credit management that ca

Re: proton engine performance: two strong credit management effects

On 08/27/2014 03:05 PM, Andrew Stitcher wrote: > On Wed, 2014-08-27 at 14:55 -0400, Andrew Stitcher wrote: >> ... >> Of this only applies under the exact circumstances of these tests, until >> we have more data points. I'd suspect it must also depend on the message >> size too. >> > > Just to re

Re: Proton Performance Pictures (1 of 2)

On 09/03/2014 11:35 AM, Michael Goulish wrote: > > > > > - Original Message - >> On 09/03/2014 08:51 AM, Michael Goulish wrote: >>> That point is where I seem to find the best performance on my >>> system: 123,500 messages per second received. ( i.e. 247,000 >>> transfers per second

Re: Intro to proton

Hi Jake, You are trying to run Proton (AMQP 1.0) against a broker that only talks AMQP 0-10. You need to make sure that the broker is loading the "amqp.so" module so it can support the 1.0 protocol. qpidd --load-module amqp.so If you are building the broker from source, you need to make sure Pr

Re: VOTE: Release Proton 0.8 RC5 as 0.8 final

[ X ] Yes, release Proton 0.8 RC5 as 0.8 final I tested 0.8 against the Dispatch trunk. On 10/27/2014 09:51 PM, Rafael Schloming wrote: > Hi Everyone, > > Sorry for the delay, there seemed to be some kind of Nexus outage today, so > I was unable to generate the java binaries until just now. > >

Re: [VOTE]: migrate the proton repo to use git

[ X ] Yes, migrate the proton repo over to git. On 10/30/2014 06:59 AM, Rafael Schloming wrote: > Hi Everyone, > > I'm planning on updating the release script for 0.9 to automate the last > few details of the release process and to do proper branching. Given that > the release script must make us

Re: reactor examples

Rafael, I'm a bit confused by this push. How does this set of examples relate to the examples Gordon has been developing in examples/engine/py? They are both "reactor" APIs with very similar structure yet they appear to be completely different and unrelated. Yours uses Reactor, on_delivery

Re: I think that's a blocker...

Would it be safe to assume that any operations on driver->io are not thread safe? Dispatch is a multi-threaded application. It looks to me as though io->error is a resource shared across the threads in an unsafe way. -Ted On 02/25/2015 08:55 AM, Rafael Schloming wrote: This isn't necessari

Re: I think that's a blocker...

On 02/25/2015 11:52 AM, Rafael Schloming wrote: On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross wrote: Would it be safe to assume that any operations on driver->io are not thread safe? Dispatch is a multi-threaded application. It looks to me as though io->error is a resource shared acro

Re: [VOTE]: Proton 0.9-rc-3

[ X ] Yes, release Proton 0.9-rc-3 as 0.9 final On 03/16/2015 04:42 PM, Rafael Schloming wrote: Hi Everyone, Here's a quick respin of 0.9-rc-3. The only changes from rc-2 are exactly those two mentioned on the rc-2 vote thread. I've included them at the end for reference. You can find the sour

Re: [RESULT] [VOTE]: Proton 0.9-rc-3

Rafael, Do you have an ETA for the final bits? We're anxious to build some downstream packages. -Ted On 03/22/2015 02:44 PM, Rafael Schloming wrote: This vote passes with 8 binding +1's and no other votes. I will push the final bits soon. --Rafael On Tue, Mar 17, 2015 at 9:42 AM, Rafael S

Re: 0.10 release time frame?

+1 I'd like to see an official release with the SASL updates as soon as practical. -Ted On 04/30/2015 09:37 PM, Rafael Schloming wrote: I'd like to see one fairly soon. I'm currently working through a few sasl-related interop issues between proton-c and proton-j, but once that is done and g

Re: [VOTE]: Release Proton 0.9.1-rc1 as 0.9.1

+1 On 04/29/2015 03:34 PM, Rafael Schloming wrote: Hi Everyone, I've put out an RC for 0.9.1 in the usual places. Source artifacts are here: https://people.apache.org/~rhs/qpid-proton-0.9.1-rc1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid

Re: AMQP 1.0 and Shared Subscriptions

On 05/06/2015 10:05 AM, Ken Giusti wrote: Bump this up. I'm essentially in the same boat. The olso.messaging library in Openstack has introduced a feature called 'consumer pools' which is essentially the same pattern: a set of subscribers to a topic can belong to a pool. Each distinct pool

[GitHub] qpid-proton pull request: Fix 2 Code Analysis warnings and a reall...

Github user ted-ross commented on the pull request: https://github.com/apache/qpid-proton/pull/39#issuecomment-118902728 I'd like to see this pull request move forward. On Dan's points above: 1) I agree with Andrew that using __LINE__ as an error code should be

Re: New python tox tests failing on fedora 22, Python 2.7.10/3.4.2

I had a similar error, not sure if it was exactly the same. I discovered that I was missing the python3-devel package. Once python3-devel was installed and I did a completely clean build, the problems went away. -Ted On 07/10/2015 10:01 AM, aconway wrote: Anyone seeing errors like this? I

Re: [VOTE] Release Qpid Proton 0.10 (RC2)

-1 unfortunately. I've been testing against Dispatch and I'm seeing lots of timeouts on the tests. It turns out that pn_read_frame is used to parse text that is not a frame header. It's actually the AMQP header so it interprets the string "AMQP" as the frame length. Now that we're testing

Re: [VOTE] Release Qpid Proton 0.10 (RC3)

+1 I tested proton-c against Dispatch Router. It all looks good. -Ted On 08/11/2015 04:08 PM, Robbie Gemmell wrote: Hi all, I have put up a third cut for 0.10, please test it and vote accordingly. Since RC2 there have been fixes for PROTON-978, PROTON-975, and PROTON-899. The release archi

Re: [VOTE] Release Qpid Proton 0.10 (RC3)

I ran the tests under Ubuntu 14.04 (for amd64) running an x86_64 Linux kernel (using Docker). All of the tests, including the SSL tests pass. -Ted On 08/13/2015 09:56 AM, Robbie Gemmell wrote: I have run up a fresh Ubuntu 14.04.3 install didn't see any issues (once I figured out what packages

Re: [VOTE] Release Qpid Proton 0.10 (RC3)

an issue and it can be identified, I'm sure it will be joined by others once a larger group of folks can actually get there hands on a release, and I'll happilly cut a 0.10.1 to address them if fixes are available. +1 Robbie On 13 August 2015 at 20:05, Ted Ross wrote: I ran the t

Re: Bug in proton interop suite??

I don't think this is a valid data sequence. Literally, it is a binary sequence of seven octets where the internal encoding of a string is coincidental. Binary is not a compound type and does not contain sub-fields. -Ted On 09/08/2015 05:36 PM, aconway wrote: I'm doing some interop work on

Re: proton 0.10 and swiftmq router

It looks like SwiftMQ is configured to require SASL authentication. If you supply authentication credentials (even "anonymous"), I believe this will work. -Ted On 10/02/2015 09:05 AM, Michael Ivanov wrote: Hallo, I am trying to run proton 0.10 client with SwiftMQ router and I'm getting the

Re: Proton 0.11.0 release update - Beta is available

I installed the 0.11.0 beta, ran the test suite, built Dispatch from master against it, and ran the Dispatch test suite. I also ran the six-node dispatch-router scenario. There were no build or test issues. -Ted On 10/28/2015 06:49 AM, Justin Ross wrote: Hi, everyone. The beta is now avai

Re: [VOTE] Release Qpid Proton 0.11.1

+1 I tested proton-c against qpid dispatch on Fedora 20. -Ted On 12/15/2015 02:32 PM, Robbie Gemmell wrote: Hi all, I have put up an RC for 0.11.1, please test it and vote accordingly. The release archive and sig/checksums can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/prot

Re: Issues with Qpid dispatch make

Hi Paul, Which version did you download and on what platform are you attempting to build it? -Ted On 02/01/2016 05:45 PM, Paul Flores wrote: Hi, Downloaded qpid_dispatch. Have run into issues with Building C object src/CMakeFiles/qpid-dispatch.dir/compose.c.o at container.h ( at lines 17

Re: [VOTE] merge the proton mailing list into the users/dev lists

+1 And a separate +1 to Rob's suggestion. -Ted On 03/30/2016 06:30 AM, Rob Godfrey wrote: +1 Additionally it might make sense to write a paragraph somewhere on suggestions for best practice on mailing the list (like including components / languages in use in the title or the body of the e-mai

Using Proton in Multi-Threaded Environments

In order to make sure that it can be done, I'm attempting to use Proton-c in a multi-threaded server environment.The basic assumptions that I'm making are: 1. The root data structure that threads can operate on is pn_connector_t/pn_connection_t. An application thread cannotuse pn_driver_

Re: Using Proton in Multi-Threaded Environments

On 09/06/2012 05:44 PM, William Henry wrote: - Original Message - In order to make sure that it can be done, I'm attempting to use Proton-c in a multi-threaded server environment.The basic assumptions that I'm making are: 1. The root data structure that threads can operate on is

Question on Internal Links

If I have a container built on proton and I want to establish a link between two nodes in the container, I would like to use pn_link_t so I have all the available link features. Is there a way to establish internal links? I assume that it would require a loopback connection of some sort since

Re: Proton engine api naming proposal

On 09/13/2012 09:00 AM, Justin Ross wrote: Hi, everyone. In my opinion, the engine api could benefit from being less terse and using systematic naming. The naming is already systematic in some respects, but it has idiosyncracies that I found consternating when I was trying to figure out what

Re: Proton engine api naming proposal

On 09/13/2012 09:28 AM, Ted Ross wrote: On 09/13/2012 09:00 AM, Justin Ross wrote: Hi, everyone. In my opinion, the engine api could benefit from being less terse and using systematic naming. The naming is already systematic in some respects, but it has idiosyncracies that I found

A multi-threaded server built on Qpid Proton-C

t an AMQP network, compatible with emerging AMQP addressing conventions and standards. A testbed, if you will, for AMQP addressing. I've put my work in progress on a repo at GitHub (https://github.com/ted-ross/nexus) in case anybody wants to look at or play with it. Out of the box, it pro

Re: initial release candidate

On 10/23/2012 02:41 PM, Rafael Schloming wrote: Hi Everyone, I've posted an initial release candidate here: http://people.apache.org/~rhs/qpid-proton-0.1/ Please keep in mind there hasn't been a wide variety of install testing so go ahead and try on as many different OS distro/versions as y

Re: RC2

There's a blocker bug in proton-c RC2. I'm investigating... It appears that messenger truncates the address in the "to" field on sent messages so that it only contains the "scheme://host" portion. -Ted On 10/24/2012 08:19 AM, Rafael Schloming wrote: I've uploaded another release candidate

Re: RC2

Withdrawn, pilot-error. -Ted On 10/24/2012 09:45 AM, Ted Ross wrote: There's a blocker bug in proton-c RC2. I'm investigating... It appears that messenger truncates the address in the "to" field on sent messages so that it only contains the "scheme://host" port

Re: acks for messenger

For the record, I also like option (2), for the reasons that Justin articulated. -Ted On 10/26/2012 11:24 AM, Justin Ross wrote: I like option 2) for two reasons. One, it produces very straightforward semantics for the various levels of delivery guarantee. Two, it's easy to ignore if you'd

Re: [VOTE] RC8

+1 ship it On 10/29/2012 09:32 PM, Rafael Schloming wrote: I'm optimistically starting an official release vote for RC8 here. I'm hoping if there is enough support and no procedural objections we can fudge the 72 hour formal vote process down to 24 hours. I personally think this is reasonable be

[VOTE] qpid-proton 0.2 maven binaries

The binaries for the proton-j 0.2 source packages have been deployed in the Apache Nexus Repository. This vote is to approve the release of the binary artifacts. I will run the vote until COB on Monday, November 12 (EST). Posted here: https://repository.apache.org/content/repositories/orgap

[VOTE RESULT] qpid-proton 0.2 maven binaries

5 +1 votes, 4 from PMC members. The vote passes. -Ted The binaries for the proton-j 0.2 source packages have been deployed in the Apache Nexus Repository. This vote is to approve the release of the binary artifacts. I will run the vote until COB on Monday, November 12 (E

Using script-native drivers for Proton messenger bindings

One of the problems we've had for a long time with wrapped bindings is the mismatch of threading models. For example, a Ruby program using an extension module written in C/C++ will hang if a call into the extension blocks. This is because the extension uses pthreads and the host program uses

Re: Using script-native drivers for Proton messenger bindings

On 11/14/2012 12:24 PM, Andrew Stitcher wrote: On Wed, 2012-11-14 at 17:49 +0100, Rafael Schloming wrote: ... How does the packaging prevent this? Not to put words in Ted's mouth, but I think what he is talking about here is that the messenger API code itself depends on the driver code. Andre

Re: Using script-native drivers for Proton messenger bindings

On 11/14/2012 11:49 AM, Rafael Schloming wrote: How does the packaging prevent this? 1) Develop the non-blocking aspects of the API. This might just involve a few additions to the current API or possibly adding a distinct non-blocking API which would be a layer underneath the current API.

Re: Using script-native drivers for Proton messenger bindings

On 11/14/2012 12:56 PM, Rafael Schloming wrote: On Wed, Nov 14, 2012 at 6:37 PM, Ted Ross wrote: On 11/14/2012 11:49 AM, Rafael Schloming wrote: How does the packaging prevent this? 1) Develop the non-blocking aspects of the API. This might just involve a few additions to the current

Re: Problems building and running proton-c on Linux RHEL 5

Phil, With regard to the python uuid issue, this was handled in qpid (see qpid/python/build/lib/qpid/datatypes.py). Perhaps proton needs to use a similar approach. -Ted On 11/29/2012 11:13 AM, Phil Harvey wrote: I'm having problems building and running proton-c on my machine. I'm hitting

Contrib under proton-c?

We've added a contrib directory under proton-j. Does anyone object to putting one in the proton-c directory as well? -Ted

Re: Contrib under proton-c?

wrote: Do you have something in mind to put there? --Rafael On Mon, Dec 17, 2012 at 6:08 PM, Ted Ross wrote: We've added a contrib directory under proton-j. Does anyone object to putting one in the proton-c directory as well? -Ted

Re: Contrib under proton-c?

18, 2012, at 5:23 AM, Rafael Schloming wrote: Do you have something in mind to put there? --Rafael On Mon, Dec 17, 2012 at 6:08 PM, Ted Ross wrote: We've added a contrib directory under proton-j. Does anyone object to putting one in the proton-c directory as well? -Ted

Re: Contrib under proton-c?

, William Henry wrote: It thought the idea of proton was for the libraries and language API wrappers only. Why doesn't everything else just move into Qpid proper. There is a danger that proton becomes its own AMQP project otherwise. No? Sent from my iPhone On Dec 18, 2012, at 6:54 AM, Ted Ros

Re: Contrib under proton-c?

On 12/18/2012 01:49 PM, Darryl L. Pierce wrote: On Tue, Dec 18, 2012 at 09:43:05AM -0500, Ted Ross wrote: Yes, but the content I'm talking about is just libraries (and headers). Actual applications like routers, proxies, brokers, etc. would live in Qpid. I can put these libraries in

Re: Contrib under proton-c?

On 12/18/2012 02:06 PM, Rafael Schloming wrote: The proton-j/contrib directory was created to hold glue/integration with established third-party libraries/apis (specifically jms and hawtdispatch). The fact that hawtdispatch and jms don't want a proton dependency, and proton doesn't want a jms or

Proton Messenger and the Request/Response pattern

I'd like to start a discussion on how, from an API perspective, applications can use the request/response pattern. If we get this right, we will remove a significant barrier to adoption of AMQP. Middleware messaging systems typically do a poor job of supporting this pattern. The Qpid APIs ar

Re: Proton Messenger and the Request/Response pattern

On 01/02/2013 02:39 PM, William Henry wrote: - Original Message - I'd like to start a discussion on how, from an API perspective, applications can use the request/response pattern. If we get this right, we will remove a significant barrier to adoption of AMQP. Middleware messaging sy

Re: inconsistent proton library names?

Phil, The only shared-object in that list that is a proper "library" is libqpid-proton.so. The others are extension modules for their various scripting languages. I'm not 100% sure, but I believe that the naming conventions are dictated by the scripting language's extension mechanisms. -Te

Re: [VOTE] 0.3 RC3

+1 Tested against a couple of applications I'm developing. It looks good. -Ted On 01/08/2013 09:53 PM, Rafael Schloming wrote: Source is here: http://people.apache.org/~rhs/qpid-proton-0.3rc3/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-118/ Fixes

Re: Is Proton a lightweight alternative to Qpid?

Taylor, Another possibility to look at is using ActiveMQ as your broker. They've added an AMQP transport (based on Proton-J) to their project recently. -Ted On 01/15/2013 12:37 PM, Eagy, Taylor wrote: Rafael, Thanks for responding. The only reason why I said it wouldn't be portable is be

Re: Is Proton a lightweight alternative to Qpid?

Taylor, You need the following files: proton.py (from proton-c/bindings/python) cproton.py (from $BUILD/bindings/python) _cproton.so(from $BUILD/bindings/python) libqpid-proton.so (from $BUILD) -Ted On 01/15/2013 03:35 PM, Eagy, Taylor wrote: Ted,

Re: mailing lists and fragmented communication

+1 I think this is a real problem and I would be supportive of consolidating all of the discussion into one list. We either exclude people by sending to one list or, like this email, we include all lists and everybody gets three copies. -Ted On 01/18/2013 12:21 PM, Gordon Sim wrote: I beli

Re: Is Proton a lightweight alternative to Qpid?

stuff would get you down to about 1.2MB if you want to go super barebones. --Rafael On Tue, Jan 15, 2013 at 5:38 PM, Ted Ross wrote: Taylor, You need the following files: proton.py (from proton-c/bindings/python) cproton.py (from $BUILD/bindings/python) _cproto

Re: bug? interaction between two senders

This is related to PROTON-200 On 02/15/2013 09:15 AM, Rafael Schloming wrote: Can you post your code? --Rafael On Fri, Feb 15, 2013 at 5:22 AM, Michael Goulish wrote: Have I found a bug ? scenario { receiver { I start a receiver and it subscribes to ports and 6667. In

Re: UUID size

Also, the AMQP specification defines uuid as 16-bytes. -Ted On 02/22/2013 11:29 AM, Ken Giusti wrote: Hi Darryl, Proton represents the UUID as binary, hence the 16 byte array. For string representations, such as Ruby's, that would have to be converted to ascii/utf8 hex, and would require t

Re: put vs. send

On 03/05/2013 02:01 PM, Rafael Schloming wrote: On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish wrote: So, am I understanding correctly? -- I should be able to get messages from my sender to my receiver just by calling put() -- if the receiver is ready to receive? Not necessarily, the rece

Re: put vs. send

On 03/05/2013 02:14 PM, Rajith Attapattu wrote: This is a good explanation that we need to put in the docs, as Application developers certainly need to know how it behaves. If one were to use the current C impl, it certainly gives the impression that put() is meant to write messages into your i

Re: semantics vs. behavior

If semantics like "put vs. send" are not stable as documented across releases, then the API is not stable and people's applications will break when they shouldn't. In other words, even documented changes in semantics represent incompatible breaks in the API. So, you should be documenting sema

Re: put vs. send

On 03/06/2013 04:44 AM, Rob Godfrey wrote: On 5 March 2013 21:10, Rafael Schloming wrote: On Tue, Mar 5, 2013 at 11:24 AM, Ted Ross wrote: [.. snip ..] It isn't really possible to have "put" cause messages to be eventually sent without a background thread, something we

Re: put vs. send

On 03/06/2013 08:30 AM, Rafael Schloming wrote: On Wed, Mar 6, 2013 at 5:15 AM, Ted Ross wrote: This is exactly right. The API behaves in a surprising way and causes reasonable programmers to write programs that don't work. For the sake of adoption, we should fix this, not merely doc

Re: put vs. send

On 03/06/2013 10:09 AM, Rafael Schloming wrote: On Wed, Mar 6, 2013 at 6:52 AM, Ted Ross wrote: On 03/06/2013 08:30 AM, Rafael Schloming wrote: On Wed, Mar 6, 2013 at 5:15 AM, Ted Ross wrote: This is exactly right. The API behaves in a surprising way and causes reasonable programmers

Re: new send / recv proposal, documented

On 03/08/2013 09:31 AM, Michael Goulish wrote: based on Rafi's proposal a couple days ago. The idea here is to use this document to clearly see what the proposal is. Is this what we want ? Comment early and often. PLEASE NOTE one big difference. I don't have to talk about timeouts anymore t

Re: Why 2 space indentations??

+1. I've also wondered why this one codebase was written with 2-space indentation. My editors are all set up for 4-spaces so doing any work in this code is a pain. I'm in favor of converting all of it to comply with the 4-space convention. -Ted On 03/14/2013 09:18 AM, Ken Giusti wrote: Not

Re: nagle algorithm

+1 It would be good to make this configurable, but in the absence of configurability, we should turn Nagle off by default. -Ted On 03/14/2013 03:25 PM, Rafael Schloming wrote: I think in most of the other network code at qpid we tend to disable nagle as you suggest, so I expect it would make

Re: RFC: new routing functionality for messenger

I generally like this translation facility, though I'll need to think through some use cases to make sure there's sufficient capability in the matching and substitution. I question the value of having this as part of the API. It seems to me that the Messenger routing table should be part of t

Re: the soul of a new messaging technology

On 03/27/2013 07:28 AM, Michael Goulish wrote: I am trying to understand the fundamental differences between AMQP 1.0 / Proton messaging, and what we've done before -- and to express it in language that non-engineers can clearly understand and get excited about. Messaging for poets. You who a

Re: RFC: new routing functionality for messenger

On 03/25/2013 09:30 AM, Rafael Schloming wrote: On Mon, Mar 25, 2013 at 8:36 AM, Ted Ross wrote: I question the value of having this as part of the API. It seems to me that the Messenger routing table should be part of the configuration of a system (i.e. in a place like /etc/qpid/messenger

Re: Defining the behaviour of Proton Engine API under error conditions

On 03/27/2013 11:53 AM, Keith W wrote: Hi all Phil and I are tasked with producing a comprehensive set of system tests for Proton Engine. The aim is to produce a test suite that will execute against all Proton implementations thus guaranteeing that all exhibit identical behaviour and assuring

Re: problem with multiple senders

Any clues from a trace of the receiver? $ PN_TRACE_FRM=1 ./receiver -Ted On 04/04/2013 02:09 PM, Michael Goulish wrote: Is this a bug, or am I Doing Something Wrong ? Scenario { My sender sends a single message, and hopes to see that the receiver has accepted it. I lau

Re: problem with multiple senders

Looks like all three credits were given to the first link. Once one message arrived, its credit was given to the second link. The second link then transferred a message but the credit was given back to the second link where there were no more messages to transfer. On 04/04/2013 03:06 PM, Mi

Re: nagle algorithm

https://issues.apache.org/jira/browse/PROTON-294 On 03/15/2013 08:18 AM, Ted Ross wrote: +1 It would be good to make this configurable, but in the absence of configurability, we should turn Nagle off by default. -Ted On 03/14/2013 03:25 PM, Rafael Schloming wrote: I think in most of the

Re: Specification question: attach with no source/target

On 04/22/2013 09:31 AM, Rafael Schloming wrote: This might seem like an odd way to fail link establishment, however it is really a special case of a more general negotiation pattern, for example the same pattern might be used to do a kind of redirect: Client ATTACH(target="old-queu

Re: Receiving messages with PROTON messenger

If I understand you correctly, you want to block until MAXCOUNT messages are received before processing the messages. Is that correct? The "recv" function blocks until *at most* MAXCOUNT messages are received. In practice, it will usually return after the first message is received. You can

Re: Deadlock in pn_messenger_stop? (C Qpid Library)

I would suggest that you not stop the subscriber messenger in the main thread. Rather, stop it in the subscriber thread right before it exits. Alternatively (preferably), you should pthread_join the thread in main before stopping the messengers. It looks to me that you've got a race conditio

Re: Creating queues with PROTON messenger

Proton is an endpoint library. In order to have queues or topics, you will need to have a message broker. Are you using a particular broker? -Ted On 06/25/2013 05:51 AM, atarutin wrote: Hi, Folks. I still need an example. If messenger cann't create queues or topics, I think it might be poss

Re: Creating queues with PROTON messenger

I believe that ActiveMQ will create a queue as a side effect of subscribing or producing from/to an address. The AMQP working group is developing a management specification that will define a standard way for AMQP clients to create queues/topics on brokers. Until this is complete, there are o

Re: Qpid-specific logging facade(s) for Proton etc

Phil, Since this commit, I can't build proton. I get the following: /.../proton/proton-j/proton-api/src/main/java/org/apache/qpid/proton/logging/SLF4JCategoryLogger.java:21: error: package org.slf4j does not exist import org.slf4j.Logger; I checked and slf4j is installed on my system (Fedora

Re: svn commit: r1504829 - /qpid/proton/trunk/proton-j/contrib/proton-hawtdispatch/src/main/java/org/apache/qpid/proton/hawtdispatch/impl/AmqpTransport.java

Ack. You are quite right. My apologies for making you do work that I should have done myself. -Ted On 07/23/2013 03:32 PM, Robbie Gemmell wrote: This really shouldn't have been a NO-JIRA commit. There are two distinct changes here, both of which appear to have JIRAs with the associated patch

  1   2   3   >