Re: [NOTICE] the proton@ mailing list is being merged into the users/dev lists

[Robbie Gemmell]

On 18 April 2016 at 12:34, Robbie Gemmell  wrote:
> On 18 April 2016 at 11:42, Robbie Gemmell  wrote:
>> The proton@q.a.o mailing list will merged into the users/dev lists, as
>> you may already be aware from recent threads.
>>
>> As part of this, around 50 subscribers to proton@ who are not also
>> currently subscribed to users@ will be subscribed to the users@ list.
>> The proton@ list will then be retired and its list address aliased
>> with users@. I will raise this request with infra next week.
>>
>> If you fall into the group of people not subscribed to both those
>> lists already and wish to subscribe to users@ before that time, you
>> can do so by following the subscribe instructions at
>> http://qpid.apache.org/discussion.html. Alternatively, if you are in
>> the group and do not wish to be subscribed to users@, you may
>> unsubscribe from the proton@ list before then by following the
>> unsubscribe instructions on the same page.
>>
>> Development related traffic such as mails from JIRA and GitHub will
>> move to the dev@ list (also see the above page if wishing to subscribe
>> there). I will raise requests with infra to that end shortly.
>>
>> Regards,
>> Robbie
>
> The change to direct Proton JIRA update traffic to dev@ is now live.
>
> Robbie


The change to direct the GitHub integration notification mails to dev@
is now also in effect.

Robbie

Re: [NOTICE] the proton@ mailing list is being merged into the users/dev lists

[Robbie Gemmell]

On 18 April 2016 at 11:42, Robbie Gemmell  wrote:
> The proton@q.a.o mailing list will merged into the users/dev lists, as
> you may already be aware from recent threads.
>
> As part of this, around 50 subscribers to proton@ who are not also
> currently subscribed to users@ will be subscribed to the users@ list.
> The proton@ list will then be retired and its list address aliased
> with users@. I will raise this request with infra next week.
>
> If you fall into the group of people not subscribed to both those
> lists already and wish to subscribe to users@ before that time, you
> can do so by following the subscribe instructions at
> http://qpid.apache.org/discussion.html. Alternatively, if you are in
> the group and do not wish to be subscribed to users@, you may
> unsubscribe from the proton@ list before then by following the
> unsubscribe instructions on the same page.
>
> Development related traffic such as mails from JIRA and GitHub will
> move to the dev@ list (also see the above page if wishing to subscribe
> there). I will raise requests with infra to that end shortly.
>
> Regards,
> Robbie

The change to direct Proton JIRA update traffic to dev@ is now live.

Robbie

[NOTICE] the proton@ mailing list is being merged into the users/dev lists

[Robbie Gemmell]

The proton@q.a.o mailing list will merged into the users/dev lists, as
you may already be aware from recent threads.

As part of this, around 50 subscribers to proton@ who are not also
currently subscribed to users@ will be subscribed to the users@ list.
The proton@ list will then be retired and its list address aliased
with users@. I will raise this request with infra next week.

If you fall into the group of people not subscribed to both those
lists already and wish to subscribe to users@ before that time, you
can do so by following the subscribe instructions at
http://qpid.apache.org/discussion.html. Alternatively, if you are in
the group and do not wish to be subscribed to users@, you may
unsubscribe from the proton@ list before then by following the
unsubscribe instructions on the same page.

Development related traffic such as mails from JIRA and GitHub will
move to the dev@ list (also see the above page if wishing to subscribe
there). I will raise requests with infra to that end shortly.

Regards,
Robbie

[RESULT] [VOTE] Release Qpid Proton 0.12.2

[Robbie Gemmell]

There were 5 binding +1 votes, and no other votes received. The vote has passed.

I will add the archives to the dist release repo and release the maven
staging repo shortly. The website will be updated later after the
artifacts have had time to sync to the mirrors and maven central.

Robbie

Re: Proton-j Reactor - Receiver

[Robbie Gemmell]

Hi Sree,

Your attachment didnt make it, the mailing list strips almost all
attachments, particularly of any non trivial size. Best to attach
stuff to JIRAs or provide links to them elsewhere.

I had another look at it and still don't see a way for it to do what
it did before, I'd guess it may be something slightly different. I
think I'll need more analysis and/or a reproducer from you to make any
further progress.

0.12.2 currently has the votes to pass. If it stays that way I
probably lean towards proceeding with its release unless more concrete
details becomes obvious, since it does seem to give a good improvement
over the previous behaviour.

Robbie

On 15 April 2016 at 01:35, Garlapati Sreeram Kumar  wrote:
> Hello Robbie,
>
>
>
> After couple hours of Stress Run with the proton-j change – we still could
> repro the Receive Stuck problem. Although – the below bug fix places us in a
> much better state now.
>
> Attached a screenshot of Objects sizes on Heap – which corresponds to the
> codepath that you fixed (SimpleSslTransportWrapper).
>
> Please see if this rings any bells – I am more than happy to share more
> details (proton traces & dump – pls suggest if you will need more details).
>
>
>
> Thx!
>
> Sree
>
>
>
> From: Garlapati Sreeram Kumar
> Sent: Monday, April 11, 2016 11:50 AM
> To: Robbie Gemmell; proton@qpid.apache.org
> Cc: SeongJoon Kwak (SJ); hm...@microsoft.com
> Subject: RE: Proton-j Reactor - Receiver
>
>
>
> Awesome.
>
> To make it easy - added you as collaborator to my fork of Proton & here’s
> the branch from which I submitted the PR:
> https://github.com/SreeramGarlapati/qpid-proton/tree/sg.recvstuck
>
> Thx!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Monday, April 11, 2016 9:52 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>;
> hm...@microsoft.com<mailto:hm...@microsoft.com>
> Subject: Re: Proton-j Reactor - Receiver
>
> Ah, excellent. I had actually started on testing this myself a little
> earlier, so I'll take a look and see whats what before continuing
> tomorrow. On taking an initial better look at things I think the
> change itself may need augmented to account for some other conditions
> too, need to investigate further to be sure.
>
> Robbie
>
> On 11 April 2016 at 17:37, Garlapati Sreeram Kumar 
> wrote:
>> Thanks a lot for the Response Robbie!
>> Per your suggestion, added the CIT to the Pull Request (& yes, as you
>> already said – this issue is being tracked via JIRA - PROTON-1171).
>>
>> Thanks a lot for the Wonderful Collaboration!
>> Sree
>>
>> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
>> Sent: Thursday, April 7, 2016 3:52 AM
>> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
>> Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>;
>> hm...@microsoft.com<mailto:hm...@microsoft.com>
>> Subject: Re: Proton-j Reactor - Receiver
>>
>> Hi Sree,
>>
>> Thanks for the analysis and PR, I'll try to take a proper look soon.
>> It's not an area of the code I'm familiar with so I'll need to have a
>> bit of a dig myself to see if the change seems ok. I'd note that any
>> not-insignificant bug fix such as this should probably have a test
>> with it (and a JIRA, though I see you have since created one of those)
>> :)
>>
>> Robbie
>>
>> On 6 April 2016 at 01:23, Garlapati Sreeram Kumar 
>> wrote:
>>> Hello Robbie,
>>>
>>> We are using proton-j client with SSL and many of our customers are
>>> hitting this issue.
>>> Here are my findings after debugging through this issue:
>>>
>>> -  When incoming bytes arrive on the SocketChannel – proton-j
>>> client gets signaled by nio & as a result it unwinds the transport stack –
>>> as a result all the TransportInput implementations performs its task on the
>>> Read Bytes and hands off to the Next Layer in the stack (transport to ssl,
>>> ssl to frameparser etc).
>>>
>>> -  While unwinding that stack,
>>> SimpleSSLTransportWrapper.unwrapInput reads(16k bytes) from _inputBuffer and
>>> the result - decoded bytes are written to _decodedInputBuffer – as an
>>> intermediate buffer.
>>>
>>> -  It then flushes bytes from intermediate buffer to the next
>>> layer & invokes an _underlyingInput.Process() – to signal it that it has
>>> bytes in its input buffer.
>>>
>>> -  

[jira] [Commented] (PROTON-1177) [proton-j] Source and Target interfaces are incomplete and confusing

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242959#comment-15242959
 ] 

Robbie Gemmell commented on PROTON-1177:


Having more of a think about this, it probably resulted from the layered nature 
of the protocol (where the transport layer, i.e links etc, doesnt actually 
define the source/target types, the messaging layer does), and the fact there 
are 2 very different types of Target (regular targets, and coordinator 
targets). We could possibly still decide that the Source interface should just 
go ahead and expose all the methods the Source impl facilitates, but the Target 
interface probably needs to remain essentially as it is.

> [proton-j] Source and Target interfaces are incomplete and confusing
> 
>
> Key: PROTON-1177
> URL: https://issues.apache.org/jira/browse/PROTON-1177
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.1
>    Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> The org.apache.qpid.proton.amqp.transport.Source and 
> org.apache.qpid.proton.amqp.transport.Target interfaces are used on the Link 
> interface setters/getters, however they container almost none of the methods 
> needed to use the Source and Target. The impls have all the necessary 
> methods, but folks would currently need to cast the values to them in order 
> to use in almost any meaningful way, and they exist in a completely different 
> package which makes them less than obvious. Finally, most of the interfaces 
> for engine objects have a factory in their interface for creating them, the 
> Source and Target ones do not, making their use less obvious again.
> Changing the existing interface/impl names/packages would break most existing 
> uses, so we probably want to avoid that, but we should at least update the 
> interfaces to contain the required methods, and perhaps add the equivalent 
> factories to make their creation more obvious.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1177) [proton-j] Source and Target interfaces are incomplete and confusing

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1177:
--

 Summary: [proton-j] Source and Target interfaces are incomplete 
and confusing
 Key: PROTON-1177
 URL: https://issues.apache.org/jira/browse/PROTON-1177
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.12.1
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.13.0


The org.apache.qpid.proton.amqp.transport.Source and 
org.apache.qpid.proton.amqp.transport.Target interfaces are used on the Link 
interface setters/getters, however they container almost none of the methods 
needed to use the Source and Target. The impls have all the necessary methods, 
but folks would currently need to cast the values to them in order to use in 
almost any meaningful way, and they exist in a completely different package 
which makes them less than obvious. Finally, most of the interfaces for engine 
objects have a factory in their interface for creating them, the Source and 
Target ones do not, making their use less obvious again.

Changing the existing interface/impl names/packages would break most existing 
uses, so we probably want to avoid that, but we should at least update the 
interfaces to contain the required methods, and perhaps add the equivalent 
factories to make their creation more obvious.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Qpid Proton 0.12.2

[Robbie Gemmell]

On 14 April 2016 at 18:28, Robbie Gemmell  wrote:
> Hi all,
>
> I have put up an RC for 0.12.2, please test it and vote accordingly.
>
> The source release archive and sig/checksums can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.2-rc1/
>
> Maven artifacts for the Java bits can be found in a temporary staging repo at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1072
>
> Other than version updates, there is only 1 changes since 0.12.1:
> https://issues.apache.org/jira/browse/PROTON-1171
>
> It was created from commit a9c41ef19664af2f928324024dab345c5958f85a
> on the 0.12.x branch, and is tagged as 0.12.2-rc1.
>
> Regards,
> Robbie

Making my +1 explicit.

I tested as follows:
- Verified the signature+checksums.
- Ran the CMake build+tests.
- Ran the Maven build+tests.
- Ran the Qpid JMS master build against it using the maven staging repo.
- Diffed against the 0.12.1 source release to verify only the expected
  changes + versions updates.

[VOTE] Release Qpid Proton 0.12.2

[Robbie Gemmell]

Hi all,

I have put up an RC for 0.12.2, please test it and vote accordingly.

The source release archive and sig/checksums can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.2-rc1/

Maven artifacts for the Java bits can be found in a temporary staging repo at:
https://repository.apache.org/content/repositories/orgapacheqpid-1072

Other than version updates, there is only 1 changes since 0.12.1:
https://issues.apache.org/jira/browse/PROTON-1171

It was created from commit a9c41ef19664af2f928324024dab345c5958f85a
on the 0.12.x branch, and is tagged as 0.12.2-rc1.

Regards,
Robbie

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

[Robbie Gemmell]

On 4 April 2016 at 16:03, Robbie Gemmell  wrote:
> There were 13 binding +1 votes received and another 2 from users, with
> no other votes received. The vote has passed.
>
> I'll chat with infra in the days ahead about how things proceed.
>
> Robbie

I've discussed this with infra.

Whilst they wouldn't normally like to subscribe folks to other lists,
given the particular situation they said they thought it OK to
subscribe the ~50 relevant folks who aren't on both lists to users@,
provided we are prompt in addressing any concerns from those affected.

The old mail archive should remain in its current place, and we should
be able to alias proton@ towards users@ afterwards to allow incoming
mails to the address to keep working.

If I haven't seen anyone object in the next couple days, I will proceed to:
- Announce the upcoming changes in their own thread, for any folks not
following this as we go.
 -- Including details how to subscribe to users@ in advance, or how to
unsubscribe from proton@ in advance if they dont want to be moved.
- Raise an INFRA JIRA to move the PROTON JIRA mails to dev@
- Raise an INFRA JIRA to move the Proton GitHub mirror integration mails to dev@
- Wait a week or so and then send request for the relevant subscribers
be added to users@, and proton@ be shut off.

Robbie

Re: Proton 0.12.2 release

[Robbie Gemmell]

Hi Frank,

That isn't one I can be much help with, being proton-c and Messenger,
neither of which I'm much use with. If someone looks at it in time,
great, but it seems more likely it won't squeeze into 0.12.2 at this
point. I was really just calling for any previously-committed bug
fixes folks wanted to have considered ahead of 0.13.0 (due later in
the month).

As an aside, it might be useful (but also might not..) if you put up
protocol trace logs of a run showing the issue you are seeing
(environment variable PN_TRACE_FRM=1 for proton-c, I think).

Robbie

On 13 April 2016 at 17:02, Frank Quinn  wrote:
> Hi Robbie,
>
> Would appreciate if someone could take a look at this one:
> https://issues.apache.org/jira/browse/PROTON-1169
>
> Cheers,
> Frank
>
> On Wed, Apr 13, 2016 at 3:11 PM, Robbie Gemmell 
> wrote:
>
>> Hi folks,
>>
>> I'd like to do a 0.12.2 release to incorporate a proton-j fix for
>> https://issues.apache.org/jira/browse/PROTON-1171. If all goes well
>> with feedback on that change I would propose to spin a release
>> candidate in the next day or so.
>>
>> If you have any targetted bug fixes you would like to include ahead of
>> the imminent 0.13.0 release cycle, now would be the time to think
>> about it.
>>
>> Robbie
>>

Proton 0.12.2 release

[Robbie Gemmell]

Hi folks,

I'd like to do a 0.12.2 release to incorporate a proton-j fix for
https://issues.apache.org/jira/browse/PROTON-1171. If all goes well
with feedback on that change I would propose to spin a release
candidate in the next day or so.

If you have any targetted bug fixes you would like to include ahead of
the imminent 0.13.0 release cycle, now would be the time to think
about it.

Robbie

[jira] [Updated] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1171:
---
Fix Version/s: 0.12.2

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> Here are my findings after debugging through this issue:
> -  When incoming bytes arrive on the SocketChannel – proton-j client 
> gets signaled by nio & as a result it unwinds the transport stack – as a 
> result all the TransportInput implementations performs its task on the Read 
> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
> frameparser etc).
> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
> reads(16k bytes) from _inputBuffer and the result - decoded bytes are written 
> to _decodedInputBuffer – as an intermediate buffer.
> -  It then flushes bytes from intermediate buffer to the next layer & 
> invokes an _underlyingInput.Process() – to signal it that it has bytes in its 
> input buffer.
> -  If the underlyingInput (lets say FrameParser) buffer size is small 
> – lets say 4k – then decodedInputBuffer will be left with 12k bytes & Over 
> time this accrues.
> The fix here is to flush decodedInputBuffer to the Next transport in the 
> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer is 
> empty. Here’s the pull request: 
> https://github.com/apache/qpid-proton/pull/73



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1171:
---
Affects Version/s: 0.12.1

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> Here are my findings after debugging through this issue:
> -  When incoming bytes arrive on the SocketChannel – proton-j client 
> gets signaled by nio & as a result it unwinds the transport stack – as a 
> result all the TransportInput implementations performs its task on the Read 
> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
> frameparser etc).
> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
> reads(16k bytes) from _inputBuffer and the result - decoded bytes are written 
> to _decodedInputBuffer – as an intermediate buffer.
> -  It then flushes bytes from intermediate buffer to the next layer & 
> invokes an _underlyingInput.Process() – to signal it that it has bytes in its 
> input buffer.
> -  If the underlyingInput (lets say FrameParser) buffer size is small 
> – lets say 4k – then decodedInputBuffer will be left with 12k bytes & Over 
> time this accrues.
> The fix here is to flush decodedInputBuffer to the Next transport in the 
> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer is 
> empty. Here’s the pull request: 
> https://github.com/apache/qpid-proton/pull/73



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reassigned PROTON-1171:
--

