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
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
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:
On 11/14/2012 12:56 PM, Rafael Schloming wrote:
On Wed, Nov 14, 2012 at 6:37 PM, Ted Ross tr...@redhat.com 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
18, 2012, at 5:23 AM, Rafael Schloming r...@alum.mit.edu wrote:
Do you have something in mind to put there?
--Rafael
On Mon, Dec 17, 2012 at 6:08 PM, Ted Ross tr...@redhat.com wrote:
We've added a contrib directory under proton-j. Does anyone object to
putting one in the proton-c directory
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
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
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.
-Ted
+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/
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
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,
to go super
barebones.
--Rafael
On Tue, Jan 15, 2013 at 5:38 PM, Ted Ross tr...@redhat.com wrote:
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
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 mgoul...@redhat.comwrote:
Have I found a bug ?
scenario
{
receiver
{
I start a receiver and it subscribes to ports
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
On 03/05/2013 02:01 PM, Rafael Schloming wrote:
On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish mgoul...@redhat.comwrote:
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
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
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
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
+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:
+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
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
On 03/25/2013 09:30 AM, Rafael Schloming wrote:
On Mon, Mar 25, 2013 at 8:36 AM, Ted Ross tr...@redhat.com 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
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
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,
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
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
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
appearances to the contrary.
The JIRAs are still open btw :)
Robbie
On 24 July 2013 13:12, Ted Ross tr...@redhat.com wrote:
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
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
+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:
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.
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
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
http://qpid.2158936.n2.nabble.com/file/n7603555/send.c slightly modified
send.c example. It works in 64 bit environment, but crashes
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
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()
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 will allow
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
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 the
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
+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:
-
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 can strongly
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 ) using about
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
[ 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.
I've
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,
[ 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
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
On 02/25/2015 11:52 AM, Rafael Schloming wrote:
On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross tr...@redhat.com 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
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
+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:
+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
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
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
changed
-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
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
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
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
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
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
+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
Ted Ross created PROTON-12:
--
Summary: Delivery structure uses malloc/free for every delivery
(delivery tag)
Key: PROTON-12
URL: https://issues.apache.org/jira/browse/PROTON-12
Project: Qpid Proton
Ted Ross created PROTON-18:
--
Summary: Add application context field to pn_connection_t
Key: PROTON-18
URL: https://issues.apache.org/jira/browse/PROTON-18
Project: Qpid Proton
Issue Type
Ted Ross created PROTON-25:
--
Summary: Connection doesn't transistion to PN_REMOTE_CLOSED when
socket is closed.
Key: PROTON-25
URL: https://issues.apache.org/jira/browse/PROTON-25
Project: Qpid Proton
Ted Ross created PROTON-31:
--
Summary: Message Corruption in point-to-point transfer via
messenger
Key: PROTON-31
URL: https://issues.apache.org/jira/browse/PROTON-31
Project: Qpid Proton
Issue
[
https://issues.apache.org/jira/browse/PROTON-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-31:
---
Attachment: send1.py
Invoked as:
$ ./send1.py -a //0.0.0.0/queue1
Message Corruption
[
https://issues.apache.org/jira/browse/PROTON-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-39:
---
Attachment: proton-39.patch
Implement pn_offer for sender links
[
https://issues.apache.org/jira/browse/PROTON-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465826#comment-13465826
]
Ted Ross commented on PROTON-40:
Here's a trace from a sending client that illustrates
[
https://issues.apache.org/jira/browse/PROTON-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466808#comment-13466808
]
Ted Ross commented on PROTON-40:
I've lowered the priority of this issue to minor.
There's
Ted Ross created PROTON-63:
--
Summary: Need access to annotated-message sections
Key: PROTON-63
URL: https://issues.apache.org/jira/browse/PROTON-63
Project: Qpid Proton
Issue Type: New Feature
[
https://issues.apache.org/jira/browse/PROTON-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-63:
---
Component/s: proton-j
Need access to annotated-message sections
[
https://issues.apache.org/jira/browse/PROTON-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-83.
Resolution: Fixed
Added a method to the driver API for activating connectors
[
https://issues.apache.org/jira/browse/PROTON-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-25.
Resolution: Not A Problem
Fix Version/s: 0.1
This is not a bug, only a user error. When the socket
[
https://issues.apache.org/jira/browse/PROTON-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-44.
Resolution: Cannot Reproduce
Fix Version/s: 0.1
Assignee: Ted Ross (was: Rafael H
[
https://issues.apache.org/jira/browse/PROTON-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-47.
Resolution: Fixed
Fix Version/s: 0.1
Script to generate release tarballs
[
https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-74:
---
Priority: Major (was: Blocker)
Fix the mailbox example.
Key
[
https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-74:
---
Affects Version/s: 0.1
Fix the mailbox example.
Key: PROTON
[
https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13480316#comment-13480316
]
Ted Ross commented on PROTON-74:
This example has been removed from the generated tarballs
[
https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-74:
---
Fix Version/s: 0.2
Fix the mailbox example.
Key: PROTON-74
[
https://issues.apache.org/jira/browse/PROTON-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-46:
---
Fix Version/s: 0.2
No way to get at a message's subscription using pn_messenger_t and
pn_message_t
[
https://issues.apache.org/jira/browse/PROTON-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-125:
Attachment: PROTON-125.patch
Proposed fix
Driver dies unnecessarily when poll returns
[
https://issues.apache.org/jira/browse/PROTON-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-125.
-
Resolution: Fixed
Re-resolved. pn_driver_wait now returns an error rather than exiting the
process
[
https://issues.apache.org/jira/browse/PROTON-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned PROTON-134:
---
Assignee: Ted Ross
pn_connector makes a blocking call to socket::connect
Ted Ross created PROTON-152:
---
Summary: SASL architecture does not support security layers
Key: PROTON-152
URL: https://issues.apache.org/jira/browse/PROTON-152
Project: Qpid Proton
Issue Type: Bug
[
https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-65.
Resolution: Fixed
Fix Version/s: 0.3
Provide a AMQP 1.0 Message to JMS Message mapping logic
[
https://issues.apache.org/jira/browse/PROTON-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-22.
Resolution: Fixed
Fix Version/s: 0.3
Add optional module that provides HawtDispatch integration
[
https://issues.apache.org/jira/browse/PROTON-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-134.
-
Resolution: Fixed
pn_connector makes a blocking call to socket::connect
[
https://issues.apache.org/jira/browse/PROTON-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580820#comment-13580820
]
Ted Ross commented on PROTON-243:
-
The shorter version: When installing 0.4 on a 64-bit
[
https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616324#comment-13616324
]
Ted Ross commented on PROTON-278:
-
An alternative API is to add a method
[
https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616324#comment-13616324
]
Ted Ross edited comment on PROTON-278 at 4/3/13 3:00 PM
[
https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620979#comment-13620979
]
Ted Ross commented on PROTON-278:
-
A second alternative is to provide a special put call
[
https://issues.apache.org/jira/browse/PROTON-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned PROTON-294:
---
Assignee: Ted Ross
Driver - Enable TCP_NODELAY on connections by default
[
https://issues.apache.org/jira/browse/PROTON-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-294:
Summary: Driver - Enable TCP_NODELAY on connections by default (posix)
(was: Driver - Enable TCP_NODELAY
[
https://issues.apache.org/jira/browse/PROTON-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-294.
-
Resolution: Fixed
Driver - Enable TCP_NODELAY on connections by default (posix
[
https://issues.apache.org/jira/browse/PROTON-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-139:
Priority: Blocker (was: Major)
Can't set distribution-mode on a source
Ted Ross created PROTON-308:
---
Summary: Python Messenger: Strings encoded in map bodies are
encoded as binary, not string
Key: PROTON-308
URL: https://issues.apache.org/jira/browse/PROTON-308
Project: Qpid
[
https://issues.apache.org/jira/browse/PROTON-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13652946#comment-13652946
]
Ted Ross commented on PROTON-308:
-
If the body is set as {u'opcode', u'test'}, the strings
[
https://issues.apache.org/jira/browse/PROTON-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-308.
-
Resolution: Won't Fix
This is at most a documentation issue as it is related to the way Python
handles
[
https://issues.apache.org/jira/browse/PROTON-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved PROTON-314.
-
Resolution: Fixed
Fixed in commit: 1482995
Posix driver - If a connector
Ted Ross created PROTON-323:
---
Summary: Regression: Messenger sends null in disposition state
after accept
Key: PROTON-323
URL: https://issues.apache.org/jira/browse/PROTON-323
Project: Qpid Proton
[
https://issues.apache.org/jira/browse/PROTON-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-323:
Priority: Blocker (was: Major)
Regression: Messenger sends null in disposition state after accept
1 - 100 of 182 matches
Mail list logo
