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

[Alan Conway]

+1

On Wed, 2016-03-30 at 11:25 +0100, 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: 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

[GitHub] qpid-proton pull request: NO-JIRA: Fix break in Javascript binding...

[prestona]

Github user prestona commented on the pull request:

https://github.com/apache/qpid-proton/pull/72#issuecomment-203982961
  
Hi @astitcher - I've added a second commit which uses ${Proton_SOURCE_DIR}, 
as per your comment.  If the CI builds complete successfully then: yes I would 
appreciate it if someone could merge this on my behalf.


---
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: NO-JIRA: Fix break in Javascript binding...

[astitcher]

Github user astitcher commented on the pull request:

https://github.com/apache/qpid-proton/pull/72#issuecomment-203974958
  
This looks fine modulo the inline comment.

Do you need someone else to merge it?


---
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: NO-JIRA: Fix break in Javascript binding...

[prestona]

GitHub user prestona opened a pull request:

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

NO-JIRA: Fix break in Javascript bindings build

Attempting to build Proton with Emscripten on the path fails with the 
following
message:
/home/prestona/git/qpid-proton/examples/c/messenger/recv-async.c:26:10: 
fatal
error: 'pncompat/misc_funcs.inc' file not found
#include "pncompat/misc_funcs.inc"
 ^
1 error generated.

This appears to have been introduced by commit
84e416e389fe74ec7a1cab9252af2342fc95b83f

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/prestona/qpid-proton javascript_build_break

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/72.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #72


commit 46f949699531b873f10b301aae0e73ff1ed8220a
Author: Adrian Preston 
Date:   2016-03-31T13:10:34Z

NO-JIRA: Fix break in Javascript bindings build

Attempting to build Proton with Emscripten on the path fails with the 
following
message:
/home/prestona/git/qpid-proton/examples/c/messenger/recv-async.c:26:10: 
fatal
error: 'pncompat/misc_funcs.inc' file not found
#include "pncompat/misc_funcs.inc"
 ^
1 error generated.

This appears to have been introduced by commit
84e416e389fe74ec7a1cab9252af2342fc95b83f




---
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.
---

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

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher reassigned PROTON-1135:
---

Assignee: Andrew Stitcher

> [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
>Assignee: Andrew Stitcher
>
> 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.



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