Assignee: Robbie Gemmell

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> Here are my findings after debugging through this issue:
> -  When incoming bytes arrive on the SocketChannel – proton-j client 
> gets signaled by nio & as a result it unwinds the transport stack – as a 
> result all the TransportInput implementations performs its task on the Read 
> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
> frameparser etc).
> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
> reads(16k bytes) from _inputBuffer and the result - decoded bytes are written 
> to _decodedInputBuffer – as an intermediate buffer.
> -  It then flushes bytes from intermediate buffer to the next layer & 
> invokes an _underlyingInput.Process() – to signal it that it has bytes in its 
> input buffer.
> -  If the underlyingInput (lets say FrameParser) buffer size is small 
> – lets say 4k – then decodedInputBuffer will be left with 12k bytes & Over 
> time this accrues.
> The fix here is to flush decodedInputBuffer to the Next transport in the 
> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer is 
> empty. Here’s the pull request: 
> https://github.com/apache/qpid-proton/pull/73



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1171:
---
Summary: [proton-j] transport SSL wrapper does not flush all decoded bytes 
to the underlying input  (was: proton-j: SimpleSSLTransportWrapper doesn't 
flush all bytes from the Decode buffer to the next transport buffer 
(_underlyingInput))

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
> Environment: Any
>Reporter: Sreeram Garlapati
>Priority: Critical
> Fix For: 0.13.0
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> Here are my findings after debugging through this issue:
> -  When incoming bytes arrive on the SocketChannel – proton-j client 
> gets signaled by nio & as a result it unwinds the transport stack – as a 
> result all the TransportInput implementations performs its task on the Read 
> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
> frameparser etc).
> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
> reads(16k bytes) from _inputBuffer and the result - decoded bytes are written 
> to _decodedInputBuffer – as an intermediate buffer.
> -  It then flushes bytes from intermediate buffer to the next layer & 
> invokes an _underlyingInput.Process() – to signal it that it has bytes in its 
> input buffer.
> -  If the underlyingInput (lets say FrameParser) buffer size is small 
> – lets say 4k – then decodedInputBuffer will be left with 12k bytes & Over 
> time this accrues.
> The fix here is to flush decodedInputBuffer to the Next transport in the 
> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer is 
> empty. Here’s the pull request: 
> https://github.com/apache/qpid-proton/pull/73



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton-j Reactor - Receiver

[Robbie Gemmell]

Ah, excellent. I had actually started on testing this myself a little
earlier, so I'll take a look and see whats what before continuing
tomorrow. On taking an initial better look at things I think the
change itself may need augmented to account for some other conditions
too, need to investigate further to be sure.

Robbie

On 11 April 2016 at 17:37, Garlapati Sreeram Kumar  wrote:
> Thanks a lot for the Response Robbie!
> Per your suggestion, added the CIT to the Pull Request (& yes, as you already 
> said – this issue is being tracked via JIRA - PROTON-1171).
>
> Thanks a lot for the Wonderful Collaboration!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Thursday, April 7, 2016 3:52 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
> hm...@microsoft.com<mailto:hm...@microsoft.com>
> Subject: Re: Proton-j Reactor - Receiver
>
> Hi Sree,
>
> Thanks for the analysis and PR, I'll try to take a proper look soon.
> It's not an area of the code I'm familiar with so I'll need to have a
> bit of a dig myself to see if the change seems ok. I'd note that any
> not-insignificant bug fix such as this should probably have a test
> with it (and a JIRA, though I see you have since created one of those)
> :)
>
> Robbie
>
> On 6 April 2016 at 01:23, Garlapati Sreeram Kumar  wrote:
>> Hello Robbie,
>>
>> We are using proton-j client with SSL and many of our customers are hitting 
>> this issue.
>> Here are my findings after debugging through this issue:
>>
>> -  When incoming bytes arrive on the SocketChannel – proton-j client 
>> gets signaled by nio & as a result it unwinds the transport stack – as a 
>> result all the TransportInput implementations performs its task on the Read 
>> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
>> frameparser etc).
>>
>> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
>> reads(16k bytes) from _inputBuffer and the result - decoded bytes are 
>> written to _decodedInputBuffer – as an intermediate buffer.
>>
>> -  It then flushes bytes from intermediate buffer to the next layer 
>> & invokes an _underlyingInput.Process() – to signal it that it has bytes in 
>> its input buffer.
>>
>> -  If the underlyingInput (lets say FrameParser) buffer size is 
>> small – lets say 4k – then decodedInputBuffer will be left with 12k bytes & 
>> Over time this accrues.
>>
>> The fix here is to flush decodedInputBuffer to the Next transport in the 
>> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer 
>> is empty. Here’s the pull request - 
>> https://github.com/apache/qpid-proton/pull/73
>>
>> Pl. let me know if we need to do more to fix this issue comprehensively.
>>
>> Thx!
>> Sree
>>
>> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
>> Sent: Thursday, March 31, 2016 9:19 AM
>> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
>> Subject: Re: Proton-j Reactor - Receiver
>>
>> On 31 March 2016 at 04:32, Garlapati Sreeram Kumar  wrote:
>>> Hello All!
>>>
>>> I am using Proton-J reactor API (Version 0.12.0) for receiving AMQP 
>>> Messages (from Microsoft Azure Event Hubs): 
>>> https://github.com/Azure/azure-event-hubs/blob/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp/ReceiveLinkHandler.java#L124
>>>
>>> Am using the onDelivery(Event) callback to receive messages. I really 
>>> appreciate your help with this issue/behavior:
>>>
>>> ISSUE: I noticed that the last few messages on the Queue are not being 
>>> issued to onDelivery(Event) callback by the Reactor
>>> - Then, I went ahead and enabled proton Frame tracing (PN_TRACE_FRM=1) and 
>>> discovered that the Transfer frames corresponding to those messages were 
>>> not even delivered to Client. Then, I looked at our Service Proton Frames 
>>> and can clearly see that they are being delivered by the Service. And other 
>>> AMQP clients (for ex: .net client can see the Transfer frames)
>>> - Is this a known behavior?
>>> Does Reactor code path disable Nagle on underlying socket – could this be 
>>> related? or is there any other Configuration that we should be setting to 
>>> see all Transfer frames received on the Socket?
>>>
>>> Please advice.
>>>
>>> Thanks a lot in Advance!
>>> Sree
>>>
>>> Sent from Mail for Windows 10
>>>
>>
>> I'm not aware of anyone else reporting anything like that. I don't see
>> anything in the code suggesting the reactor sets TCP_NODELAY trueon
>> the socket, but I wouldn't think that should matter here.
>>
>> The frame trace logging is done after the bytes are given to the
>> Transport and are processed into frames, so a lack of logging could
>> suggest various things such as they didnt actually get there, they
>> werent processed, something went wrong before they did/were, something
>> went wrong decoding them, etc. Its hard to say much more without more
>> info.
>>
>> Robbie

[jira] [Updated] (PROTON-1168) 2-way Authentication via Certificates Fails in Proton-J

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1168:
---
Attachment: ssl_logs1.tar.gz

Attaching ssl_logs1.tar.gz with console logs from the broker and proton-j 
reactor client using -Djavax.net.debug=ssl to turn ssl trace logging on, plus 
PN_TRACE_FRM=true to turn on AMQP trace logging from proton. Also inludes a 
screenshot from wireshark of the run showing the client cert being sent.

> 2-way Authentication via Certificates Fails in Proton-J
> ---
>
> Key: PROTON-1168
> URL: https://issues.apache.org/jira/browse/PROTON-1168
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
> Environment: Ubuntu 15.10 & RHEL 7
> Qpid Dispatch 0.5 & 0.6
> Proton-C 0.12 and Proton-J 0.12
>Reporter: Jack Gibson
>Priority: Critical
> Attachments: PROTON-1168_reactor_ssl.patch, 
> my_qdrouterd_B_standalone.conf, recv_with_ssl.c, send_with_ssl.c, 
> ssl_logs1.tar.gz
>
>
> Using qpid dispatch, we are unable to enable 2 way SSL with proton-j but able 
> to with proton-c.
> To reproduce use the attached config to enable 2 WAY SSL with “authenticate 
> Peer” flag set to TRUE.
> Restart the qdrouterd instance to pick up the config changes.
> Make the client send a message based on the AMQP-CLIENT library (which uses 
> Proton J). 
> Client Error Message: from the log file
> AMQP framing error
> EventImpl{type=TRANSPORT_ERROR, context=TransportImpl 
> [_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionImpl@6ef351a0,
>  org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
> Server Error Message: from the log file
> =64, totalFreeToHeap=0, transferBatchSize=64, 
> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t, typeSize=56)
> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent on 
> $management
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered: 
> $management
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered: 
> $management
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: 
> FixedAddressEntity(bias=closest, fanout=single, identity=fixedAddress/0, 
> name=fixedAddress/0, prefix=/, type=org.apache.qpid.dispatch.fixedAddress)
> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/ phase=0 
> fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE 
> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: 
> ListenerEntity(addr=0.0.0.0, authenticatePeer=True, 
> certDb=/home/vsharda/protected/pprootca_cert.pem, 
> certFile=/home/vsharda/protected/generic_cert.pem, 
> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16, 
> keyFile=/home/vsharda/protected/generic_key.pem, maxFrameSize=65536, 
> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs, 
> port=20009, requireEncryption=True, requireSsl=True, role=normal, 
> saslMechanisms=EXTERNAL, stripAnnotations=both, 
> type=org.apache.qpid.dispatch.listener)
> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:20009 
> proto=any role=normal
> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: 
> ConsoleEntity(identity=console/0, name=console/0, 
> type=org.apache.qpid.dispatch.console, wsport=5673)
> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads Running
> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming connection from 
> 10.225.90.106:51196 to 0.0.0.0:20009
> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming 
> connection from 10.225.90.106:51196 to 0.0.0.0:20009
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket created.
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection detected
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data size=162 )
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO Layer, 0 
> left over
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl() returning 162
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from BIO Layer
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 
> 3651
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
> Wed Mar 30

Re: Proton-j Reactor - Receiver

[Robbie Gemmell]

Hi Sree,

Thanks for the analysis and PR, I'll try to take a proper look soon.
It's not an area of the code I'm familiar with so I'll need to have a
bit of a dig myself to see if the change seems ok. I'd note that any
not-insignificant bug fix such as this should probably have a test
with it (and a JIRA, though I see you have since created one of those)
:)

Robbie

On 6 April 2016 at 01:23, Garlapati Sreeram Kumar  wrote:
> Hello Robbie,
>
> We are using proton-j client with SSL and many of our customers are hitting 
> this issue.
> Here are my findings after debugging through this issue:
>
> -  When incoming bytes arrive on the SocketChannel – proton-j client 
> gets signaled by nio & as a result it unwinds the transport stack – as a 
> result all the TransportInput implementations performs its task on the Read 
> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
> frameparser etc).
>
> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
> reads(16k bytes) from _inputBuffer and the result - decoded bytes are written 
> to _decodedInputBuffer – as an intermediate buffer.
>
> -  It then flushes bytes from intermediate buffer to the next layer & 
> invokes an _underlyingInput.Process() – to signal it that it has bytes in its 
> input buffer.
>
> -  If the underlyingInput (lets say FrameParser) buffer size is small 
> – lets say 4k – then decodedInputBuffer will be left with 12k bytes & Over 
> time this accrues.
>
> The fix here is to flush decodedInputBuffer to the Next transport in the 
> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer is 
> empty. Here’s the pull request - https://github.com/apache/qpid-proton/pull/73
>
> Pl. let me know if we need to do more to fix this issue comprehensively.
>
> Thx!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Thursday, March 31, 2016 9:19 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Subject: Re: Proton-j Reactor - Receiver
>
> On 31 March 2016 at 04:32, Garlapati Sreeram Kumar  wrote:
>> Hello All!
>>
>> I am using Proton-J reactor API (Version 0.12.0) for receiving AMQP Messages 
>> (from Microsoft Azure Event Hubs): 
>> https://github.com/Azure/azure-event-hubs/blob/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp/ReceiveLinkHandler.java#L124
>>
>> Am using the onDelivery(Event) callback to receive messages. I really 
>> appreciate your help with this issue/behavior:
>>
>> ISSUE: I noticed that the last few messages on the Queue are not being 
>> issued to onDelivery(Event) callback by the Reactor
>> - Then, I went ahead and enabled proton Frame tracing (PN_TRACE_FRM=1) and 
>> discovered that the Transfer frames corresponding to those messages were not 
>> even delivered to Client. Then, I looked at our Service Proton Frames and 
>> can clearly see that they are being delivered by the Service. And other AMQP 
>> clients (for ex: .net client can see the Transfer frames)
>> - Is this a known behavior?
>> Does Reactor code path disable Nagle on underlying socket – could this be 
>> related? or is there any other Configuration that we should be setting to 
>> see all Transfer frames received on the Socket?
>>
>> Please advice.
>>
>> Thanks a lot in Advance!
>> Sree
>>
>> Sent from Mail for Windows 10
>>
>
> I'm not aware of anyone else reporting anything like that. I don't see
> anything in the code suggesting the reactor sets TCP_NODELAY trueon
> the socket, but I wouldn't think that should matter here.
>
> The frame trace logging is done after the bytes are given to the
> Transport and are processed into frames, so a lack of logging could
> suggest various things such as they didnt actually get there, they
> werent processed, something went wrong before they did/were, something
> went wrong decoding them, etc. Its hard to say much more without more
> info.
>
> Robbie

Re: Amqp-ConnProp: user-agent

[Robbie Gemmell]

Each component simply sets the "product" and "version" entries into
its connection properties map, which use a map with amqp symbol keys,
e.g Symbol.valueOf("product"); in the case of proton-j.

For example, the JMS client does it here:
https://github.com/apache/qpid-jms/blob/0.8.0/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/builders/AmqpConnectionBuilder.java#L106

Robbie

On 5 April 2016 at 18:22, Garlapati Sreeram Kumar  wrote:
> Can you please point me to those Symbols. I would love to not re-invent & 
> reuse those …
>
> Thx!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Tuesday, April 5, 2016 10:14 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Subject: Re: Amqp-ConnProp: user-agent
>
> Many of the Qpid components advertise "product" and "version"
> connection properties containing strings with the appropriate details.
> Those [Symbol] keys were chosen because they happened to be names
> specified in the older AMQP 0-x specs, and so matched what some of the
> components were already using.
>
> Robbie
>
> On 5 April 2016 at 18:02, Garlapati Sreeram Kumar  wrote:
>> Hello Folks!
>>
>> In our (Microsoft Azure EventHubs) java library, we are looking for a way to 
>> identify which AmqpClient did the call originate from.
>> We want to use this information to:
>> 1) Identify client stack while troubleshooting Service issues - for ex: a 
>> bug in implementation of AmqpProtocol stack
>> 2) collect telemetry on how many different clients are talking to our 
>> service (which will open-up data insights in future, for ex: investing our 
>> efforts on the right client echo system etc.,)
>>
>> To achieve this - we are planning to introduce a Property (on AmqpConnection 
>> -  [AMQP-CONNPROP]) to identify UserAgent.
>> - We chose “Connection properties” – as this would be one-time per 
>> connection and will not add extra overhead per message.
>>
>> I believe this would be a common requirement to all Amqp implementations. 
>> Are you folks aware of any proposal to add a standard property to Amqp 
>> Protocol Specification (or) is there already one that you folks use for this 
>> purpose – in any of the Clients – which we can re-use and collectively 
>> propose to the protocol spec.
>>
>> Thanks a lot for the Wonderful collaboration!
>> Sree

