Proton-j Reactor - Receiver

[Garlapati Sreeram Kumar]

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

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

[Jack Gibson (JIRA)]

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

Jack Gibson updated PROTON-1168:

Description: 
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 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data size=205 )
Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO Layer, 0 
left over
Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR amqp:connection:framing-error 
SSL Failure: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did 
not return a certificate
Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:  <- EOS
Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:  -> EOS
Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL socket freed.

For your reference please find the attached client/server code which is written 
using the proton C where the 2 way SSL worked fine. (send_with_ssl.c & 
recv_with_ssl.c)


  was:
To 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). Code Repository with our client changes - : 
https://github.paypal.com/sivthiyagarajan/amqp-client
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 

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

[Jack Gibson (JIRA)]

Jack Gibson created PROTON-1168:
---

 Summary: 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






--
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=15219039#comment-15219039
 ] 

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

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

PROTON-1153, PROTON-1153: [C++ binding] Align code with API doc
- Remove sender/receiver/session member functions no longer needed
- Removed sasl member functions not needed
- Made private some sasl member functions that shouldn't be exposed to API
- Made condition and sasl object not user creatable or copyable


> [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-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=15219040#comment-15219040
 ] 

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

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

PROTON-1153, PROTON-1153: [C++ binding] Align code with API doc
- Remove sender/receiver/session member functions no longer needed
- Removed sasl member functions not needed
- Made private some sasl member functions that shouldn't be exposed to API
- Made condition and sasl object not user creatable or copyable


> [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)

RE: Proton-j: SendLink flow control

[Garlapati Sreeram Kumar]

Thanks a lot Robbie.

Sent from Mail for Windows 10

From: Robbie Gemmell
Sent: Wednesday, March 30, 2016 2:27 AM
To: proton@qpid.apache.org
Subject: Re: Proton-j: SendLink flow control

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

[jira] [Commented] (PROTON-1167) Qpid-proton: SIGSEGV crash when a queue becomes full

[Gordon Sim (JIRA)]

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

Gordon Sim commented on PROTON-1167:


I wasn't able to reproduce this, either on latest svn/git for qpid/proton, or 
on qpid-cpp 0.34 against proton 0.12 (this requires a minor patch to qpid-cpp 
in order to compile it). Did you build qpid-cpp 0.34 yourself against 0.12? How 
reproducible is it for you?

> Qpid-proton: SIGSEGV crash when a queue becomes full
> 
>
> Key: PROTON-1167
> URL: https://issues.apache.org/jira/browse/PROTON-1167
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.12.0
> Environment: CentOS7 (latest)
> qpid-proton-c-0.12.0-1.el7.x86_64
>Reporter: Graham Leggett
>
> When qpid is asked to create a default queue as follows:
> {code}
> qpid-config add queue foo
> {code}
> And if an attempt is made to fill this queue to overflow with 1MB messages 
> until we run out of space, qpid crashes as follows:
> {code}
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002 
> decoded 65536 bytes from 65536
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002 
> decoded 1016 bytes from 1016
> 2016-03-29 22:18:59 [Broker] debug received delivery: 
> \xE4\x03\x00\x00\x00\x00\x00\x00
> 2016-03-29 22:18:59 [Broker] debug Message received: 1049552 bytes
> 2016-03-29 22:18:59 [System] debug Exception constructed: Maximum depth 
> exceeded on foo: current=[count: 125, size: 103905496], max=[size: 104857600] 
> (/builddir/build/BUILD/qpid-cpp-0.34/src/qpid/broker/Queue.cpp:1633)
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002 
> encoded 249 bytes from 65536
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002 
> decoded 51 bytes from 51
> 2016-03-29 22:18:59 [Broker] debug received delivery: 
> \xE4\x03\x00\x00\x00\x00\x00\x00
> 2016-03-29 22:18:59 [Broker] debug Message received: 0 bytes
> 2016-03-29 22:18:59 [Broker] debug clean(): 125 messages remain; head is now 0
> 2016-03-29 22:18:59 [Broker] debug Message 0x69b2e0 published, state is 1 
> (head is now 0)
> 2016-03-29 22:18:59 [Broker] debug Message 126 enqueued on foo
> Program received signal SIGSEGV, Segmentation fault.
> pni_process_tpwork_receiver (settle=, delivery=0x698550, 
> transport=0x7fffec01c710)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2147
> 2147if ((int16_t) ssn->state.local_channel >= 0 && 
> !delivery->remote.settled && delivery->state.init) {
> Missing separate debuginfos, use: debuginfo-install 
> boost-program-options-1.53.0-25.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 
> krb5-libs-1.13.2-10.el7.x86_64 libaio-0.3.109-13.el7.x86_64 
> libcom_err-1.42.9-7.el7.x86_64 libdb4-cxx-4.8.30-13.el7.x86_64 
> libselinux-2.2.2-6.el7.x86_64 libuuid-2.23.2-26.el7.x86_64 
> nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64 pcre-8.32-15.el7.x86_64 
> xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64
> (gdb) bt
> #0  pni_process_tpwork_receiver (settle=, 
> delivery=0x698550, transport=0x7fffec01c710)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2147
> #1  pni_process_tpwork (transport=transport@entry=0x7fffec01c710, 
> endpoint=)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2181
> #2  0x73a898c1 in pni_process_tpwork (endpoint=, 
> transport=0x7fffec01c710)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2164
> #3  pni_phase (phase=, transport=0x7fffec01c710)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2381
> #4  pni_process (transport=) at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2399
> #5  pn_output_write_amqp (transport=, layer=, 
> bytes=0x7fffec00bf80 "", available=16384)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2550
> #6  0x73a8aacc in transport_produce 
> (transport=transport@entry=0x7fffec01c710)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2603
> #7  pn_transport_pending (transport=transport@entry=0x7fffec01c710)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2882
> #8  0x73a8acd7 in pn_transport_output (transport=0x7fffec01c710, 
> bytes=0x7fffec02f280 "", size=65536)
> at 
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2630
> #9  0x73d046ee in qpid::broker::amqp::Connection::encode 
> (this=0x7fffec007780, buffer=0x7fffec02f280 "", size=65536)
> at /usr/src/debug/qpid-cpp-0.34/src/qpid/broker/amqp/Connection.cpp:233
> #10 0x7749b3c4 in qpid::sys::AsynchIOHandler::idle 
> (this=0x7fffec01ca30)

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

