Rajith Attapattu created PROTON-803:
---
Summary: Message codec improvements
Key: PROTON-803
URL: https://issues.apache.org/jira/browse/PROTON-803
Project: Qpid Proton
Issue Type: Improvement
Rajith Attapattu created PROTON-594:
---
Summary: In tree builds with cmake causes issues when running
python based tests
Key: PROTON-594
URL: https://issues.apache.org/jira/browse/PROTON-594
Project
[
https://issues.apache.org/jira/browse/PROTON-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14018873#comment-14018873
]
Rajith Attapattu commented on PROTON-594:
-
Rafi could you please create a new
Rajith Attapattu created PROTON-589:
---
Summary: Implement passive mode for proton-j messenger
Key: PROTON-589
URL: https://issues.apache.org/jira/browse/PROTON-589
Project: Qpid Proton
Mark,
Nothing is wrong with your code.
The issue is down to a difference in how SASL is handled in the Proton java
side and the c++ broker.
If I comment out the SASL code in the messenger impl your example works
properly.
I have seen this issue before and will investigate it further.
Rajith
On
Rajith Attapattu created PROTON-543:
---
Summary: Frame Parser error if input stream is read before SASL is
initialized in the transport
Key: PROTON-543
URL: https://issues.apache.org/jira/browse/PROTON-543
Schloming r...@alum.mit.edu wrote:
On Mon, Mar 24, 2014 at 9:37 PM, Rajith Attapattu rajit...@gmail.com
wrote:
I encountered an issue in Proton J which I believe is a race condition.
If the input stream is read and passed into the transport, before the
sasl() method of TransportImpl.java
I would like to get logging working with the protocol engine.
Does anybody know the current status and how to get trace level logging
going on ?
Regards,
Rajith
So, I'd be in favour of Hiram's proposal if ProtonJ and ProtonC reside in
proton-api.jar. This would be very easy to do, e.g.
I don't think ProtonJ and ProtonC should reside in the proton-api.jar
And I don't think thats what Hiram suggested either (pls correct me if I
have misunderstood).
For starters I would copy this email to the user list.
(In the future we should post things like this to a more wider
audience, especially if we are looking for feedback based on real
world use cases.)
I actually like the minimalistic approach you've taken here. It works
well in an embedded
On Mon, Mar 25, 2013 at 11:42 AM, Rafael Schloming r...@alum.mit.edu wrote:
On Mon, Mar 25, 2013 at 10:34 AM, Rajith Attapattu rajit...@gmail.comwrote:
For starters I would copy this email to the user list.
(In the future we should post things like this to a more wider
audience, especially
Phil,
I don't think what you suggested is against the spirit of open source.
As a project we certainly need to think about how to better
communicate among us and also with our user base.
A number of users have voiced their concerns about not knowing major
changes and plans in a timely manner.
We
On Wed, Mar 6, 2013 at 10:09 AM, Rafael Schloming r...@alum.mit.edu wrote:
On Wed, Mar 6, 2013 at 6:52 AM, Ted Ross tr...@redhat.com wrote:
On 03/06/2013 08:30 AM, Rafael Schloming wrote:
On Wed, Mar 6, 2013 at 5:15 AM, Ted Ross tr...@redhat.com wrote:
This is exactly right. The API
On Wed, Mar 6, 2013 at 11:37 AM, Rajith Attapattu rajit...@gmail.com wrote:
On Wed, Mar 6, 2013 at 10:09 AM, Rafael Schloming r...@alum.mit.edu wrote:
On Wed, Mar 6, 2013 at 6:52 AM, Ted Ross tr...@redhat.com wrote:
On 03/06/2013 08:30 AM, Rafael Schloming wrote:
On Wed, Mar 6, 2013 at 5:15
+1
Rajith
On Tue, Mar 5, 2013 at 1:48 PM, Rafael Schloming r...@alum.mit.edu wrote:
I'm +1 on docs. It would be consistent with examples, tests, and tools.
--Rafael
On Tue, Mar 5, 2013 at 1:01 AM, Phil Harvey p...@philharveyonline.comwrote:
I'm happy with the location although to increase
On Tue, Mar 5, 2013 at 2:01 PM, Rafael Schloming r...@alum.mit.edu wrote:
On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish mgoul...@redhat.comwrote:
quoth Rafi:
The semantics of pn_messenger_put allow it to send if it can do so
without
blocking.
So, am I understanding correctly? -- I
On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross tr...@redhat.com wrote:
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
Mick, great question!
As I mentioned in the other thread we owe it to application developers
to describe the behaviour.
And if we change the behaviour btw releases we need to document it
prominently in the release notes as is often the case applications
will be written taking advantage of certain
On Tue, Mar 5, 2013 at 3:20 PM, Rafael Schloming r...@alum.mit.edu wrote:
On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu rajit...@gmail.comwrote:
On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross tr...@redhat.com wrote:
On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
This is a good
:07 PM, Rajith Attapattu rajit...@gmail.com wrote:
I'm strong believer in maintaining our docs in the source tree, as it
makes it easy to release docs along side the code.
Also it helps keep the docs current.
The wiki based documentation in the past had many issues, the chief
complaint being
I'm strong believer in maintaining our docs in the source tree, as it
makes it easy to release docs along side the code.
Also it helps keep the docs current.
The wiki based documentation in the past had many issues, the chief
complaint being stale most of the time.
We could look at doing
I was wondering what is the mechanism recommended for obtaining a
MessengerFactory instance (other than directly instantiating it).
IIRC people are planning to use the pure java and swig based impl side
by side especially for testing.
So this rules out the way we used for the old jms client
bindings were associated with the bug.
Having a component per binding would not allow the above flexibility.
Rajith
On Mon, Feb 4, 2013 at 2:56 PM, Rajith Attapattu rajit...@gmail.com wrote:
We could use lables to denote which binding(s).
The advantage here is that if multiple bindings expose
We could use lables to denote which binding(s).
The advantage here is that if multiple bindings expose the same bug,
all we need to do is to add an additional label to the same JIRA.
We currently use labels in the JMS client to denote sub categories (Ex
addressing, exception-handling).
The same
I'd agree with Gordon.
1. We should keep the Message as a pure value object without any sort
of coupling to Messenger or other objects.
2. I'm in favor of layering features on top of a generic flexible core
component rather than putting them all in the same layer.
This allows us the freedom
On Fri, Jan 18, 2013 at 2:29 PM, Rafael Schloming r...@alum.mit.edu wrote:
The nub of the problem is the sharing of the Java Proton-API between
both proton-c and proton-j trees. Solutions based on svn-external and
a simple tree copy have been considered and discussed at length on
conference
On Mon, Jan 14, 2013 at 2:48 PM, Darryl L. Pierce dpie...@redhat.com wrote:
On Mon, Jan 14, 2013 at 02:35:08PM -0500, Rajith Attapattu wrote:
Rafi,
We should create tags for the releases.
Unless I have missed (in which case I apologize), I don't see any for
0.1 and 0.2 releases (I do see
Rafi,
If you are spinning another RC please include [1] ?
It's done to ensure we close tcp connections.
Please see [2] for details.
[1] http://svn.apache.org/viewvc?rev=1425124view=rev
[2] https://reviews.apache.org/r/7934/diff/3/?file=236677#file236677line108
Rajith
On Fri, Dec 21, 2012 at
[x] Ship it. Reviewed the C code change with Rafi.
Rajith
On Mon, Nov 5, 2012 at 7:29 AM, Rob Godfrey rob.j.godf...@gmail.com wrote:
[X] Ship it! (Release RC4 as 0.2)
Tested java and reviewed C change.
-- Rob
On 5 November 2012 13:19, Rafael Schloming r...@alum.mit.edu wrote:
Posted
I like Option 2 with the addendum.
1. Keeping Message purely as a value object without any coupling to
any state is very desirable.
2. As Justin mentioned, option 2 allows a clear and more importantly a
common approach for handling reliability for both sender and receiver.
3. Messenger.ack() to
I used RAT to automatically add the headers.
I will correct it on monday.
Rajith
On Fri, Oct 26, 2012 at 8:16 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
It doesnt really affect the release since the files are now licenced, but
the diff below suggests the header wasn't added to the Java
On friday I ran the java and C builds on f14 (64bit) and passed
without any issues.
Rajith
On Fri, Oct 26, 2012 at 11:51 AM, Ken Giusti kgiu...@redhat.com wrote:
+1 RC7 proton-c {mainly Debian6 i686 testing}
-K
- Original Message -
Lucky number 7 posted here:
.
Actually a better suggestion would have been to move that file to the top level.
But anyways, given that we have a new system in place it's irrelevant now.
We should make an attempt to use the new approach.
Rajith
Robbie
On 26 October 2012 02:05, Rajith Attapattu rajit...@gmail.com wrote
25, 2012 at 9:01 PM, Rajith Attapattu rajit...@gmail.com wrote:
The following RAT output shows that we are missing a few license
headers, mostly java files.
http://people.apache.org/~rajith/proton/proton-rat-output.txt
We need to fix them before releasing.
Unfortunately I need to step out
[
https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472449#comment-13472449
]
Rajith Attapattu commented on PROTON-65:
Hiram,
One of the goals of proton
[
https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472540#comment-13472540
]
Rajith Attapattu commented on PROTON-65:
Hiram,
First of all, thx for confirming
Rajith Attapattu created PROTON-66:
--
Summary: Driver implementation for proton-j
Key: PROTON-66
URL: https://issues.apache.org/jira/browse/PROTON-66
Project: Qpid Proton
Issue Type: New
On Thu, Sep 20, 2012 at 4:37 PM, William Henry whe...@redhat.com wrote:
- Original Message -
On Thu, Sep 20, 2012 at 4:02 PM, William Henry whe...@redhat.com
wrote:
Best to look at proton's examples/messenger send.py and recv.py
That's the only documentation besides messenger.h
I've already committed the bug fixes and is working on getting the
driver code in.
For the driver I plan to get it in, once I incorporate Rob's feedback.
Once I get that in, for the second phase I would like to work with Rob
to adjust the driver code to mirror the changes he's planning on the
I would strongly favour shared documentation as much as possible.
The concepts , examples etc.. can be handled via a common document and
we might have to have some language specific sections.
Rajith
On Wed, Sep 12, 2012 at 3:42 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hey Everyone,
I've
[
https://issues.apache.org/jira/browse/PROTON-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450062#comment-13450062
]
Rajith Attapattu commented on PROTON-16:
I plan to cherry-pick the following commit
I'm trying to figure out what changes are needed on the Java side.
It seems the bind method will be of interest.
Rafi, could you also explain how the refactor is going to help with SSL ?
Rajith
On Tue, Sep 4, 2012 at 5:09 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Everyone,
I've done
43 matches
Mail list logo