Re: Amqp-ConnProp: user-agent

[Robbie Gemmell]

Many of the Qpid components advertise "product" and "version"
connection properties containing strings with the appropriate details.
Those [Symbol] keys were chosen because they happened to be names
specified in the older AMQP 0-x specs, and so matched what some of the
components were already using.

Robbie

On 5 April 2016 at 18:02, Garlapati Sreeram Kumar  wrote:
> Hello Folks!
>
> In our (Microsoft Azure EventHubs) java library, we are looking for a way to 
> identify which AmqpClient did the call originate from.
> We want to use this information to:
> 1) Identify client stack while troubleshooting Service issues - for ex: a bug 
> in implementation of AmqpProtocol stack
> 2) collect telemetry on how many different clients are talking to our service 
> (which will open-up data insights in future, for ex: investing our efforts on 
> the right client echo system etc.,)
>
> To achieve this - we are planning to introduce a Property (on AmqpConnection 
> -  [AMQP-CONNPROP]) to identify UserAgent.
> - We chose “Connection properties” – as this would be one-time per connection 
> and will not add extra overhead per message.
>
> I believe this would be a common requirement to all Amqp implementations. Are 
> you folks aware of any proposal to add a standard property to Amqp Protocol 
> Specification (or) is there already one that you folks use for this purpose – 
> in any of the Clients – which we can re-use and collectively propose to the 
> protocol spec.
>
> Thanks a lot for the Wonderful collaboration!
> Sree

[jira] [Updated] (PROTON-1168) 2-way Authentication via Certificates Fails in Proton-J

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1168:
---
Attachment: PROTON-1168_reactor_ssl.patch

I posted the following reply on the users list thread\[1\] yesterday, copying 
here for later ease and also attaching the patch contents from the referenced 
pastebin in case anyone has problems with the link.

{quote}
Hi Jack,

This isn't something I had tried before, but I was able to establish a
connecting using the master/0.13.0-SNAPSHOT proton-j reactor and send
messages to a 6.0.x/6.0.2-SNAPSHOT Qpid Java broker that was
configured to require SSL client certs and use the EXTERNAL SASL
mechanism (I didn't have a Dispatch set up appropriately and that was
easier for me, plus the issue described seemed to be client-side).

I had to make the following changes to the existing Send example to
add a required dependency, actually set where the sender is attaching,
change the sasl mech, and configure use of ssl plus provide the
cert/trust details:

http://pastebin.com/TR5azYFR

I notice that the C code you attached to the JIRA (PROTON-1168 for
interested folks) is actually using Messenger with proton-c, and not
the Reactor as mentioned here for proton-j. I'm not sure if your Java
code is actually doing the same since you didn't include it, but that
isn't something I have tried either in any case. I do seem to recall
previous discussion around proton-c Messenger that it isn't actually
possible to set the particular sasl mechanism with Messenger (though
that would presumably be a separate issue from the one the Dispatch
logs suggest occurred, of not sending a cert as requested/required).

Robbie
{quote}

\[1\] 
http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpTn2smMXbCVNQCLxo5B6S%3D5KUzmbQwozti1%2BQb4ezRS8Q%40mail.gmail.com%3E

> 2-way Authentication via Certificates Fails in Proton-J
> ---
>
> Key: PROTON-1168
> URL: https://issues.apache.org/jira/browse/PROTON-1168
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
> Environment: Ubuntu 15.10 & RHEL 7
> Qpid Dispatch 0.5 & 0.6
> Proton-C 0.12 and Proton-J 0.12
>Reporter: Jack Gibson
>Priority: Critical
> Attachments: PROTON-1168_reactor_ssl.patch, 
> my_qdrouterd_B_standalone.conf, recv_with_ssl.c, send_with_ssl.c
>
>
> Using qpid dispatch, we are unable to enable 2 way SSL with proton-j but able 
> to with proton-c.
> To reproduce use the attached config to enable 2 WAY SSL with “authenticate 
> Peer” flag set to TRUE.
> Restart the qdrouterd instance to pick up the config changes.
> Make the client send a message based on the AMQP-CLIENT library (which uses 
> Proton J). 
> Client Error Message: from the log file
> AMQP framing error
> EventImpl{type=TRANSPORT_ERROR, context=TransportImpl 
> [_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionImpl@6ef351a0,
>  org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
> Server Error Message: from the log file
> =64, totalFreeToHeap=0, transferBatchSize=64, 
> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t, typeSize=56)
> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent on 
> $management
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered: 
> $management
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered: 
> $management
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: 
> FixedAddressEntity(bias=closest, fanout=single, identity=fixedAddress/0, 
> name=fixedAddress/0, prefix=/, type=org.apache.qpid.dispatch.fixedAddress)
> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/ phase=0 
> fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE 
> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: 
> ListenerEntity(addr=0.0.0.0, authenticatePeer=True, 
> certDb=/home/vsharda/protected/pprootca_cert.pem, 
> certFile=/home/vsharda/protected/generic_cert.pem, 
> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16, 
> keyFile=/home/vsharda/protected/generic_key.pem, maxFrameSize=65536, 
> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs, 
> port=20009, requireEncryption=True, requireSsl=True, role=normal, 
> saslMechanisms=EXTERNAL, stripAnnotations=both, 
> type=org.apache.qpid.dispatch.listener)
> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:20009 
> proto=any role=normal
> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
> Wed Mar 30 12:00:47 2

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

[Robbie Gemmell]

There were 13 binding +1 votes received and another 2 from users, with
no other votes received. The vote has passed.

I'll chat with infra in the days ahead about how things proceed.

Robbie

Re: Proton-j Reactor - Receiver

[Robbie Gemmell]

On 31 March 2016 at 04:32, Garlapati Sreeram Kumar  wrote:
> Hello All!
>
> I am using Proton-J reactor API (Version 0.12.0) for receiving AMQP Messages 
> (from Microsoft Azure Event Hubs): 
> https://github.com/Azure/azure-event-hubs/blob/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp/ReceiveLinkHandler.java#L124
>
> Am using the onDelivery(Event) callback to receive messages. I really 
> appreciate your help with this issue/behavior:
>
> ISSUE: I noticed that the last few messages on the Queue are not being issued 
> to onDelivery(Event) callback by the Reactor
> - Then, I went ahead and enabled proton Frame tracing (PN_TRACE_FRM=1) and 
> discovered that the Transfer frames corresponding to those messages were not 
> even delivered to Client. Then, I looked at our Service Proton Frames and can 
> clearly see that they are being delivered by the Service. And other AMQP 
> clients (for ex: .net client can see the Transfer frames)
> - Is this a known behavior?
> Does Reactor code path disable Nagle on underlying socket – could this be 
> related? or is there any other Configuration that we should be setting to see 
> all Transfer frames received on the Socket?
>
> Please advice.
>
> Thanks a lot in Advance!
> Sree
>
> Sent from Mail for Windows 10
>

I'm not aware of anyone else reporting anything like that. I don't see
anything in the code suggesting the reactor sets TCP_NODELAY trueon
the socket, but I wouldn't think that should matter here.

The frame trace logging is done after the bytes are given to the
Transport and are processed into frames, so a lack of logging could
suggest various things such as they didnt actually get there, they
werent processed, something went wrong before they did/were, something
went wrong decoding them, etc. Its hard to say much more without more
info.

Robbie

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

[Robbie Gemmell]

Agreed, we can include something to that effect on the website
alongside the list details.

Robbie
(who very nearly missed out a list after initially forgetting to
reply-all, having just called that out earlier...)

On 30 March 2016 at 11:30, 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-mail :-) ).
>
> -- Rob
>
> On 30 March 2016 at 11:25, Robbie Gemmell  wrote:
>
>> Hello folks,
>>
>> Many moons ago, a seperate mailing list was established for Proton,
>> back when it was purely a protocol engine other components would use.
>> Its scope has since expanded beyond that and the separate mailing list
>> has I feel been an increasing source of confusion and hassle of late
>> more than anything else. Collapsing it into the other larger existing
>> lists we have (that the traffic would otherwise have been on) seems to
>> me like it would be an improvement across the board, and as such I
>> have called this vote.
>>
>> I would propose that discussion (such as this) would head to the
>> users@q.a.o list to join the similar/related/duplicate traffic already
>> present, with remaining things going to the dev@q.a.o list as
>> consistent with that list (e.g JIRA, GitHub integration mails,
>> ReviewBoard, though the latter was never actually directed to proton@
>> to begin with..).
>>
>> Whilst redirecting JIRA etc emails should be easy enough (has been
>> done before), I dont know what the precise options are regarding
>> existing mail subscriptions to the list. There are significantly more
>> subscribers to users@ than proton@, and many are duplicates, but some
>> are not. I'd need to discuss options with infra, but first things
>> first, the vote.
>>
>> I have gone straight to a vote on this because I feel this has already
>> been discussed enough previously over time that many people will have
>> already thought about it enough to quickly vote one way or the other,
>> and it is past time to act on it if things head that way. Obviously
>> things can be further discusssed at this point also if desired.
>>
>> Note that both users@ and proton@ are in the recipients. I expect the
>> thread will splinter when someone forgets to reply-all, as almost all
>> cross-posted thread on the lists do, but at least it can start on both
>> for visibility to all.
>>
>> Robbie
>>

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

[Robbie Gemmell]

On 30 March 2016 at 11:25, Robbie Gemmell  wrote:
> Hello folks,
>
> Many moons ago, a seperate mailing list was established for Proton,
> back when it was purely a protocol engine other components would use.
> Its scope has since expanded beyond that and the separate mailing list
> has I feel been an increasing source of confusion and hassle of late
> more than anything else. Collapsing it into the other larger existing
> lists we have (that the traffic would otherwise have been on) seems to
> me like it would be an improvement across the board, and as such I
> have called this vote.
>
> I would propose that discussion (such as this) would head to the
> users@q.a.o list to join the similar/related/duplicate traffic already
> present, with remaining things going to the dev@q.a.o list as
> consistent with that list (e.g JIRA, GitHub integration mails,
> ReviewBoard, though the latter was never actually directed to proton@
> to begin with..).
>
> Whilst redirecting JIRA etc emails should be easy enough (has been
> done before), I dont know what the precise options are regarding
> existing mail subscriptions to the list. There are significantly more
> subscribers to users@ than proton@, and many are duplicates, but some
> are not. I'd need to discuss options with infra, but first things
> first, the vote.
>
> I have gone straight to a vote on this because I feel this has already
> been discussed enough previously over time that many people will have
> already thought about it enough to quickly vote one way or the other,
> and it is past time to act on it if things head that way. Obviously
> things can be further discusssed at this point also if desired.
>
> Note that both users@ and proton@ are in the recipients. I expect the
> thread will splinter when someone forgets to reply-all, as almost all
> cross-posted thread on the lists do, but at least it can start on both
> for visibility to all.
>
> Robbie


Making my +1 explicit.

Robbie

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

[Robbie Gemmell]

Hello folks,

Many moons ago, a seperate mailing list was established for Proton,
back when it was purely a protocol engine other components would use.
Its scope has since expanded beyond that and the separate mailing list
has I feel been an increasing source of confusion and hassle of late
more than anything else. Collapsing it into the other larger existing
lists we have (that the traffic would otherwise have been on) seems to
me like it would be an improvement across the board, and as such I
have called this vote.

I would propose that discussion (such as this) would head to the
users@q.a.o list to join the similar/related/duplicate traffic already
present, with remaining things going to the dev@q.a.o list as
consistent with that list (e.g JIRA, GitHub integration mails,
ReviewBoard, though the latter was never actually directed to proton@
to begin with..).

Whilst redirecting JIRA etc emails should be easy enough (has been
done before), I dont know what the precise options are regarding
existing mail subscriptions to the list. There are significantly more
subscribers to users@ than proton@, and many are duplicates, but some
are not. I'd need to discuss options with infra, but first things
first, the vote.

I have gone straight to a vote on this because I feel this has already
been discussed enough previously over time that many people will have
already thought about it enough to quickly vote one way or the other,
and it is past time to act on it if things head that way. Obviously
things can be further discusssed at this point also if desired.

Note that both users@ and proton@ are in the recipients. I expect the
thread will splinter when someone forgets to reply-all, as almost all
cross-posted thread on the lists do, but at least it can start on both
for visibility to all.

Robbie

Re: Proton-j: SendLink flow control

[Robbie Gemmell]

On 25 March 2016 at 19:06, Garlapati Sreeram Kumar  wrote:
> Hello All!
>
> We are using the Proton-J 0.12.0 Amqp library – and built Event Hubs Java 
> Amqp Client on Reactor framework - 
> https://github.com/Azure/azure-event-hubs/tree/master/java.
>
> Please validate my assumption w.r.to Sender Flow control:
> - Current Expectation from Reactor APIs is that – on Sender Link – wait for 
> the onLinkFlow(Event) and rely on
> “event.getLInk().getRemoteCredit()”
> to know how many more messages can be Sent on the Link. Proton amqp layer 
> will interpret the FlowFrame and do-the-math of deliveryCounts of Sender and 
> Receiver and the New Credit issued by the Sender.
> - This API Contract essentially means that, Frameworks building atop Reactor 
> API – will need to implement FlowControl (will queue-up all the Messages 
> until it receives the FlowFrame).
>
> Do you folks have plans to move this functionality of flow control into the 
> Proton-API offering – as every implementation will need it.
>
> Thanks!
> Sree
>
>

Hi Sree,

The above seems essentially correct yes. The sender/engine can
actually buffer messages beyond that which it has credit to send and
then send them later (if credit ever arrives), but I'm not sure how
much you would typically want to take advantage of that, versus
prefering some sort of application/client-level handling that can be
made to suit your particular needs w.r.t any buffering / pausing of
message sources / blocking etc you might want to do.

Robbie

Re: SASL

[Robbie Gemmell]

Hi Kai,

As Gordon noted, proton can be used in different ways. In the case
where it is used purely as an AMQP protocol engine with e.g TLS being
provided by the external IO being used with it, getting the Principal
would currently fall to that code rather than proton. That is how
proton-j currently sees most of its usage (or at least, the usage I'm
actually familiar with).

The SASL/TLS related API's in proton-c have seen major rework since
earlier releases, but the equivalents in proton-j have not and now
differ substantially. I dont see an equivalent of the APIs Gordon
referenced below, however as above its likely those may not apply in
the particular usage context anyway when it comes to proton-j.

I don't think there is much in the way of examples in this area I'm
afraid other than the code of components using it (e.g the ActiveMQ
brokers, or the Qpid JMS client).

Robbie