[Timothy Bish]

+1

On 03/30/2016 06:25 AM, 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
.




--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

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

[Ken Giusti]

+1

- Original Message -
> From: "Robbie Gemmell" 
> To: us...@qpid.apache.org, proton@qpid.apache.org
> Sent: Wednesday, March 30, 2016 6:25:34 AM
> Subject: [VOTE] merge the proton mailing list into the users/dev lists
> 
> 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
> 

-- 
-K

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

[Justin Ross]

+1

On Wed, Mar 30, 2016 at 5:17 AM, Chuck Rolke  wrote:

> +1
>
> - Original Message -
> > From: "Robbie Gemmell" 
> > To: us...@qpid.apache.org, proton@qpid.apache.org
> > Sent: Wednesday, March 30, 2016 6:25:34 AM
> > Subject: [VOTE] merge the proton mailing list into the users/dev lists
> >
> > 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
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

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

[Chuck Rolke]

+1

- Original Message -
> From: "Robbie Gemmell" 
> To: us...@qpid.apache.org, proton@qpid.apache.org
> Sent: Wednesday, March 30, 2016 6:25:34 AM
> Subject: [VOTE] merge the proton mailing list into the users/dev lists
> 
> 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

[Fraser Adams]

+1

On 30/03/16 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

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

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

[Ted Ross]

+1

And a separate +1 to Rob's suggestion.

-Ted

On 03/30/2016 06:30 AM, 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

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

[Gordon Sim (JIRA)]

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

Gordon Sim commented on PROTON-1135:


My 2 cents: servers SHOULD handle the pipelined case (in the case of qpidd, I 
consider it a bug in the io handling rather than a concious choice, and I would 
guess the same is true of others). That said I do also think that proton is 
doing the wrong thing with sasl on the client and should wait for the server to 
offer mechanisms before choosing them. It MUST do this when a specific 
mechanism isn't chosen anyway (at least when integrated with cyrus), and even 
where it is I think it would provide clearer error information. Less of a 
concern (to me anyway) is pipelining the open before receiving a successful 
outcome.

> [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@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)

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

[Jakub Scholz]

+1

On Wed, Mar 30, 2016 at 1:01 PM, Kai  wrote:

> +1
>
> On Wed, Mar 30, 2016 at 12:25 PM 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

[Kai]

+1

On Wed, Mar 30, 2016 at 12:25 PM 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

[Gordon Sim]

+1

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

[Kritikos, Alex]

+1




On 30/03/16 13: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
>>
This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying, 
or use of this communication or the information in it, is strictly prohibited. 
If you have received this communication in error please notify us by e-mail and 
then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - 
http://www.softwareag.com/uk

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

[Rob Godfrey]

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

[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