[jira] [Commented] (PROTON-1164) Update handlers to align with current proposal

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1164:
-

Commit 3ca3cb3b519c38b1da917449cc6545cc25714315 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3ca3cb3 ]

PROTON-1164: [C++ binding] Add a container accessor to object hierarchy
- This allows simple access to all layers of the object model
  from every object type that can bre passed to a handler


> Update handlers to align with current proposal
> --
>
> Key: PROTON-1164
> URL: https://issues.apache.org/jira/browse/PROTON-1164
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> The current event handler proposal includes the primary object that the event 
> is concerned with in the handler signature. This makes it more convenient to 
> process the event by giving the most likely object to be needed directly to 
> the handler without any other lookups.



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

[jira] [Commented] (PROTON-1153) [C++ binding] Tidy up various details

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1153:
-

Commit ac5d3c6871fed288cec36f8a7d9473a14033dfe7 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ac5d3c6 ]

PROTON-1153: [C++ binding] Remove all data members from proton_handler
- It's now a pure interface
  - This does mean that you currently create more pn_handler_t structs
than before, but they could be cached somewhere else.


> [C++ binding] Tidy up various details
> -
>
> Key: PROTON-1153
> URL: https://issues.apache.org/jira/browse/PROTON-1153
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>




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

[jira] [Commented] (PROTON-1164) Update handlers to align with current proposal

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1164:
-

Commit edd8bc57b41f77752779110790a4399cc91eebd5 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=edd8bc5 ]

PROTON-1164: [C++ binding] Remove the proton::event parameter from handler 
invocations
- It was no longer needed as there is now always a parameter that gives you
  access to the object tree.
- Consequently removed the proton::event interface
  and its implementation class proton::messaging_event
- Fixed all the examples


> Update handlers to align with current proposal
> --
>
> Key: PROTON-1164
> URL: https://issues.apache.org/jira/browse/PROTON-1164
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> The current event handler proposal includes the primary object that the event 
> is concerned with in the handler signature. This makes it more convenient to 
> process the event by giving the most likely object to be needed directly to 
> the handler without any other lookups.



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

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
> Sent: Thursday, March 31, 2016 9:19 AM
> To: 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

[GitHub] qpid-proton pull request: Schema parsing should not be so greedy

[hekonsek]

Github user hekonsek closed the pull request at:

https://github.com/apache/qpid-proton/pull/65


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] qpid-proton pull request: Schema parsing should not be so greedy

[hekonsek]

Github user hekonsek commented on the pull request:

https://github.com/apache/qpid-proton/pull/65#issuecomment-206744093
  
Done :) .


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---