On 29 February 2016 at 17:11, Kai  wrote:
> Thanks for your replies, Gordon. I didn't explicitly mention that I was
> interested in accessing the Principal from Java but you seem to have
> guessed that already :-) However, the question is still open, right?
>
> Kai
>
> On Mon, Feb 29, 2016 at 6:04 PM Gordon Sim  wrote:
>
>> On 29/02/16 14:56, Gordon Sim wrote:
>> > On 28/02/16 15:59, Kai wrote:
>> >> I was trying to find some examples or documentation regarding how to use
>> >> SASL in Proton but did not find anything so far. Can you point me into
>> >> the
>> >> right direction? In particular I am interested in determining the
>> >> identity
>> >> of a client that has been authenticated as part of a TLS handshake (if
>> >> that's possible) ...
>> >
>> > In the c api, pn_ssl_get_remote_subject() gets you the subject field of
>> > the certificate. In python that is exposed as a remote_subject property
>> > on the ssl object associated with the transport.
>> >
>> > I'm not sure if/how the java api's offer the behaviour, anyone else able
>> > to comment on that?
>>
>> One thing to add/point out here is that proton can be used in different
>> ways. One use is simply as a protocol engine, with bytes pumped in and
>> out by an external io component. In that usage model, you would use
>> java's built in support for SSL (as part of the io).
>>

Re: Proton-J Reactor sending delay

[Robbie Gemmell]

It looks to already be configurable, e.g. you could call the same
method to update the value from the thread running the reactor,
perhaps in the onReactorInit() handler. That said, I'm not sure youd
would normally want to, except maybe to increase it, which is
presumably not what you were thinking here when asking.

My limited understanding of it is that the timeout should only really
have an effect when the reactor thinks it has nothing else to do, with
the value dictating how long the reactor awaits something new to do,
e.g new data arriving to give it work, before it fires off another
quiesced event. As such I would guess that in this case the reactor is
either incorrect in thinking that it has nothing to do, or perhaps
isn't being used in the intended/required fashion (see sub-thread from
Ken's mail).

Robbie

On 25 February 2016 at 17:45, Andrew Buckley  wrote:
> Ah, thanks Robbie. Yes I do now notice the 3141ms timeout inside run(). Are 
> there plans to make that timeout configurable? At least from my point of 
> view, 3 seconds is quite a long time to wait between calling send and the 
> action actually being performed, and applications using the Reactor do suffer 
> a bit of a blow in performance because of this.
>
> Thanks,
> -Andrew
>
> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Monday, February 15, 2016 3:47 AM
> To: d...@qpid.apache.org; proton@qpid.apache.org
> Subject: Re: Proton-J Reactor sending delay
>
> On 13 February 2016 at 00:28, Andrew Buckley  wrote:
>> I'm using the reactor with Proton-J and have noticed that there is a 2-4 
>> second delay between when I call send() on a particular link and when that 
>> transfer frame actually goes out. Is this expected behavior? If so, are 
>> there plans to improve on this? And if not, have you seen this in any other 
>> scenario and might you have any ideas what could be causing it?
>>
>> Thanks,
>> -Andrew Buckley
>>
>
> Hi Andrew,
>
> While im no expert on the reactor, I'd be surprised if that was expected, and 
> I can't say I'm aware of it being mentioned before.
>
> One thing that springs to mind from previous discussion [about proton-c 
> reactor] is that when the reactor has a particular thread dedicated to 
> running it, it sets a 3141ms timeout on its selector meaning it wakes up at 
> that period when it is 'quiesced' (has nothing to do). Seems like perhaps 
> that could be related given your note of 2-4sec.
>
> Do you have an example showing the behaviour?
>
> Robbie
>
> (added proton@ as well, in case anyone only paying attention there has 
> thoughts)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional 
> commands, e-mail: dev-h...@qpid.apache.org
>

Re: Proton-J Reactor sending delay

[Robbie Gemmell]

Yes, where/when/how send is being called might be important, thats one
reason why I asked for an example showing the behaviour.

The java reactor does also has a wakeup method to prod the thread
blocked in process() to life, which notes itself to be the only method
you can call at the same time another thread is using the reactor.

Robbie

On 25 February 2016 at 19:03, Ken Giusti  wrote:
>
> Andrew - are you calling send() from within a reactor callback?  Or from 
> another thread?
>
> I'm not very familiar with the Java reactor, but the C reactor has a method 
> called pn_reactor_wakeup() which causes it to immediately return from the 
> blocking select() call.
>
> -K
>
> - Original Message -
>> From: "Andrew Buckley" 
>> To: d...@qpid.apache.org, proton@qpid.apache.org
>> Sent: Thursday, February 25, 2016 12:45:04 PM
>> Subject: RE: Proton-J Reactor sending delay
>>
>> Ah, thanks Robbie. Yes I do now notice the 3141ms timeout inside run(). Are
>> there plans to make that timeout configurable? At least from my point of
>> view, 3 seconds is quite a long time to wait between calling send and the
>> action actually being performed, and applications using the Reactor do
>> suffer a bit of a blow in performance because of this.
>>
>> Thanks,
>> -Andrew
>>
>> -Original Message-
>> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
>> Sent: Monday, February 15, 2016 3:47 AM
>> To: d...@qpid.apache.org; proton@qpid.apache.org
>> Subject: Re: Proton-J Reactor sending delay
>>
>> On 13 February 2016 at 00:28, Andrew Buckley  wrote:
>> > I'm using the reactor with Proton-J and have noticed that there is a 2-4
>> > second delay between when I call send() on a particular link and when that
>> > transfer frame actually goes out. Is this expected behavior? If so, are
>> > there plans to improve on this? And if not, have you seen this in any
>> > other scenario and might you have any ideas what could be causing it?
>> >
>> > Thanks,
>> > -Andrew Buckley
>> >
>>
>> Hi Andrew,
>>
>> While im no expert on the reactor, I'd be surprised if that was expected, and
>> I can't say I'm aware of it being mentioned before.
>>
>> One thing that springs to mind from previous discussion [about proton-c
>> reactor] is that when the reactor has a particular thread dedicated to
>> running it, it sets a 3141ms timeout on its selector meaning it wakes up at
>> that period when it is 'quiesced' (has nothing to do). Seems like perhaps
>> that could be related given your note of 2-4sec.
>>
>> Do you have an example showing the behaviour?
>>
>> Robbie
>>
>> (added proton@ as well, in case anyone only paying attention there has
>> thoughts)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional
>> commands, e-mail: dev-h...@qpid.apache.org
>>
>>
>
> --
> -K
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

[jira] [Created] (PROTON-1146) [proton-j] fixes for issues identified by Coverity

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1146:
--

 Summary: [proton-j] fixes for issues identified by Coverity
 Key: PROTON-1146
 URL: https://issues.apache.org/jira/browse/PROTON-1146
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.12.0
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
Priority: Minor
 Fix For: 0.13.0


Holder for small fixes/improvements identified by Coverity



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: How does one setup a topic using qpid-config tyo satisfy QPID JMS requirements?

[Robbie Gemmell]

The topic config in the jndi.properties file is just an example, only
the queue is used by the code for the examples.

But to answer the question, one model of a topic in qpidd would be to
create an exchange of that name, of either topic or fanout type.

Robbie

On 22 February 2016 at 17:47, Flores, Paul A.  wrote:
> Using qpid-config to set up a queue prior to trying the helloworld example 
> from QPID JMS.
>
>
>
> But the jndi properties expects a topic along with a queue.
>
>
>
> How do I set up a topic using qpid-config?
>
>
>
> Thanks for your help!
>
>
>
> Paul

Re: Help?!: Qpid JMS 0.6.0 HelloWorld example issue

[Robbie Gemmell]

Glad to hear you got past the issue with your jndi config. Jakub's
mail covers your question on qpid-config.

Note you can also have the broker auto-create queues as needed using
the CLI option I mentioned in your recent thread on the users list.

As an aside, the current release of the client has been 0.7.0 for a
couple months, and the 0.8.0 release just passed its vote now and will
be reflected on the site come Monday. It will sync to maven central in
the hours ahead, but is available now via repository.apache.org, or
you can find an archive here also:
http://apache.org/dist/qpid/jms/0.8.0/

Robbie

On 19 February 2016 at 21:28, Flores, Paul A.  wrote:
> I got that far now I am trying to create a queue.  Don't seem to able to find 
> qpid-config.  In what release/download is that found?
>
> 
> From: Timothy Bish [tabish...@gmail.com]
> Sent: Friday, February 19, 2016 2:41 PM
> To: proton@qpid.apache.org
> Subject: Re: Help?!: Qpid JMS 0.6.0 HelloWorld example issue
>
> On 02/19/2016 12:39 PM, Flores, Paul A. wrote:
>> Trying to get the HelloWorld example that is found with the QPID JMS 0.6.0 
>> Release to work.
>>
>>
>>
>> When I go to run it  I am seeing the following.
>>
>>
>>
>> Can some one point me to a resolution? I am running out of hair to pull!
>>
>
> Try changing you URI in the jndi.properties to 'amqp://localhost:5672'
> not the 'amqp' is not capitalized.
>
>>
>> Thanks.
>>
>>
>>
>> Paul
>>
>>
>>
>> 2016-02-19 10:32:47,256 [main   ] - ERROR ProviderFactory
>> - Failed to create Provider instance for AMQP, due to: 
>> java.io.IOException: Provider scheme NOT recognized: [AMQP]
>> 2016-02-19 10:32:47,259 [main   ] - ERROR JmsConnectionFactory   
>> - Failed to create JMS Provider instance for: AMQP
>> Caught exception, exiting.
>> javax.jms.JMSException: Failed to create connection to: AMQP://localhost:5672
>> at 
>> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:66)
>> at 
>> org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:165)
>> at HelloWorld.main(HelloWorld.java:51)
>> Caused by: java.io.IOException: Provider scheme NOT recognized: [AMQP]
>> at 
>> org.apache.qpid.jms.provider.ProviderFactory.findProviderFactory(ProviderFactory.java:104)
>> at 
>> org.apache.qpid.jms.provider.ProviderFactory.create(ProviderFactory.java:70)
>> at 
>> org.apache.qpid.jms.JmsConnectionFactory.createProvider(JmsConnectionFactory.java:221)
>> at 
>> org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:161)
>> ... 1 more
>> Caused by: org.apache.qpid.jms.util.ResourceNotFoundException: Could not 
>> find factory resource: META-INF/services/org/apache/qpid/jms/provider/AMQP
>> at 
>> org.apache.qpid.jms.util.FactoryFinder$StandaloneObjectFactory.loadProperties(FactoryFinder.java:223)
>> at 
>> org.apache.qpid.jms.util.FactoryFinder$StandaloneObjectFactory.create(FactoryFinder.java:164)
>> at 
>> org.apache.qpid.jms.util.FactoryFinder.newInstance(FactoryFinder.java:122)
>> at 
>> org.apache.qpid.jms.provider.ProviderFactory.findProviderFactory(ProviderFactory.java:102)
>> ... 4 more
>>
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/

Re: Proton-j: Receiver API Contracts

[Robbie Gemmell]

On 17 February 2016 at 05:05, Garlapati Sreeram Kumar  wrote:
> Hello Folks,
>
> Please help me understand few concepts on the usage of proton-j/reactor API:
>
> While using the receiver – I am overriding BaseHandler.onDelivery 
> event-callback to receive a batch of Messages. I am proactively flushing all 
> available deliveries that comes as a batch – if available. Here’s pseudo-code 
> of what I am doing – pls. correct if the intent is right. We are running into 
> blocked Receiver when we are running 1 receiver per connection (using reactor 
> framework) – does the below code ring any bells ?
>
> while (delivery != null && delivery.isReadable() && 
> !delivery.isPartial())
> {
> int size = delivery.pending();
> byte[] buffer = new byte[size];
> int read = receiveLink.recv(buffer, 0, buffer.length);
>
> Message msg = Proton.message();
> msg.decode(buffer, 0, read);
>
> messages.add(msg);
> deliveries.add(delivery);
>
> if (!receiveLink.advance())
>  {
> break;
>  }
>  else
>  {
> delivery = receiveLink.current();
>  }
> }
> application.onReceiveCallBack(messages);
> for(Delivery unsettledDelivery: deliveries)
> {
> unsettledDelivery.settle();
> }
>
> - Qstn: on a Receiver, Under what circumstances will a delivery be not 
> readable ?
>
> Thanks a lot for the Collaboration effort!
> Sree
>


The above doesnt look unreasonable for the most part, assuming a line
before what is shown is calling receiveLink.current(). It does look
like you dont apply any accepted/rejected/etc disposition to the
deliveries before settling, which may or may not cause issue for the
peer.

I'm not clear on what you mean exactly by a 'blocked reciever'
however. Is it not recieving messages you think it should? Not sending
disposition for messages you think it should? Not flowing new credit?

>From looking at the code, the delivery "isReadable()" returns true
when it the Dellivery was for a receiver link, and is the 'current'
delivery for that link, meaning that you can call receiver.rcv(..) to
grab its related content. A Delivery might not be readable if e.g the
receiver has already been advanced to the next delivery and it is no
longer the 'current' delivery, or perhaps the delivery event
corresponded to a disposition change sent by the peer after the
delviery content had been previously read and the link advanced.

Robbie

[jira] [Commented] (PROTON-1136) [proton-j] handle the case when pipelined SASL and OPEN frames are sent for ANONYMOUS login

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150831#comment-15150831
 ] 

Robbie Gemmell commented on PROTON-1136:


I don't think it has been the default for that long comparably (probably since 
0.10), or I'd have expected us to noticed more quickly that it didn't work for 
most things (In looking back I've found issues being raised against the Qpid 
C++ broker, and the Qpid Java broker, and now the servers using proton-j...and 
I don't think any of the released versions currently handle it).

> [proton-j] handle the case when pipelined SASL and OPEN frames are sent for 
> ANONYMOUS login
> ---
>
> Key: PROTON-1136
> URL: https://issues.apache.org/jira/browse/PROTON-1136
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Currently Proton-J is unable to handle pipelined SASL and OPEN frames for 
> ANONYMOUS logins, which are currently sent by proton-c, e.g see the below 
> trace log from Dispatch connecting out using ANONYMOUS:
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]:  -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
> max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]:  <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]:  <- AMQP
> {code}
> Given that there are various clients using proton that might do this by 
> default (PROTON-1135 raised regarding that), proton-j should be updated to 
> cope with it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1136) [proton-j] handle the case when pipelined SASL and OPEN frames are sent for ANONYMOUS login

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150804#comment-15150804
 ] 

Robbie Gemmell commented on PROTON-1136:


Your comment essentially exactly represents my thinking on things, and is 
basically what I said elsewhere yesterday (including the PLAIN bit)..though 
rather than have an option to turn it off at the 'client', I'd prefer an option 
to turn it on (e.g PROTON-1135). My understanding is proton-c would currently 
on do this for ANONYMOUS, at least since the sasl work done there in 0.10.

