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
[
https://issues.apache.org/jira/browse/PROTON-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018873#comment-14018873
]
Rajith Attapattu commented on PROTON-594:
-
Rafi could you please create a
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
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
[
https://issues.apache.org/jira/browse/PROTON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu updated PROTON-565:
Attachment: PROTON-565.part1.patch
> Modify the Messenger to use the Collector
[
https://issues.apache.org/jira/browse/PROTON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971420#comment-13971420
]
Rajith Attapattu commented on PROTON-565:
-
I had to mark the fix version as
Rajith Attapattu created PROTON-565:
---
Summary: Modify the Messenger to use the Collector API.
Key: PROTON-565
URL: https://issues.apache.org/jira/browse/PROTON-565
Project: Qpid Proton
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 wrote:
> On Mon, Mar 24, 2014 at 9:37 PM, Rajith Attapattu >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 is call
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 is called then the _inputProcessor
defaults to FrameParser instead of being wrapped by the SASL frame parser.
This causes
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)
On Mon, Mar 25, 2013 at 11:42 AM, Rafael Schloming wrote:
> On Mon, Mar 25, 2013 at 10:34 AM, Rajith Attapattu wrote:
>
>> 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, especial
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 contex
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 11:37 AM, Rajith Attapattu wrote:
> On Wed, Mar 6, 2013 at 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:
>>>
>>&g
On Wed, Mar 6, 2013 at 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 cause
On Tue, Mar 5, 2013 at 3:20 PM, Rafael Schloming wrote:
> On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu wrote:
>
>> On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross wrote:
>> >
>> > On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
>> >>
>> >>
&
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 b
On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross 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 th
On Tue, Mar 5, 2013 at 2:01 PM, Rafael Schloming wrote:
> On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish wrote:
>
>>
>> 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 should be able
+1
Rajith
On Tue, Mar 5, 2013 at 1:48 PM, Rafael Schloming 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 wrote:
>
>> I'm happy with the location although to increase consistency with other
>> projects
Rafi,
I don't want to sound pedantic, but we should tag our releases as per
the guidelines provided by Apache.
The previous releases don't have tags either (at least they do have a
branch, but the current release doesn't have a branch either).
Regards,
Rajith
On Mon, Feb 25, 2013 at 4:05 PM, Ra
mething wrong).
>
> Phil
> On Feb 25, 2013 7:07 PM, "Rajith Attapattu" 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
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 something
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 (Where
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 wrote:
> We could use lables to denote which binding(s).
> The advantage here is that if multiple bindings expose the same bug,
&g
Ken,
I want to draw your attention to a type of performance testing that we
haven't paid much attention in the past.
(The goals for #1 may include this, but just want to clarify if it's the case).
In the past we have focused a lot on performance tests that are
somewhat artificial and meaningless
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 str
This is also my impression about Hirams work.
So I'm not sure why there is resistance to the changes being proposed
as it's only going to benefit in the long run should the impl changes.
(I do understand that there will be some initial work in changing the
code to use the factories and interfaces).
I agree with Rob on this point. Given the trouble we had with our old
client it will be fool hardy not to correct those mistake in the new
implementation.
We've also had instances where users (and sometimes our own test
cases) directly creating implementation classes using the public
constructors m
> On Fri, Jan 18, 2013 at 2:29 PM, Rafael Schloming 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 calls. We
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 t
On Mon, Jan 14, 2013 at 2:48 PM, Darryl L. Pierce 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
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 branches for them though).
Regards,
Rajith
On Mon, Jan 14, 2013 at 2:14 PM, Rafael Schloming wrote:
> +1 from me as well. I think we have enough vo
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=1425124&view=rev
[2] https://reviews.apache.org/r/7934/diff/3/?file=236677#file236677line108
Rajith
On Fri, Dec 21, 2012 at 2
I also think qpid is a better place to host this than proton for the
reasons Rafi as mentioned.
However Qpid is fast becoming a collection of tools that are poorly
organized both on a source code level as well as on the product side.
I don't want to side track this conversation, but wanted to remi
[
https://issues.apache.org/jira/browse/PROTON-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510623#comment-13510623
]
Rajith Attapattu commented on PROTON-179:
-
I started out with a logging call
[x] Ship it. Reviewed the C code change with Rafi.
Rajith
On Mon, Nov 5, 2012 at 7:29 AM, Rob Godfrey wrote:
> [X] Ship it! (Release RC4 as 0.2)
>
> Tested java and reviewed C change.
>
> -- Rob
>
> On 5 November 2012 13:19, Rafael Schloming wrote:
>
>> Posted here: http://people.apache.org/~rh
[x] Ship it!
Rajith
On Mon, Oct 29, 2012 at 9: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 thi
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() t
Opps I meant f17 :)
Rajith
On Sat, Oct 27, 2012 at 9:56 AM, Rajith Attapattu wrote:
> 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 wrote:
>> +1 RC7 proton-c {mai
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 wrote:
> +1 RC7 proton-c {mainly Debian6 i686 testing}
>
> -K
>
> - Original Message -
>> Lucky number 7 posted here:
>>
>> http://people.apache.org/~
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
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 files where we
> norma
:01 PM, Rajith Attapattu 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 now.
e my suggestion.
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 Atta
Sorry I should have done this before you posted RC6 :(
We have a few files (mostly java files) that are missing license headers.
Please look at the RAT output I posted.
Once the final RC is voted, the release manager (in this case Rafi)
will have to sign the final artefacts.
You already have your
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 now.
If somebody hasn't gotten to it by tomorrow morning, I can take ca
We have a build failure on the java side.
It appears the SSL tests added in Kens fix is failing.
proton_tests.ssl.SslTest.test_client_authentication . fail
We should exclude this test before we spin the final release.
Rajith
On Thu, Oct 25, 2012 at 5:25 PM, Ken Giusti wrote:
[
https://issues.apache.org/jira/browse/PROTON-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479023#comment-13479023
]
Rajith Attapattu commented on PROTON-87:
All though not a big deal, I also t
[
https://issues.apache.org/jira/browse/PROTON-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479021#comment-13479021
]
Rajith Attapattu commented on PROTON-87:
Also if I'm not mist
[
https://issues.apache.org/jira/browse/PROTON-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474354#comment-13474354
]
Rajith Attapattu commented on PROTON-71:
Looks Rafi beat me t
[
https://issues.apache.org/jira/browse/PROTON-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474318#comment-13474318
]
Rajith Attapattu commented on PROTON-71:
+1
I was about to do this. Will a
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
[
https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472540#comment-13472540
]
Rajith Attapattu commented on PROTON-65:
Hiram,
First of all, thx for confir
[
https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472449#comment-13472449
]
Rajith Attapattu commented on PROTON-65:
Hiram,
One of the goals of proton i
Sep 20, 2012 at 03:37:10PM -0400, Rajith Attapattu wrote:
>> Given some of the recent discussions, it appears there isn't much
>> consensus as to what the "Messenger API" is.
>> For my own sanity, could someone with more knowledge on the $subject
>> please explain
On Thu, Sep 20, 2012 at 4:37 PM, William Henry wrote:
> - Original Message -
>> On Thu, Sep 20, 2012 at 4:02 PM, William Henry
>> wrote:
>> > Best to look at proton's examples/messenger send.py and recv.py
>> >
>> > That's the only documentation besides messenger.h
>>
>> That's precisely
On Thu, Sep 20, 2012 at 4:02 PM, William Henry wrote:
> Best to look at proton's examples/messenger send.py and recv.py
>
> That's the only documentation besides messenger.h
That's precisely my point.
We can't continue to point people at examples to figure out what the API is.
Given that we are g
We should seriously consider documenting the Engine API and it's
expected behaviour.
This has several advantages.
1. Use that as a basis for a functional spec, which we can then write
tests to verify the implementations.
2. Helps developers to navigate and understand the code more easily.
3. Fin
Given some of the recent discussions, it appears there isn't much
consensus as to what the "Messenger API" is.
For my own sanity, could someone with more knowledge on the $subject
please explain the following?
1. What is Messenger API ?
i.e Do we have a doc or a wiki page that documents what
On Thu, Sep 20, 2012 at 4:00 AM, Rob Godfrey wrote:
> On 20 September 2012 00:32, Rajith Attapattu wrote:
>
>> Hi All,
>>
>> There are a few folks who are keen to have AMQP 1.0 support for our JMS
>> client.
>> Given that the parent AMQP TC is starting a bi
Hi All,
There are a few folks who are keen to have AMQP 1.0 support for our JMS client.
Given that the parent AMQP TC is starting a bindings and mappings TC
which will cover JMS, I thought it would be a good idea to get a
discussion going on here as well.
We could aim to build the client as we pro
While we should stick to python for writing tests (that is used across
proton-j and proton-c) as much tests as possible, we still need to
write junit tests on the java side.
In doing so we will have to have a lib directory to carry the junit jar.
I know we are quite keen to keep proton dependency
I would like to commit the java version of the Mailbox example along
with the driver code.
I'm trying to determine the best location to place the files.
Any suggestion ?
I would like to include the examples in our first release.
In addition to showing how to use the driver it also doubles as a
gre
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
tran
On Thu, Sep 13, 2012 at 5:05 PM, Rafael Schloming wrote:
> On Thu, Sep 13, 2012 at 4:46 PM, Rajith Attapattu wrote:
>
>> On Mon, Sep 10, 2012 at 1:36 PM, Rafael Schloming
>> wrote:
>> > On Mon, Sep 10, 2012 at 9:26 AM, Darryl L. Pierce > >wrote:
>> > me
On Mon, Sep 10, 2012 at 1:36 PM, Rafael Schloming wrote:
> On Mon, Sep 10, 2012 at 9:26 AM, Darryl L. Pierce wrote:
> methods on Messenger and Message objects and by tying pn_messenger_free and
> pn_message_free into the respective destructors, we could make things a
> whole lot safer, e.g. avoid
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 wrote:
> Hey Everyone,
>
> I've put together a
I must admit that when I looked at the code initially I did find it a
bit hard to navigate the code.
Once I figured out the pattern it was easy.
I understand the reasoning behind Rafi's choice of words for naming
the API methods.
On the java side some of the names were a bit odd, which looked ok o
[
https://issues.apache.org/jira/browse/PROTON-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450062#comment-13450062
]
Rajith Attapattu commented on PROTON-16:
I plan to cherry-pick the follo
Rajith Attapattu created PROTON-16:
--
Summary: addTransportWork and addWork methods in
ConnectionImpl.java could cause an infinite loop
Key: PROTON-16
URL: https://issues.apache.org/jira/browse/PROTON-16
[
https://issues.apache.org/jira/browse/PROTON-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu updated PROTON-16:
---
Issue Type: Bug (was: Improvement)
> addTransportWork and addWork methods
[
https://issues.apache.org/jira/browse/PROTON-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu updated PROTON-14:
---
Summary: addModified method in ConnectionImpl can cause infinite loop
(was: add modified
[
https://issues.apache.org/jira/browse/PROTON-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450054#comment-13450054
]
Rajith Attapattu commented on PROTON-15:
I'm planning to cherry-pick the
Rajith Attapattu created PROTON-15:
--
Summary: Remove get/set Prev/Next methods from EndpointImpl.java
as they seem redundant/unused
Key: PROTON-15
URL: https://issues.apache.org/jira/browse/PROTON-15
[
https://issues.apache.org/jira/browse/PROTON-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450048#comment-13450048
]
Rajith Attapattu commented on PROTON-14:
A fix has been committed here
Rajith Attapattu created PROTON-14:
--
Summary: add modified method in ConnectionImpl can cause infinite
loop
Key: PROTON-14
URL: https://issues.apache.org/jira/browse/PROTON-14
Project: Qpid Proton
On Tue, Sep 4, 2012 at 9:16 PM, Rafael Schloming wrote:
> On Tue, Sep 4, 2012 at 5:53 PM, Rajith Attapattu wrote:
>
>> 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 als
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 wrote:
> Hi Everyone,
>
> I've done some explorator
Rafi,
>From what I understand there are two ways to use SSL/TLS with AMQP 1.0
a) A secure connection is established right off the bat.
b) A regular tcp connection is established and then based on the AMQP
header (with a protocol id of 2) you start encrypting the packets that
follow.
The first o
83 matches
Mail list logo