> [proton-j] handle the case when pipelined SASL and OPEN frames are sent for 
> ANONYMOUS login
> ---
>
> Key: PROTON-1136
> URL: https://issues.apache.org/jira/browse/PROTON-1136
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Currently Proton-J is unable to handle pipelined SASL and OPEN frames for 
> ANONYMOUS logins, which are currently sent by proton-c, e.g see the below 
> trace log from Dispatch connecting out using ANONYMOUS:
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]:  -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
> max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]:  <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]:  <- AMQP
> {code}
> Given that there are various clients using proton that might do this by 
> default (PROTON-1135 raised regarding that), proton-j should be updated to 
> cope with it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1135:
---
Description: 
Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN 
frames by default when connecting out to other peers using the ANONYMOUS mech, 
as shown in the following trace - 
{code}
[0x7f41f80079c0]:  -> SASL
[0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x7f41f80079c0]:  -> AMQP
[0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x7f41f80079c0]:  <- SASL
[0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
[0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
[0x7f41f80079c0]:  <- AMQP
[0x7f41f80079c0]:0 <- @open(16) 
[container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767, 
idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
properties={:product="qpid-cpp", :version="0.35", :platform="Linux", 
:host="localhost.localdomain"}]
{code}

The AMQP 1.0 spec does not make it clear that this is supported (e.g. see 
diagram below) but in any case various components have shown difficulty with it 
(such as PROTON-1135 just raised, and QPID-6639 which has yet to be included in 
a release but permitted the above protocol trace log).
{code}
TCP Client TCP Server
=
AMQP%d3.1.0.0 ->
  <- AMQP%d3.1.0.0
:
:

:
:
AMQP%d0.1.0.0 ->
(over SASL secured connection)
<- AMQP%d0.1.0.0
open ->
<- open
{code}

Proton should by default disable sending pipelined OPEN frames for ANONYMOUS 
logins, to aid compatibility with other components that don't expect/handle 
such behaviour.

  was:
Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN 
frames by default when connecting out to other peers using the ANONYMOUS mech, 
as shown in the following trace - 
{code}
[0x7f41f80079c0]:  -> SASL
[0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x7f41f80079c0]:  -> AMQP
[0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x7f41f80079c0]:  <- SASL
[0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
[0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
[0x7f41f80079c0]:  <- AMQP
[0x7f41f80079c0]:0 <- @open(16) 
[container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767, 
idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
properties={:product="qpid-cpp", :version="0.35", :platform="Linux", 
:host="localhost.localdomain"}]
{code}

The AMQP 1.0 spec does not make it clear that this is supported (e.g. see 
diagram below) but in any case various components have shown difficulty with it 
(such as PROTON-1135 just raised, and QPID-6639 which has yet to be included in 
a release but permitted the above protocol trace log).
{code}
TCP Client TCP Server
=
AMQP%d3.1.0.0 ->
  <- AMQP%d3.1.0.0
:
:

:
:
AMQP%d0.1.0.0 ->
(over SASL secured connection)
<- AMQP%d0.1.0.0
open ->
<- open
{code}

Proton by default enables sending pipelined OPEN frames for ANONYMOUS logins to 
aid compatibility with other components.


> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN 
> frames by default when connecting out to other peers using the ANONYMOUS 
> mech, as shown in the following trace - 
> {code}
> [0x7f41f80079c0]:  -> SASL
&

[jira] [Updated] (PROTON-1136) [proton-j] handle the case when pipelined SASL and OPEN frames are sent for ANONYMOUS login

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1136:
---
Description: 
Currently Proton-J is unable to handle pipelined SASL and OPEN frames for 
ANONYMOUS logins, which are currently sent by proton-c, e.g see the below trace 
log from Dispatch connecting out using ANONYMOUS:
{code}
[0x7f41f80079c0]:  -> SASL
[0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x7f41f80079c0]:  -> AMQP
[0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x7f41f80079c0]:  <- SASL
[0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
[0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
[0x7f41f80079c0]:  <- AMQP
{code}

Given that there are various clients using proton that might do this by default 
(PROTON-1135 raised regarding that), proton-j should be updated to cope with it.

  was:
Currently Proton-J is unable to handle pipelined SASL and OPEN frames. Proton-J 
should be fixed such that it handles the following scenario 

{code}
[0x7f41f80079c0]:  -> SASL
[0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x7f41f80079c0]:  -> AMQP
[0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x7f41f80079c0]:  <- SASL
[0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
[0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
[0x7f41f80079c0]:  <- AMQP

{code}

Summary: [proton-j] handle the case when pipelined SASL and OPEN frames 
are sent for ANONYMOUS login  (was: Proton J must handle the case when 
pipelined SASL and  OPEN frames are sent )

Tweaked description for clarity.

> [proton-j] handle the case when pipelined SASL and OPEN frames are sent for 
> ANONYMOUS login
> ---
>
> Key: PROTON-1136
> URL: https://issues.apache.org/jira/browse/PROTON-1136
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Currently Proton-J is unable to handle pipelined SASL and OPEN frames for 
> ANONYMOUS logins, which are currently sent by proton-c, e.g see the below 
> trace log from Dispatch connecting out using ANONYMOUS:
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]:  -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
> max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]:  <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]:  <- AMQP
> {code}
> Given that there are various clients using proton that might do this by 
> default (PROTON-1135 raised regarding that), proton-j should be updated to 
> cope with it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1135:
---
Description: 
Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN 
frames by default when connecting out to other peers using the ANONYMOUS mech, 
as shown in the following trace - 
{code}
[0x7f41f80079c0]:  -> SASL
[0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x7f41f80079c0]:  -> AMQP
[0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x7f41f80079c0]:  <- SASL
[0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
[0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
[0x7f41f80079c0]:  <- AMQP
[0x7f41f80079c0]:0 <- @open(16) 
[container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767, 
idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
properties={:product="qpid-cpp", :version="0.35", :platform="Linux", 
:host="localhost.localdomain"}]
{code}

The AMQP 1.0 spec does not make it clear that this is supported (e.g. see 
diagram below) but in any case various components have shown difficulty with it 
(such as PROTON-1135 just raised, and QPID-6639 which has yet to be included in 
a release but permitted the above protocol trace log).
{code}
TCP Client TCP Server
=
AMQP%d3.1.0.0 ->
  <- AMQP%d3.1.0.0
:
:

:
:
AMQP%d0.1.0.0 ->
(over SASL secured connection)
<- AMQP%d0.1.0.0
open ->
<- open
{code}

Proton should by default stop enables sending pipelined OPEN frames for 
ANONYMOUS logins to aid compatibility with other components.

  was:
Dispatch router (which uses Proton-c) sends pipelined SASL and OPEN frames by 
default like shown in the following trace - 
{code}
[0x7f41f80079c0]:  -> SASL
[0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x7f41f80079c0]:  -> AMQP
[0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x7f41f80079c0]:  <- SASL
[0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
[0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
[0x7f41f80079c0]:  <- AMQP
[0x7f41f80079c0]:0 <- @open(16) 
[container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767, 
idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
properties={:product="qpid-cpp", :version="0.35", :platform="Linux", 
:host="localhost.localdomain"}]
{code}
As per the AMQP 1.0 spec - the OPEN frame is sent after the SASL exchange is 
complete as shown below - 
{code}
TCP Client TCP Server
=
AMQP%d3.1.0.0 ->
  <- AMQP%d3.1.0.0
:
:

:
:
AMQP%d0.1.0.0 ->
(over SASL secured connection)
<- AMQP%d0.1.0.0
open ->
<- open
{code}
Proton should by default turn off the flag that enables sending pipelined OPEN 
frames.

Summary: [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS 
logins by default  (was: By default the flag that allows AMQP SASL and OPEN 
frames to be pipelined must be turned off )

Tweaked description for clarity.

> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN 
> frames by default when connecting out to other peers using the ANONYMOUS 
> mech, as shown in the following trace - 
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous

[jira] [Created] (PROTON-1137) [proton-j] SaslSniffer throws exception if given less than 8 bytes.

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1137:
--

 Summary: [proton-j] SaslSniffer throws exception if given less 
than 8 bytes.
 Key: PROTON-1137
 URL: https://issues.apache.org/jira/browse/PROTON-1137
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.12.0
Reporter: Robbie Gemmell


The SaslSniffer 'transport wrapper' looks at the initial header to determine if 
Sasl is in use or not. It throws if the transport is fed less than 8 bytes. 
This seems incorrect since the full 8 may not yet be available at the time, and 
the full 8 may not even be needed to make a determination.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton-J Reactor sending delay

[Robbie Gemmell]

On 13 February 2016 at 00:28, Andrew Buckley  wrote:
> I'm using the reactor with Proton-J and have noticed that there is a 2-4 
> second delay between when I call send() on a particular link and when that 
> transfer frame actually goes out. Is this expected behavior? If so, are there 
> plans to improve on this? And if not, have you seen this in any other 
> scenario and might you have any ideas what could be causing it?
>
> Thanks,
> -Andrew Buckley
>

Hi Andrew,

While im no expert on the reactor, I'd be surprised if that was
expected, and I can't say I'm aware of it being mentioned before.

One thing that springs to mind from previous discussion [about
proton-c reactor] is that when the reactor has a particular thread
dedicated to running it, it sets a 3141ms timeout on its selector
meaning it wakes up at that period when it is 'quiesced' (has nothing
to do). Seems like perhaps that could be related given your note of
2-4sec.

Do you have an example showing the behaviour?

Robbie

(added proton@ as well, in case anyone only paying attention there has thoughts)

Re: proton-j reactor socket error recovery

[Robbie Gemmell]

On 13 February 2016 at 08:59, Garlapati Sreeram Kumar  wrote:
> Hello All!
>
> Question on reactor framework expected behavior:
> - I am implementing an AmqpClient (for Azure EventHubs) and using 
> reactor.connection(connxnHandler) to get a new out-bound connection and then 
> creating sessions & Links (lets say a tree of 1 connxn – 1 session – 5 links).
> What happens on an event of socket errors? Is there a way to recover from the 
> connection error and retain the same Connection-Session-Link hierarchy ? My 
> question is more towards does Reactor provide any hooks to perform this Or do 
> I need to maintain this mapping and recover from the situation.
>
> Thanks!
> Sree
>

I think with the proton-j reactor you probably need to maintain the
mapping and recover currently. There is the idea of 'rebinding' the
Connection etc to a new Transport, which I believe some of the
proton-c language bindings use to support reconnect in slightly
higher-level reactive APIs built atop the C reactor, but I can't say
I've used that rebind ability with proton-j and there isn't as yet an
equivalent in proton-j for that higher level reactive API work, just
the core reactor itself.

Robbie

[jira] [Commented] (PROTON-1046) C++ multi-threaded broker example

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142512#comment-15142512
 ] 

Robbie Gemmell commented on PROTON-1046:


[~aconway] what is the status on this? Done? Bump to 0.13.0? Other?

> C++ multi-threaded broker example
> -
>
> Key: PROTON-1046
> URL: https://issues.apache.org/jira/browse/PROTON-1046
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.12.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.12.0
>
>
> Multi threaded C++ broker example based on
> - C++11 standard threading facilities
> - proton::engine driver
> - linux poll, windows WSAPol 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1064) ruby: add ConnectionEngine alterntive integration style

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142510#comment-15142510
 ] 

Robbie Gemmell commented on PROTON-1064:


[~aconway] what is the status on this? Done? Bump to 0.13.0? Other?

> ruby: add ConnectionEngine alterntive integration style
> ---
>
> Key: PROTON-1064
> URL: https://issues.apache.org/jira/browse/PROTON-1064
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: ruby-binding
>Affects Versions: 0.11.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.12.0
>
>
> Add a simple integration between a ruby IO object and a proton engine, 
> without using the reactor.  Use the same handler classes for application 
> logic but pump data directly to/from a single IO instance instead of using 
> the selector.
> - Avoids issue with GVL (since all IO is done in proton) 
> - Can integrate with any ruby IO subclass (not just sockets opened by the 
> reactor.) 
> - Can run engines in separate ruby threads for concurrency.
> A similar class is available in the C++ and Go bindings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1063) ruby: ruby reactor holds GVL in process

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142511#comment-15142511
 ] 

Robbie Gemmell commented on PROTON-1063:


[~aconway] what is the status on this? Done? Bump to 0.13.0? Other?

> ruby: ruby reactor holds GVL in process
> ---
>
> Key: PROTON-1063
> URL: https://issues.apache.org/jira/browse/PROTON-1063
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.10
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.12.0
>
>
> Ruby has a global lock the GVL, like python's GIL.
> The ruby binding Reactor#process blocks in pn_reactor_process while holding 
> the lock, blocking all other ruby threads.
> This is the same issue as PROTON-752, but it was only fixed for messenger, 
> not for the reactor.
> The fix is more complex, we can't simply call pn_reactor_process in 
> rb_thread_call_without_gvl() because it calls handler functions that call 
> back into ruby. We need to isolate just the blocking IO code in without_gvl 
> and restore the lock before handlers call back into ruby.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1071) EventInjector hangs on Windows

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142508#comment-15142508
 ] 

Robbie Gemmell commented on PROTON-1071:


[~cliffjansen] what is the status on this? Done? Bump to 0.13.0? Other?

> EventInjector hangs on Windows
> --
>
> Key: PROTON-1071
> URL: https://issues.apache.org/jira/browse/PROTON-1071
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.11.0
> Environment: Windows
>Reporter: Ken Giusti
>Assignee: Cliff Jansen
> Fix For: 0.12.0
>
>
> I added a new reactor test that exercises the python-proton ApplicationEvent 
> and EventInjector classes:
> proton_tests.reactor.ApplicationEventTest.test_application_events
> See tests/python/proton_tests/reactor.py
> This test passes on linux, but hangs when run on Windows.
> Poking around a bit, I suspect the problem may be in the Windows selector 
> code.  Description:
> The EventInjector/ApplicationEvent classes provide a way to trigger events 
> from threads external to the reactor main loop.  See 
> proton-c/bindings/python/proton/reactor.py.  A pipe is used to wake up the 
> reactor when a new event is sent to the reactor (see reactor.py in the python 
> bindings).  The EventInjector's trigger method puts the event on a queue and 
> writes to a pipe to wake up the reactor.  The on_selectable_readable callback 
> in the EventInjector is called on the reactor thread to get the event off the 
> queue and clear the pipe.
> On windows it appears as if the EventInjector selectable is made "readable" 
> even though nothing has been written to the pipe.  This causes the os.read() 
> call in the on_selectable_readable() callback to hang.
> Best I can tell the windows selector code doesn't work properly with a pipe.  
> The pn_selector_next() function is returning a read event on the pipe's read 
> descriptor even though the pipe is empty.  But I'm not familiar with the 
> window's selector implementation, so this is a best guess.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1094) c++: refactor and documentation of type conversions

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142506#comment-15142506
 ] 

Robbie Gemmell commented on PROTON-1094:


[~aconway] what is the status on this? Done? Bump to 0.13.0? Other?

> c++:  refactor and documentation of type conversions
> 
>
> Key: PROTON-1094
> URL: https://issues.apache.org/jira/browse/PROTON-1094
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.11.1
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.12.0
>
>
> Original design was to use stream operator << >> interface to proton::data to 
> give complete flexibility to construct/interpret arbitrary AMQP types in a 
> usable, idiomatic C++ way.
> This interface is important internally but most API users will use automatic 
> conversion via assignment, construction and get() functions on 
> proton::value and the proton::scalar types. 
> Move detailed documentation for the type conversion rules to proton::value, 
> and mark the data interface as "advanced" but leave it available to cover 
> possible interop cases that are not covered by the existing "canned" 
> conversions.
> Review proton::message constructors, assignment and documentation to make 
> sure it is easy to understand how to use data-containing members of a message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PROTON-1125) c++: core dump on empty address in link options

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1125.

Resolution: Fixed

> c++: core dump on empty address in link options
> ---
>
> Key: PROTON-1125
> URL: https://issues.apache.org/jira/browse/PROTON-1125
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.1
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Blocker
> Fix For: 0.12.0
>
>
> See:
> https://scan4.coverity.com/reports.htm#v14284/p10556/fileInstanceId=8369775&defectInstanceId=1901068&mergedDefectId=122279&eventId=1901068-29
> This is just the core dump on empty address fix from proton-1122, separated 
> for 0,12 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1125) c++: core dump on empty address in link options

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1125:
---
Affects Version/s: (was: 0.12.0)
Fix Version/s: (was: 0.12.1)
   (was: 0.13.0)
   0.12.0

Updating the versions again to reflect that the commit made it into the respins 
for RC2+RC3, and so now will actually be in 0.12.0.

Will also resolve now that it appears to be done.

> c++: core dump on empty address in link options
> ---
>
> Key: PROTON-1125
> URL: https://issues.apache.org/jira/browse/PROTON-1125
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.1
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Blocker
> Fix For: 0.12.0
>
>
> See:
> https://scan4.coverity.com/reports.htm#v14284/p10556/fileInstanceId=8369775&defectInstanceId=1901068&mergedDefectId=122279&eventId=1901068-29
> This is just the core dump on empty address fix from proton-1122, separated 
> for 0,12 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0

[Robbie Gemmell]

On 10 February 2016 at 14:04, Justin Ross  wrote:
> Hi, everyone.  RC 2 had some embedded build output, which this RC removes.
> Apart from that removal, it has the same content as RC 2.
>
> The proposed release artifacts:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc3/
>
> Please indicate your vote below.  If you favor releasing the 0.12.0 RC 3
> bits as 0.12.0 GA, vote +1.  If you have reason to think RC 3 is not
> ready for release, vote -1.
>
> Thanks,
> Justin

+1

I verfified the only difference in the source archive since RC1 were
the two cpp binding changes, making this the same as what I tested
earlier after trimming RC2. I also ran the QpidJMS master build
against the staged maven repo bits to verify those. All seemed well.

Robbie

Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0

[Robbie Gemmell]

Thanks, saved me sending that :)

Robbie

On 10 February 2016 at 15:35, Rob Godfrey  wrote:
> To be pedantic, only PMC members votes are officially considered binding
> [1], and votes from committers who are not on the PMC are not... However in
> general as a community we would encourage anyone who has done any sort of
> validation of the release to provide their feedback via (non-binding)
> voting.
>
> -- Rob
>
> [1] http://www.apache.org/foundation/voting.html
>
> On 10 February 2016 at 15:29, Justin Ross  wrote:
>
>> Thanks, Ganesh.  BTW, you can vote.  When we tally up the results, we
>> separate the binding (committer) from the non-binding votes, but we use all
>> the votes in our decision nonetheless.
>>
>> On Wed, Feb 10, 2016 at 7:11 AM, Ganesh Murthy  wrote:
>>
>> > I cannot vote but I did the following on Fedora 22 -
>> >
>> > 1. Downloaded and compiled the proton 0.12.0 RC3 source and ran all unit
>> > tests (including the ones I added) successfully
>> > 2. Made dispatch router master use Qpid Proton 0.12.0 RC 3. Ran dispatch
>> > unit tests successfully.
>> > 3. Made sure that the unit test for DISPATCH-200 which relies on
>> > PROTON-1088 worked.
>> >
>> > Thanks.
>> >
>> > - Original Message -
>> > From: "Justin Ross" 
>> > To: us...@qpid.apache.org, proton@qpid.apache.org
>> > Sent: Wednesday, February 10, 2016 9:31:58 AM
>> > Subject: Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0
>> >
>> > The RC 3 maven repo:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapacheqpid-1063
>> >
>> > On Wed, Feb 10, 2016 at 6:04 AM, Justin Ross 
>> > wrote:
>> >
>> > > Hi, everyone.  RC 2 had some embedded build output, which this RC
>> > > removes.  Apart from that removal, it has the same content as RC 2.
>> > >
>> > > The proposed release artifacts:
>> > >
>> > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc3/
>> > >
>> > > Please indicate your vote below.  If you favor releasing the 0.12.0 RC
>> 3
>> > > bits as 0.12.0 GA, vote +1.  If you have reason to think RC 3 is not
>> > > ready for release, vote -1.
>> > >
>> > > Thanks,
>> > > Justin
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> > For additional commands, e-mail: users-h...@qpid.apache.org
>> >
>> >
>>

Re: [VOTE] Release RC 2 as Qpid Proton 0.12.0

[Robbie Gemmell]

On 10 February 2016 at 10:36, Robbie Gemmell  wrote:
> On 9 February 2016 at 14:11, Justin Ross  wrote:
>> The artifacts proposed for release:
>>
>> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc2/
>>
>> Please indicate your vote below.  If you favor releasing the 0.12.0 RC 2
>> bits as 0.12.0 GA, vote +1.  If you have reason to think the RC is not
>> ready for release, vote -1.
>>
>> Thanks,
>> Justin
>
> -1
>
> The archive contains build output for at least the java bits.
>
> Robbie
>
> (resent to include both mailing lists)

FWIW, after cleaning out all the build related files (which did seem
to extend beyond the java builds) l was left with just the 2 expected
changes to the cpp binding. Running the install on Linux worked fine
as before (verified with a qpid-cp trunk build) and the staged java
binary artifacts worked fine for a qpid-jms build too, but will also
need a rebuild due to the source issue.

Robbie

Re: [VOTE] Release RC 2 as Qpid Proton 0.12.0

[Robbie Gemmell]

On 9 February 2016 at 14:11, Justin Ross  wrote:
> The artifacts proposed for release:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc2/
>
> Please indicate your vote below.  If you favor releasing the 0.12.0 RC 2
> bits as 0.12.0 GA, vote +1.  If you have reason to think the RC is not
> ready for release, vote -1.
>
> Thanks,
> Justin

-1

The archive contains build output for at least the java bits.

Robbie

(resent to include both mailing lists)

[jira] [Updated] (PROTON-1125) c++: core dump on empty address in link options

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1125:
---
Affects Version/s: 0.12.0
Fix Version/s: (was: 0.12.0)
   0.13.0
   0.12.1

Updating the versions to reflect that the commit missed the 0.12.0 RC currently 
under vote, and so would actually be in either a 0.12.1 (if it occurs) or else 
0.13.0 unless a respin becomes necessary that lets it be included in 0.12.0.

> c++: core dump on empty address in link options
> ---
>
> Key: PROTON-1125
> URL: https://issues.apache.org/jira/browse/PROTON-1125
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.1, 0.12.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Blocker
> Fix For: 0.12.1, 0.13.0
>
>
> See:
> https://scan4.coverity.com/reports.htm#v14284/p10556/fileInstanceId=8369775&defectInstanceId=1901068&mergedDefectId=122279&eventId=1901068-29
> This is just the core dump on empty address fix from proton-1122, separated 
> for 0,12 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1050) 0.12.0 release tasks

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132459#comment-15132459
 ] 

Robbie Gemmell commented on PROTON-1050:


I think we should probably mention something somwhere (release notes and/or 
download page) about vthe very slight build issue  between proton 0.12.0 and 
qpid-cpp-0.34 given it wont be resolved out-the-box until the next cpp release 
is available.

http://mail-archives.apache.org/mod_mbox/qpid-proton/201601.mbox/%3CCAFitrpRam52e2NH_pSL8zxgQ5G1MBC-X0WGLmbGHBVpw-NgOxg%40mail.gmail.com%3E

> 0.12.0 release tasks
> 
>
> Key: PROTON-1050
> URL: https://issues.apache.org/jira/browse/PROTON-1050
> Project: Qpid Proton
>  Issue Type: Task
>  Components: release
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.12.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Qpid Proton 0.12.0

[Robbie Gemmell]

On 3 February 2016 at 15:10, Justin Ross  wrote:
> The artifacts proposed for release:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/
>
> Please indicate your vote below.  If you favor releasing the 0.12.0 RC bits
> as 0.12.0 GA, vote +1.  If you have reason to think the RC is not ready for
> release, vote -1.
>
> Thanks,
> Justin

+1

I tested the RC out as follows:
 - Verified sigs and checksums.
 - Checked LICENCE+NOTICE present.
 - Ran the maven build, tests.
 - Ran the CMake build, tests, and install.
 - Built Qpid C++ trunk build against earlier install.
 - Built Qpid Dispatch master and 0.5 builds against against earlier install.
 - Used the staging repo to run the Qpid JMS master build and tests.
 - Used the staging repo to run the ActiveMQ master build and tests
(with the needed test updates).
 - Ran the JMS client HelloWorld example against the earlier built C++
broker, ActiveMQ broker, and Dispatch routers, as well as the 6.0.0
Qpid Java broker.

I didn't try qpid-cpp 0.34 against it, I assume the situtation there
hasn't changed since 0.12.0-beta. We might want to release note that
issue or mention it on the download page in some way to cover the
period until the next cpp release is available, I'll mention it on
PROTON-1050.

Robbie

Re: Best practices using proton-j Reactor

[Robbie Gemmell]

Hi Sree,

I'm not too familiar with the Reactor bits, I've never used them
beyong the send/recv examples, but I'll try to answer what I can.
Perhaps other folks can chime in if they know more (even if based on
knowledge of the proton-c reactor). Responses inline.

On 3 February 2016 at 20:05, Garlapati Sreeram Kumar  wrote:
> Hello Folks!
>
> Couple of Questions on Proton-j Reactor usage-pattern:
>
> 1. In the current version of proton-j: 1 Reactor instance is tied to 1 
> connection – is there any way to associate 1 Reactor per Link.

I think its actually each Connection (and related bits) is tied to a
single Reactor rather than the reverse, but no I wouldnt expect you
can associate a different reactor (though you could perhaps associate
a different Handler) with each link since that would presumably
involve multiple threads.

The proton engine can only be used by a single thread at a time. This
essentially encompasses everything relating to a given Transport as a
group except for the Message objects (which themselves still need to
be accessed by 1 thread at a time) since they are formed seperately
either from scratch or from bytes taken from a Delivery. The reactor
bits are one implementation of achieving that single-threaded access.

> Or in other words, If there are multiple links attached to one Connection, 
> which is handled by one Reactor instance - What is the recommendation to use 
> reactor in such a way that One link will not impact others – the unhandled 
> exceptions and the time it takes to process.
> Here’s the Problem: When one of the links perform I/O upon any event 
> dispatched (ex: onDelivery) by the Reactor pump – all other links are 
> starving for messages as that I/O is blocking the thread in which 
> reactor.run() – which absolutely makes sense from Reactor pump (the 
> reactor.run()) perspective.
>

Do you mean for example taking a long time to process a particular
delivery before accepting/etc? I think the reactor is built around
assumption that events will be handled quickly. There does seem to be
support for scheduling tasks and inserting your own selectables, so
one approach might be to offload any long running processing of
deliveries to another thread and construct a way to monitor their
progress and then have the reactor take any subsequent action. In
terms of IO I would expect that to be non-blocking? I'm not sure what
exceptions you are referring to.

> 2. What is the Best way to gracefully Stop the Reactor.
> In our Tests – where we  are Starting a Reactor per testclass and calling 
> reactor.free as part of class cleanup – throws exception: 
> reactor:org.apache.qpid.proton.engine.HandlerException: 
> java.nio.channels.ClosedSelectorException
> Do we need to handle this by try-catch’ing the reactor.run() block ?
>

I'm not entirely sure about this. The examples mostly look to take
advantage of the reactor exiting once there is no outstanding work (no
scheduled tasks, and no other selectables to process (e.g for outgoing
connections, or an acceptor for incoming ones)). Anything that calls
free() does it from the thread running the reactor, right after run()
returns. The wakeup() method is noted in the javadoc as the only
method that can be safely called while another thread is still
processing the reactor.

> Thanks a lot for such a Wonderful Collaboration!
> Sree
>

Re: JIRA 515 and release 0.12.0

[Robbie Gemmell]

Andrew/Alan/Any-other-C-inclined-folks, can you look at this?

I know a large sticking point is likely to be that we probably have no
easy way to test things on OpenVMS, but as it seems quite contained
(though perhaps not in the desired style?) I think approaching it on a
'if it doesn't break anything else' basis would do fine.

Robbie

On 2 February 2016 at 08:28, Tomáš Šoltys  wrote:
> Hi,
>
> JIRA 515 is set to be fixed in 0.11.1 but is still unresolved.
> I have submitted two patches (io.c.patch object.h.patch) which from my
> point of view makes port to OpenVMS complete.
>
> Can this JIRA be resolved with 0.12.0?
>
> Regards,
> Tomáš Šoltys

[jira] [Comment Edited] (PROTON-1070) validate the Open frame having been received before other frames

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15112292#comment-15112292
 ] 

Robbie Gemmell edited comment on PROTON-1070 at 2/2/16 10:56 AM:
-

Updating title/description to reflect some changes having been made via 
PROTON-1100 instead.


was (Author: gemmellr):
Updating title/description to reflect some changes having been made via 
PROTON-1000

> validate the Open frame having been received before other frames 
> -
>
> Key: PROTON-1070
> URL: https://issues.apache.org/jira/browse/PROTON-1070
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.12.0
>    Reporter: Robbie Gemmell
>
> I recently saw an odd test failure while making changes to some other code 
> (itself using proton-j) that the test was using, even though it seemed like 
> the change should have had no effect on that test. I eventually identified 
> this was due to some unexpected behaviour in other areas that was ultimately 
> occuring because no Open frame had been sent/received, as the original author 
> of the test had not opened the 'client' Connection object. The test should 
> thus never have worked as a result, but it did.
> After some further inspection, it seems that:
> - proton-j can receive and process other frames without the Open arriving, 
> resulting in different 'default' behaviour than if it were.
> - It isnt immediately obvious (to me) whether proton-c guards against the 
> receiving case or not.
> EDIT: the work on proton-j based on the following comments was split out to 
> PROTON-1000:
> - proton-j can emit other frames without first sending the Open frame 
> [because the Connection object wasnt actually opened].
> - proton-c does not appear to, since it guards in various using a check if 
> the open has been sent yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Request for inclusion in 0.12.0

[Robbie Gemmell]

Thanks Justin, Andrew.

Changes merged and a new 0.12.0-SNAPSHOT published (once I realised I
forgot to update the version on the branch.. ;p )

Robbie

On 29 January 2016 at 17:24, Justin Ross  wrote:
> Thanks, Robbie and Andrew.  All set.
>
> On Fri, Jan 29, 2016 at 9:21 AM, Andrew Stitcher 
> wrote:
>
>> I've approved both of these for inclusion (in the JIRAs).
>>
>> Andrew
>>
>> On Thu, 2016-01-28 at 11:04 +, Robbie Gemmell wrote:
>> > Hi Justin,
>> >
>> > I'd like to request the following for inclusion in 0.12.0:
>> >
>> > Stop the proton-j transport from erroneously emitting various frame
>> > types after a Close was sent.
>> > https://issues.apache.org/jira/browse/PROTON-1114
>> > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bcd08cc
>> >
>> > Some minor readme/pom changes around describing running the python
>> > tests.
>> > https://issues.apache.org/jira/browse/PROTON-1113
>> > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f11723c
>> >
>> > Thanks,
>> > Robbie
>>

[jira] [Updated] (PROTON-1114) [proton-j] the transport should not emit other frames after the Close frame has been sent

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1114:
---
Affects Version/s: (was: 0.12.0)
   0.11.1
Fix Version/s: (was: 0.13.0)
   0.12.0

Merged to 0.12.x branch for inclusion in the 0.12.0 RC

> [proton-j] the transport should not emit other frames after the Close frame 
> has been sent
> -
>
> Key: PROTON-1114
> URL: https://issues.apache.org/jira/browse/PROTON-1114
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.1
>    Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> The proton-j transport can emit other frames after sending the Close frame 
> [whether because the Connection object was closed explicitly, or otherwise], 
> which is forbidden by the AMQP spec and as such needs to be prevented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1113) tidy up some descriptive detail around running the python tests

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1113:
---
Fix Version/s: (was: 0.13.0)
   0.12.0
  Description: Merged to 0.12.x branch for inclusion in the 0.12.0 RC

> tidy up some descriptive detail around running the python tests
> ---
>
> Key: PROTON-1113
> URL: https://issues.apache.org/jira/browse/PROTON-1113
> Project: Qpid Proton
>  Issue Type: Task
>    Reporter: Robbie Gemmell
>        Assignee: Robbie Gemmell
>Priority: Trivial
> Fix For: 0.12.0
>
>
> Merged to 0.12.x branch for inclusion in the 0.12.0 RC



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-852) Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support getaddrinfo(),getprotobyname()

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-852:
--
Fix Version/s: (was: 0.12.0)
   0.13.0

> Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support 
> getaddrinfo(),getprotobyname() 
> -
>
> Key: PROTON-852
> URL: https://issues.apache.org/jira/browse/PROTON-852
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Affects Versions: 0.9, 0.9.1, 0.10
> Environment: uclinux m68k
>Reporter: Tomasz Nowicki
>Assignee: Andrew Stitcher
>  Labels: patch
> Fix For: 0.13.0
>
> Attachments: proton-c-GETADDRINFO.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> We are using proton-c on a small ebedded system based on uclinux/uclibc.c On 
> this platform several required functions ex getaddrinfo(), getprotobyname() 
> are not implemented.We added support for this type of platform by wraping 
> with pn_getaddrinfo,pn_getprotobyname.  Relevant pn_freeaddrinfo is also 
> introduced. If GETADDRINFO_NOT_IMPL flag is not present, native 
> implementation is called. Changes apply for posix versions that use old lib.c 
> Specifically in some embedded versions "get host" is not present(ip address 
> is used instead).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1091) [Python binding] AMQP null type not sent on wire according to AMQP specification

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1091:
---
Fix Version/s: (was: 0.12.0)
   0.13.0

> [Python binding] AMQP null type not sent on wire according to AMQP 
> specification
> 
>
> Key: PROTON-1091
> URL: https://issues.apache.org/jira/browse/PROTON-1091
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Fix For: 0.13.0
>
>
> When sending AMQP type null as the content of a message, the Python binding 
> sends the message with no body at all, and similarly interprets a no-body 
> AMQP type message as a null type. This violates the AMQP 1.0 specification on 
> two counts:
> * A body MUST be present and be one of three types (section 3.2);
> * When sending an AMQP null type, there is an assigned AMQP type code (0x40) 
> which should be used.
> This causes interoperability issues with other clients. For example,  the C++ 
> client can't send a null type to a python client without a failure (or _visa 
> versa_).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-985) Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock time

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-985:
--
Fix Version/s: (was: 0.12.0)
   0.13.0

> Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock 
> time
> -
>
> Key: PROTON-985
> URL: https://issues.apache.org/jira/browse/PROTON-985
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.13.0
>
>
> The timestamp argument to pn_transport_tick is a pn_timestamp_t.  
> pn_timestamp_t implies real time (wall clock) in that it's expressed as a 
> time value based on epoch.
> As seen in QPID-6698, using a real time value for that argument can lead to 
> problems if the real time is adjusted (eg.  timezone, daylight savings, 
> drift).
> Instead, pn_transport_tick should be passed a monotonic clock source - one 
> that does not reflect changes in real time.
> All documentation and examples should be updated accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-968) [proton-j] validate local/remote channel-max is adhered to

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-968:
--
Affects Version/s: (was: 0.10)
   0.12.0
Fix Version/s: (was: 0.12.0)
  Summary: [proton-j] validate local/remote channel-max is adhered 
to  (was: [proton-j] channel-max handling is broken)

> [proton-j] validate local/remote channel-max is adhered to
> --
>
> Key: PROTON-968
> URL: https://issues.apache.org/jira/browse/PROTON-968
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>    Reporter: Robbie Gemmell
>
> The channel-max handling in proton-j is broken.
> Transport[Impl] defines get/setChannelMax methods, which allow controlling 
> the value sent in the Open frame emmitted for the connection. It defaults to 
> the maximum 65535.
> The ConnectionImpl object has a getMaxChannels method that returns a hard 
> coded value of 65535, and it is this limit value that is used by 
> TransportImpl when selecting local channel numbers for sending Begin frame 
> for new sessions. As such, it pays no notice of the limit value it announced 
> in its Open frame, which may have been lower if configured on the transport.
> The remote channel-max receiver from the peer isn't used at all other than 
> for return via getRemoteChannelMax(). The above process will similarly pay it 
> no attention to it when selecting channel numbers for new sessions and so may 
> select a channel number above the remote peers limit [and perhaps also its 
> own, again].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton-J and WebSocket support

[Robbie Gemmell]

On 29 January 2016 at 07:01, Clemens Vasters  wrote:
> It appears that Proton-J doesn't implement the WebSocket protocol binding, 
> yet. (I may also not be looking in the right places)
>
> Is that on the backlog for some time in the nearer future?
>
> Thank you
> Clemens
>

Hi Clemens

I'm not aware of anyone working on this or planning to in the near
future (but anyone reading knowing otherwise, feel free to shout).
Possibly related, someone from the Azure IoT Hub team asked the same
before the holidays looking to prevent duplicate effort.

I think the core engine is largely good to go, I know the current
working state of the websocket binding removed some prior obstacles in
that area. I guess that would leave any bits actually creating sockets
such as the IO bits added with the Reactor (I'm not really familiar
with those as my dealings are mostly around the core engine).

Robbie

Re: Proton 0.12.0 release update - Beta is available

[Robbie Gemmell]

On 27 January 2016 at 00:51, Justin Ross  wrote:
> Hi, folks.  The beta is now available from the following URL:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-beta/
>
> Maven staging repo:
>
> https://repository.apache.org/content/repositories/orgapacheqpid-1059
>
> Test output from my machine, Fedora 23 x86-64:
>
>
> http://people.apache.org/~jross/qpid-releases/quirk-proton-0.12.0-beta.log
>
> Only one week remains before the release candidate.  See the release
> page[1] for more information.  Please test in your environment and report
> what you find.
>
> Thanks!
> Justin
>
> ---
> [1] Proton 0.12.0 release page:
> https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.12.0


I tested the beta out as follows:

 - Used the CMake build, tests, install.
 - Ran the maven build, tests.
 - Used the staged maven artifacts to run the Qpid JMS master build and tests.
 - Used the staged maven artifacts to run the ActiveMQ master build
and tests (with required test updates).
 - Built Qpid C++ trunk broker against it, ran the JMS client
HelloWorld example using it.
 - Built Qpid Dispatch 0.5 against it, ran the JMS client HelloWorld
example using it.

 - Tried to build qpid C++ 0.34 broker against it, which failed due to
not handling a newer possible switch statement case
  -- Presumably (I didnt verify) because it doesnt have the updates
from http://svn.apache.org/r1717539 and http://svn.apache.org/r1717997
  -- Using -DCMAKE_CXX_FLAGS=-Wno-error=switch seemed to get things
going, and I was able to run the HelloWorld example against it.
  -- I guess this is of little concern if the workarounds are as easy
as above and the next cpp release is imminent.

Robbie

Re: RFI: PROTON-1055 (SASL Plain authentication can fail on some brokers)

[Robbie Gemmell]

On 27 January 2016 at 21:09, Andrew Stitcher  wrote:
> This [1] is really an interop bug, but I suspect it will be annoying to
> anyone using earlier versions of ActiveMQ.
>
> The fix is pretty small and seems low risk to me.
>
> Andrew
>
> [1] https://issues.apache.org/jira/browse/PROTON-1055

I gave this a look, and tested it out applied to the 0.12.0 beta using
cyrus-casl, and all seemed well, I think including it would be good.

(As an aside, I actually think of it as more than just an interop bug..)

Robbie

[jira] [Commented] (PROTON-1055) Username sent twice during SASL AUTH

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121361#comment-15121361
 ] 

Robbie Gemmell commented on PROTON-1055:


The change looks good to me, and I think it should be included in the 0.12.0 
release.

I tested this out (using cyrus SASL) against ActiveMQ 5.12.1 ( what this issue 
was reported using, and the last release before AMQ-6055 was resolved) by 
configuring the SimpleAuthenitcationPlugin with a username:password (which must 
not be equal, to show the bug) as follows:

{noformat}

  

  

  

{noformat}

I then tried to log in using the 0.12.0-beta python bindings, which as shown 
below failed:
{noformat}
[0xf61cb0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"user1\x00user1\x00pass1"]
[0xf61cb0]:0 <- @sasl-outcome(68) [code=1]
{noformat}
I then applied this change to the beta and tried again, which due to not 
setting the authzid then succeeded:
{noformat}
[0x208c510]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00user1\x00pass1"]
[0x208c510]:0 <- @sasl-outcome(68) [code=0]
{noformat}

> Username sent twice during SASL AUTH
> 
>
> Key: PROTON-1055
> URL: https://issues.apache.org/jira/browse/PROTON-1055
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>Reporter: Simon Lundstrom
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice 
> during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]:  -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]:  <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]:  -> AMQP
> [0x250d3b0]:0 -> @open(16) 
> [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue", durable=0, timeout=0, dynamic=false], 
> target=@target(41) [address="TEST-queue", durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x250d3b0]:  <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="", 
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, 
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
> properties={:product="ActiveMQ", :"topic-prefix"="topic://", 
> :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, 
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0, 
> link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0, 
> delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0, 
> settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]:  -> SASL
> [0x18aa060]:  <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-

Request for inclusion in 0.12.0

[Robbie Gemmell]

Hi Justin,

I'd like to request the following for inclusion in 0.12.0:

Stop the proton-j transport from erroneously emitting various frame
types after a Close was sent.
https://issues.apache.org/jira/browse/PROTON-1114
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bcd08cc

Some minor readme/pom changes around describing running the python tests.
https://issues.apache.org/jira/browse/PROTON-1113
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f11723c

Thanks,
Robbie

[jira] [Resolved] (PROTON-1113) tidy up some descriptive detail around running the python tests

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1113.

Resolution: Fixed

> tidy up some descriptive detail around running the python tests
> ---
>
> Key: PROTON-1113
> URL: https://issues.apache.org/jira/browse/PROTON-1113
> Project: Qpid Proton
>  Issue Type: Task
>    Reporter: Robbie Gemmell
>        Assignee: Robbie Gemmell
>Priority: Trivial
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PROTON-1114) [proton-j] the transport should not emit other frames after the Close frame has been sent

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1114.

Resolution: Fixed

> [proton-j] the transport should not emit other frames after the Close frame 
> has been sent
> -
>
> Key: PROTON-1114
> URL: https://issues.apache.org/jira/browse/PROTON-1114
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>    Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> The proton-j transport can emit other frames after sending the Close frame 
> [whether because the Connection object was closed explicitly, or otherwise], 
> which is forbidden by the AMQP spec and as such needs to be prevented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1114) [proton-j] the transport should not emit other frames after the Close frame has been sent

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1114:
--

 Summary: [proton-j] the transport should not emit other frames 
after the Close frame has been sent
 Key: PROTON-1114
 URL: https://issues.apache.org/jira/browse/PROTON-1114
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.12.0
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.13.0


The proton-j transport can emit other frames after sending the Close frame 
[whether because the Connection object was closed explicitly, or otherwise], 
which is forbidden by the AMQP spec and as such needs to be prevented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1113) tidy up some descriptive detail around running the python tests

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1113:
--

 Summary: tidy up some descriptive detail around running the python 
tests
 Key: PROTON-1113
 URL: https://issues.apache.org/jira/browse/PROTON-1113
 Project: Qpid Proton
  Issue Type: Task
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
Priority: Trivial
 Fix For: 0.13.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1111) Fix warnings during make doc

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119426#comment-15119426
 ] 

Robbie Gemmell commented on PROTON-:


I remember asking [~gsim] about warnings in the doc build back when doing 0.10 
(I think), and there being some discussion with [~kgiusti] about whether 
something should have been the way it was, which I think it might have been the 
same bit as changed here. Either of you recall the details (which went over my 
head..) ? :)

> Fix warnings during make doc
> 
>
> Key: PROTON-
> URL: https://issues.apache.org/jira/browse/PROTON-
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c, python-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Request for inclusion in 0.12.0 beta

[Robbie Gemmell]

Great, thanks Justin. Both changes are now picked onto the 0.12.x branch.

Robbie

On 26 January 2016 at 14:16, Justin Ross  wrote:
> Thanks, Robbie.  Both are approved.
>
>
> On Tue, Jan 26, 2016 at 6:10 AM, Robbie Gemmell 
> wrote:
>
>> Hi Justin,
>>
>> I see you have created the 0.12.x branch, but before you actually spin
>> the beta, could I request the following...
>>
>> The latest commit on https://issues.apache.org/jira/browse/PROTON-1100
>> didnt make the branch.
>> https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6422e24
>>
>> Also since its a similarly trivial if check expansion but of more real
>> world use, can I separately request:
>> https://issues.apache.org/jira/browse/PROTON-1110
>>
>> Thanks,
>> Robbie
>>

[jira] [Resolved] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1110.

Resolution: Fixed

> [proton-j] allow suppressing the synthentic flow event when sending transfers
> -
>
> Key: PROTON-1110
> URL: https://issues.apache.org/jira/browse/PROTON-1110
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.1
>    Reporter: Robbie Gemmell
>    Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> The engine emits synthetic Flow events when sending messages, in addition to 
> those raised when receiving a Flow frame for the link. I believe the 
> reasoning for this is so to treat it as a 'credit changed' indicator. 
> However, as there are cases where the decision to send a message has little 
> at all to do with the credit conditions, having these events its often 
> unecessary and wasteful.
> A simple toggle will be added to signal the transport not to emit the flow 
> events for use in those cases. The default behaviour will be unchanged.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1110:
---
Affects Version/s: (was: 0.12.0)
Fix Version/s: (was: 0.13.0)
   0.12.0

Thanks Justin, change now merged to the 0.12.x branch for inclusion in the beta.

> [proton-j] allow suppressing the synthentic flow event when sending transfers
> -
>
> Key: PROTON-1110
> URL: https://issues.apache.org/jira/browse/PROTON-1110
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.1
>    Reporter: Robbie Gemmell
>    Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> The engine emits synthetic Flow events when sending messages, in addition to 
> those raised when receiving a Flow frame for the link. I believe the 
> reasoning for this is so to treat it as a 'credit changed' indicator. 
> However, as there are cases where the decision to send a message has little 
> at all to do with the credit conditions, having these events its often 
> unecessary and wasteful.
> A simple toggle will be added to signal the transport not to emit the flow 
> events for use in those cases. The default behaviour will be unchanged.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117262#comment-15117262
 ] 

Robbie Gemmell commented on PROTON-1100:


The last commit above on master has now been merged to the 0.12.x branch for 
inclusion in the 0.12.0 beta.

> [proton-j] the transport should not emit other frames before the Open frame 
> has been sent
> -
>
> Key: PROTON-1100
> URL: https://issues.apache.org/jira/browse/PROTON-1100
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> As per PROTON-1070 description, the proton-j transport can emit other frames 
> without first sending the Open frame [because the Connection object wasnt 
> actually opened], which is erroneous behaviour and should be prevented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Request for inclusion in 0.12.0 beta

[Robbie Gemmell]

Hi Justin,

I see you have created the 0.12.x branch, but before you actually spin
the beta, could I request the following...

The latest commit on https://issues.apache.org/jira/browse/PROTON-1100
didnt make the branch.
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6422e24

Also since its a similarly trivial if check expansion but of more real
world use, can I separately request:
https://issues.apache.org/jira/browse/PROTON-1110

Thanks,
Robbie

[jira] [Updated] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1110:
---
Affects Version/s: 0.12.0

> [proton-j] allow suppressing the synthentic flow event when sending transfers
> -
>
> Key: PROTON-1110
> URL: https://issues.apache.org/jira/browse/PROTON-1110
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.1, 0.12.0
>    Reporter: Robbie Gemmell
>    Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> The engine emits synthetic Flow events when sending messages, in addition to 
> those raised when receiving a Flow frame for the link. I believe the 
> reasoning for this is so to treat it as a 'credit changed' indicator. 
> However, as there are cases where the decision to send a message has little 
> at all to do with the credit conditions, having these events its often 
> unecessary and wasteful.
> A simple toggle will be added to signal the transport not to emit the flow 
> events for use in those cases. The default behaviour will be unchanged.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1110:
---
Fix Version/s: (was: 0.12.0)
   0.13.0

> [proton-j] allow suppressing the synthentic flow event when sending transfers
> -
>
> Key: PROTON-1110
> URL: https://issues.apache.org/jira/browse/PROTON-1110
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.1
>    Reporter: Robbie Gemmell
>    Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> The engine emits synthetic Flow events when sending messages, in addition to 
> those raised when receiving a Flow frame for the link. I believe the 
> reasoning for this is so to treat it as a 'credit changed' indicator. 
> However, as there are cases where the decision to send a message has little 
> at all to do with the credit conditions, having these events its often 
> unecessary and wasteful.
> A simple toggle will be added to signal the transport not to emit the flow 
> events for use in those cases. The default behaviour will be unchanged.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1107) [proton-j] only create the attachments Record on a Delivery if it actually gets used

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1107:
---
Fix Version/s: (was: 0.12.0)
   0.13.0

> [proton-j] only create the attachments Record on a Delivery if it actually 
> gets used
> 
>
> Key: PROTON-1107
> URL: https://issues.apache.org/jira/browse/PROTON-1107
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.10, 0.11.0, 0.11.1
>    Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> We should only create the attachments Record on a Delivery if it actually 
> gets used.
> When the Reactor bits were added in 0.10 via PROTON-881, all of the main 
> engine objects were made to implement the 'Extendable' interface that gave 
> them an 'attachments' 'Record' that can be used to store things, by default 
> seemingly just details relating to the Handler heirarchy as used by the 
> Reactor.
> In the case of the Delivery objects this currently means every message sent 
> or received by the engine creates a RecordImpl object (which in turn holds a 
> HashMap). This happens regardless of whether the Reactor is even being used, 
> and whether there are any attachments being set/checked on the Delivery. Even 
> when the Reactor is being used, by default the lowest level the Handlers seem 
> to get looked up when process is called is at the Link level (then Session, 
> then Connection, etc) meaning its likely the Delivery attachments will never 
> be used unless by the application code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1107) [proton-j] only create the attachments Record on a Delivery if it actually gets used

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1107:
---
Fix Version/s: (was: 0.13.0)
   0.12.0

> [proton-j] only create the attachments Record on a Delivery if it actually 
> gets used
> 
>
> Key: PROTON-1107
> URL: https://issues.apache.org/jira/browse/PROTON-1107
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.10, 0.11.0, 0.11.1
>    Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> We should only create the attachments Record on a Delivery if it actually 
> gets used.
> When the Reactor bits were added in 0.10 via PROTON-881, all of the main 
> engine objects were made to implement the 'Extendable' interface that gave 
> them an 'attachments' 'Record' that can be used to store things, by default 
> seemingly just details relating to the Handler heirarchy as used by the 
> Reactor.
> In the case of the Delivery objects this currently means every message sent 
> or received by the engine creates a RecordImpl object (which in turn holds a 
> HashMap). This happens regardless of whether the Reactor is even being used, 
> and whether there are any attachments being set/checked on the Delivery. Even 
> when the Reactor is being used, by default the lowest level the Handlers seem 
> to get looked up when process is called is at the Link level (then Session, 
> then Connection, etc) meaning its likely the Delivery attachments will never 
> be used unless by the application code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1110:
--

 Summary: [proton-j] allow suppressing the synthentic flow event 
when sending transfers
 Key: PROTON-1110
 URL: https://issues.apache.org/jira/browse/PROTON-1110
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.11.1
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.12.0


The engine emits synthetic Flow events when sending messages, in addition to 
those raised when receiving a Flow frame for the link. I believe the reasoning 
for this is so to treat it as a 'credit changed' indicator. However, as there 
are cases where the decision to send a message has little at all to do with the 
credit conditions, having these events its often unecessary and wasteful.

A simple toggle will be added to signal the transport not to emit the flow 
events for use in those cases. The default behaviour will be unchanged.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cpp binding failing builds in CI (WAS: [2/2] qpid-proton git commit: PROTON-1062: c++: proton::connection_engine with client and server examples.)

[Robbie Gemmell]

On 24 January 2016 at 07:19,   wrote:
> PROTON-1062: c++: proton::connection_engine with client and server examples.
>
> Easier to use proton::connction_engine:
> - inherit and override io_read, io_write, io_close to provide IO 
> functionality.
> - processing logic (read/write/dispatch) built into connction_engine.
>
> Support for socket IO out of the box
> - socket_engine implements socket-based IO
> - examples/engine/direct_*.cpp simple single connection servers.
> - examples/engine/broker.cpp is a full select-based broker
>   - uses same handler as the reactor broker, only changes the IO logic
>
> Full set of engine-based examples using socket IO.
>
> TODO:
> - Broker example needs to be ported to windows.
> - Documentation& fixes.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo
> Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/b0c66544
> Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/b0c66544
> Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/b0c66544
>
> Branch: refs/heads/master
> Commit: b0c6654486a26e16d3877a23fb9580b4b021f50b
> Parents: e39baba
> Author: Alan Conway 
> Authored: Tue Jan 19 17:16:05 2016 -0500
> Committer: Alan Conway 
> Committed: Sun Jan 24 02:17:49 2016 -0500
>



The CI builds (on ASF Jenkins, Travis, and Appveyor) all appear to
have started failing consistently with this commit, either failing
during compilation or timing out running the examples during test.

Robbie

[jira] [Resolved] (PROTON-1107) [proton-j] only create the attachments Record on a Delivery if it actually gets used

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1107.

Resolution: Fixed

> [proton-j] only create the attachments Record on a Delivery if it actually 
> gets used
> 
>
> Key: PROTON-1107
> URL: https://issues.apache.org/jira/browse/PROTON-1107
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.10, 0.11.0, 0.11.1
>    Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> We should only create the attachments Record on a Delivery if it actually 
> gets used.
> When the Reactor bits were added in 0.10 via PROTON-881, all of the main 
> engine objects were made to implement the 'Extendable' interface that gave 
> them an 'attachments' 'Record' that can be used to store things, by default 
> seemingly just details relating to the Handler heirarchy as used by the 
> Reactor.
> In the case of the Delivery objects this currently means every message sent 
> or received by the engine creates a RecordImpl object (which in turn holds a 
> HashMap). This happens regardless of whether the Reactor is even being used, 
> and whether there are any attachments being set/checked on the Delivery. Even 
> when the Reactor is being used, by default the lowest level the Handlers seem 
> to get looked up when process is called is at the Link level (then Session, 
> then Connection, etc) meaning its likely the Delivery attachments will never 
> be used unless by the application code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1107) [proton-j] only create the attachments Record on a Delivery if it actually gets used

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1107:
--

 Summary: [proton-j] only create the attachments Record on a 
Delivery if it actually gets used
 Key: PROTON-1107
 URL: https://issues.apache.org/jira/browse/PROTON-1107
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.11.1, 0.11.0, 0.10
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.12.0


We should only create the attachments Record on a Delivery if it actually gets 
used.

When the Reactor bits were added in 0.10 via PROTON-881, all of the main engine 
objects were made to implement the 'Extendable' interface that gave them an 
'attachments' 'Record' that can be used to store things, by default seemingly 
just details relating to the Handler heirarchy as used by the Reactor.

In the case of the Delivery objects this currently means every message sent or 
received by the engine creates a RecordImpl object (which in turn holds a 
HashMap). This happens regardless of whether the Reactor is even being used, 
and whether there are any attachments being set/checked on the Delivery. Even 
when the Reactor is being used, by default the lowest level the Handlers seem 
to get looked up when process is called is at the Link level (then Session, 
then Connection, etc) meaning its likely the Delivery attachments will never be 
used unless by the application code.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PROTON-1105) enable EventImpl#getTransport() to succeed in more situations

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1105.

Resolution: Fixed

> enable EventImpl#getTransport() to succeed in more situations
> -
>
> Key: PROTON-1105
> URL: https://issues.apache.org/jira/browse/PROTON-1105
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.1
>    Reporter: Robbie Gemmell
>    Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> Raising JIRA to apply changes similar to those proposed in a PR:
> https://github.com/apache/qpid-proton/pull/58
> EventImpl#getTransport() currently is only able to return a non-null value if 
> the Event context is a Transport or Connection, this change would also enable 
> it to succeed in other situations (if possible, i.e there is a Transport to 
> return).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1105) enable EventImpl#getTransport() to succeed in more situations

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1105:
--

 Summary: enable EventImpl#getTransport() to succeed in more 
situations
 Key: PROTON-1105
 URL: https://issues.apache.org/jira/browse/PROTON-1105
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.11.1
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.12.0


Raising JIRA to apply changes similar to those proposed in a PR:
https://github.com/apache/qpid-proton/pull/58

EventImpl#getTransport() currently is only able to return a non-null value if 
the Event context is a Transport or Connection, this change would also enable 
it to succeed in other situations (if possible, i.e there is a Transport to 
return).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1017) Engine does not handle UNINITALIZED/CLOSED sessions

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1017:
---
Attachment: PROTON-1017-WIP.patch

Attaching a WIP patch.

Isn't complete as its a fairly annoying situation, where the obvious initial 
fix introduce scope of other problems, the fixes to which introduce other 
problems, etc.

It does pass all the existing tests, and the new one committed previously, and 
a further new one in the python suite. The latter shows that proton-c doesn't 
handle the situation well either (whereas proton-j sent the wrong initial Begin 
response, proton-c looks to send no response at all) and presents similar 
issues with fixes.

> Engine does not handle UNINITALIZED/CLOSED sessions
> ---
>
> Key: PROTON-1017
> URL: https://issues.apache.org/jira/browse/PROTON-1017
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.10
>Reporter: Bozo Dragojevic
> Attachments: PROTON-1017-WIP.patch
>
>
> If the initiator sends a BEGIN and END frame the receiving engine processed 
> the END frame before generating the outgoing BEGIN frame and it has no notion 
> of remoteChannel number anymore.
> {noformat}
> [2114881339:0] -> Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1472159463:0] <- Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1472159463:0] -> Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [2114881339:0] <- Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [2114881339:0] -> Begin{remoteChannel=null, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [2114881339:0] -> End{error=null}
> [1472159463:0] <- Begin{remoteChannel=null, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1472159463:0] <- End{error=null}
> [1472159463:0] -> Begin{remoteChannel=65535, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1472159463:0] -> End{error=null}
> [2114881339:0] <- Begin{remoteChannel=65535, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> {noformat}
> test dies with
> {noformat}
> java.lang.NullPointerException: uncorrelated channel: 65535
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.handleBegin(TransportImpl.java:1074)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.handleBegin(TransportImpl.java:1)
>   at org.apache.qpid.proton.amqp.transport.Begin.invoke(Begin.java:144)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.handleFrame(TransportImpl.java:1304)
>   at 
> org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:419)
>   at 
> org.apache.qpid.proton.engine.impl.FrameParser.process(FrameParser.java:528)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.process(TransportImpl.java:1415)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.processInput(TransportImpl.java:1373)
>   at 
> org.apache.qpid.proton.systemtests.EngineTestBase.pumpServerToClient(EngineTestBase.java:73)
>   at 
> org.apache.qpid.proton.systemtests.ProtonEngineExampleTest.testPROTON_TBD(ProtonEngineExampleTest.java:350)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1070) validate the Open frame having been received before other frames

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1070:
---
Affects Version/s: (was: 0.11.0)
   0.12.0

> validate the Open frame having been received before other frames 
> -
>
> Key: PROTON-1070
> URL: https://issues.apache.org/jira/browse/PROTON-1070
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.12.0
>    Reporter: Robbie Gemmell
>
> I recently saw an odd test failure while making changes to some other code 
> (itself using proton-j) that the test was using, even though it seemed like 
> the change should have had no effect on that test. I eventually identified 
> this was due to some unexpected behaviour in other areas that was ultimately 
> occuring because no Open frame had been sent/received, as the original author 
> of the test had not opened the 'client' Connection object. The test should 
> thus never have worked as a result, but it did.
> After some further inspection, it seems that:
> - proton-j can receive and process other frames without the Open arriving, 
> resulting in different 'default' behaviour than if it were.
> - It isnt immediately obvious (to me) whether proton-c guards against the 
> receiving case or not.
> EDIT: the work on proton-j based on the following comments was split out to 
> PROTON-1000:
> - proton-j can emit other frames without first sending the Open frame 
> [because the Connection object wasnt actually opened].
> - proton-c does not appear to, since it guards in various using a check if 
> the open has been sent yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1070) validate the Open frame having been received before other frames

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1070:
---
Description: 
I recently saw an odd test failure while making changes to some other code 
(itself using proton-j) that the test was using, even though it seemed like the 
change should have had no effect on that test. I eventually identified this was 
due to some unexpected behaviour in other areas that was ultimately occuring 
because no Open frame had been sent/received, as the original author of the 
test had not opened the 'client' Connection object. The test should thus never 
have worked as a result, but it did.

After some further inspection, it seems that:
- proton-j can receive and process other frames without the Open arriving, 
resulting in different 'default' behaviour than if it were.
- It isnt immediately obvious (to me) whether proton-c guards against the 
receiving case or not.

EDIT: the work on proton-j based on the following comments was split out to 
PROTON-1000:
- proton-j can emit other frames without first sending the Open frame [because 
the Connection object wasnt actually opened].
- proton-c does not appear to, since it guards in various using a check if the 
open has been sent yet.

  was:
I recently saw an odd test failure while making changes to some other code 
(itself using proton-j) that the test was using, even though it seemed like the 
change should have had no effect on that test. I eventually identified this was 
due to some unexpected behaviour in other areas that was ultimately occuring 
because no Open frame had been sent/received, as the original author of the 
test had not opened the 'client' Connection object. The test should thus never 
have worked as a result, but it did.

After some further inspection, it seems that:
- proton-j can emit other frames without first sending the Open frame [because 
the Connection object wasnt actually opened].
- proton-c does not appear to, since it guards in various using a check if the 
open has been sent yet.
- proton-j can receive and process other frames without the Open arriving, 
resulting in different 'default' behaviour than if it were.
- It isnt immediately obvious (to me) whether proton-c guards against the 
receiving case or not.


Summary: validate the Open frame having been received before other 
frames   (was: other frames can be sent/received without the Open frame having 
been)

Updating title/description to reflect some changes having been made via 
PROTON-1000

> validate the Open frame having been received before other frames 
> -
>
> Key: PROTON-1070
> URL: https://issues.apache.org/jira/browse/PROTON-1070
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.11.0
>Reporter: Robbie Gemmell
>
> I recently saw an odd test failure while making changes to some other code 
> (itself using proton-j) that the test was using, even though it seemed like 
> the change should have had no effect on that test. I eventually identified 
> this was due to some unexpected behaviour in other areas that was ultimately 
> occuring because no Open frame had been sent/received, as the original author 
> of the test had not opened the 'client' Connection object. The test should 
> thus never have worked as a result, but it did.
> After some further inspection, it seems that:
> - proton-j can receive and process other frames without the Open arriving, 
> resulting in different 'default' behaviour than if it were.
> - It isnt immediately obvious (to me) whether proton-c guards against the 
> receiving case or not.
> EDIT: the work on proton-j based on the following comments was split out to 
> PROTON-1000:
> - proton-j can emit other frames without first sending the Open frame 
> [because the Connection object wasnt actually opened].
> - proton-c does not appear to, since it guards in various using a check if 
> the open has been sent yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1100.

Resolution: Fixed

> [proton-j] the transport should not emit other frames before the Open frame 
> has been sent
> -
>
> Key: PROTON-1100
> URL: https://issues.apache.org/jira/browse/PROTON-1100
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.11.0
>    Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.12.0
>
>
> As per PROTON-1070 description, the proton-j transport can emit other frames 
> without first sending the Open frame [because the Connection object wasnt 
> actually opened], which is erroneous behaviour and should be prevented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Include PROTON-1096 in the release Proton-0.12

[Robbie Gemmell]

Fear not Sreeram, the change will be included in 0.12.

The 0.12 alpha was cut from master mainly to serve as a heads up the
release process is going to get under way, and help tease out any
obvious issues before a 0.12.x branch is created to progress the
release via a beta and any subsequent fixups before RCs that can be
voted on. The branch hasnt been created yet, that will occur along
with the beta (originally due today, since postponed a little until
perhaps Monday).

Robbie

On 20 January 2016 at 19:36, Sreeram Kumar Garlapati
 wrote:
> Hello Folks,
>
> Need help getting a feature into proton-0.12 release train – the feature 
> request JIRA : PROTON-1096 
> (corresponding to the GitHub pull request: 
> https://github.com/apache/qpid-proton/pull/53).
>
> My bad. I pushed this change just before the fork of 0.12-alpha and created 
> this feature request against the release 0.12. I downloaded 0.12-alpha 
> (tar.gz) and built it and found that this pull-request missed Alpha. Can 
> someone please help how to get on to 0.12…
>
> PS: We (Windows Azure EventHubs team) are very close to releasing a 
> JavaClient for EventHubs based on 0.12 and badly need this feature for 
> enabling a very crucial scenario. Appreciate your help.
>
> Thanks!
> Sree
>

[jira] [Created] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1100:
--

 Summary: [proton-j] the transport should not emit other frames 
before the Open frame has been sent
 Key: PROTON-1100
 URL: https://issues.apache.org/jira/browse/PROTON-1100
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.11.0
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.12.0


As per PROTON-1070 description, the proton-j transport can emit other frames 
without first sending the Open frame [because the Connection object wasnt 
actually opened], which is erroneous behaviour and should be prevented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (PROTON-259) engine operations do not check if the endpoint is already closed

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell closed PROTON-259.
-
Resolution: Not A Problem

Closing based on earlier discussion.

> engine operations do not check if the endpoint is already closed
> 
>
> Key: PROTON-259
> URL: https://issues.apache.org/jira/browse/PROTON-259
> Project: Qpid Proton
>  Issue Type: Bug
>Affects Versions: 0.3
>Reporter: Philip Harvey
>
> Operations such as SessionImpl#receiver(receiverName) and LinkImpl#delivery 
> do not check the state of the endpoint.  I believe they should throw an 
> exception.
> Moreover, I notice that the following sequence of calls cause the transport 
> to produce no output:
> ---
> sender.close;
> // deliberately use a closed sender.
> // The presence of this line causes the subsequent transport.output to 
> produce zero bytes.
> sender.delivery(deliveryTag);
> transport.output(); 
> ---



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-259) engine operations do not check if the endpoint is already closed

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-259:
--
   Assignee: (was: Philip Harvey)
Component/s: (was: proton-j)
Summary: engine operations do not check if the endpoint is already 
closed  (was: proton-j engine operations do not check if the endpoint is 
already closed)

> engine operations do not check if the endpoint is already closed
> 
>
> Key: PROTON-259
> URL: https://issues.apache.org/jira/browse/PROTON-259
> Project: Qpid Proton
>  Issue Type: Bug
>Affects Versions: 0.3
>Reporter: Philip Harvey
>
> Operations such as SessionImpl#receiver(receiverName) and LinkImpl#delivery 
> do not check the state of the endpoint.  I believe they should throw an 
> exception.
> Moreover, I notice that the following sequence of calls cause the transport 
> to produce no output:
> ---
> sender.close;
> // deliberately use a closed sender.
> // The presence of this line causes the subsequent transport.output to 
> produce zero bytes.
> sender.delivery(deliveryTag);
> transport.output(); 
> ---



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)