Re: Settlement [Was: Re: 0.2 RC2]

2012-11-05 Thread Rafael Schloming
On Mon, Nov 5, 2012 at 5:57 PM, Justin Ross  wrote:

> Ted mentioned that with 0.2 came a change in settlement behavior.
> Deliveries are now pre-settled.
>
> As a matter of default api behavior, what's the rationale for pre-settling
> rather than auto settling deliveries?  I have no particular preference; I'm
> aiming to understand the principle involved.
>

I'm not sure exactly what you mean by auto-settling, but in 0.1 the default
(and only) behavior was at-most-once. Although it the impl didn't
pre-settle, it ignored disposition updates and therefore provided the same
semantics as if it had pre-settled. The fact that in 0.2 the implementation
no longer ignores disposition updates means that the easiest way to
preserve the at-most-once semantics is to send pre-settled.

--Rafael


Re: [VOTE] 0.2 RC4

2012-11-05 Thread Darryl L. Pierce
On Mon, Nov 05, 2012 at 10:37:34PM +0100, Rafael Schloming wrote:
> On Mon, Nov 5, 2012 at 6:08 PM, Robbie Gemmell 
> wrote:
> 
> > Surely its going to be in /dist/qpid/proton since its a sub project?
> >
> 
> Oops, I misread the post. It will be exactly where 0.1 is except it will
> say 0.2 instead:
> 
>   http://www.apache.org/dist/qpid/proton/0.1/qpid-proton-c-0.1.tar.gz

Cool. I'll update the specfile appropriately.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpiKVIHZpCb5.pgp
Description: PGP signature


Re: [VOTE] 0.2 RC4

2012-11-05 Thread Rafael Schloming
On Mon, Nov 5, 2012 at 6:08 PM, Robbie Gemmell wrote:

> Surely its going to be in /dist/qpid/proton since its a sub project?
>

Oops, I misread the post. It will be exactly where 0.1 is except it will
say 0.2 instead:

  http://www.apache.org/dist/qpid/proton/0.1/qpid-proton-c-0.1.tar.gz

--Rafael


>
> Robbie
>
> On 5 November 2012 16:11, Rafael Schloming  wrote:
>
> > On Mon, Nov 5, 2012 at 3:54 PM, Darryl L. Pierce 
> > wrote
> > >
> > > Will the final, official URL for the source be:
> > >
> > > http://www.apache.org/dist/proton/$VER/qpid-proton-c-$VER.tar.gz
> > >
> > > ? I'd like to clean up another rpmlint error where it doesn't like a
> > > non-URI value for the source.
> >
> >
> > Yes, with the caveat that I believe we (qpid) are encouraged to switch
> over
> > to using svnpubsub for publishing releases at some point. I don't know
> > if/how this will impact the convention for future releases beyond that
> > point.
> >
> > --Rafael
> >
>


[jira] [Created] (PROTON-121) Platform specific code is mixed in with platform independent code

2012-11-05 Thread Andrew Stitcher (JIRA)
Andrew Stitcher created PROTON-121:
--

 Summary: Platform specific code is mixed in with platform 
independent code
 Key: PROTON-121
 URL: https://issues.apache.org/jira/browse/PROTON-121
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Andrew Stitcher


the function pn_error_from errno() is platform specific and so should not be in 
error.c which is (everywhere else) purely platform independent.

It should be moved to a platform (POSIX) specific file (perhaps a file with 
only this single function).

[The clue for this is the #define POSIX_C_SOURCE at the top of error.c]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PROTON-60) Support configuring the max frame size.

2012-11-05 Thread Ken Giusti (JIRA)

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

Ken Giusti commented on PROTON-60:
--

Just for reference:

This commit:

http://svn.apache.org/viewvc?view=revision&revision=1401094

adds get/set max-frame api to proton-c at the engine interface.

> Support configuring the max frame size.
> ---
>
> Key: PROTON-60
> URL: https://issues.apache.org/jira/browse/PROTON-60
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Reporter: Hiram Chirino
>  Labels: api
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (PROTON-120) Link.delivery() signature takes offset and size which are not used

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim reassigned PROTON-120:
-

Assignee: Gordon Sim

> Link.delivery() signature takes offset and size which are not used
> --
>
> Key: PROTON-120
> URL: https://issues.apache.org/jira/browse/PROTON-120
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Minor
> Fix For: 0.3
>
> Attachments: delivery_signature.patch
>
>
> One option is that these should be used. Another is that they can be removed 
> from the API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PROTON-118) Add support for Messenger API

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim commented on PROTON-118:
---

Two deviations from the C to highlight:

(i) at present the Sender.unsettled() method isn't implemented so I couldn't 
rely on that for determining when send() can stop blocking. That is a temporary 
deviation only, just to make some progress with the rest of it.

(ii) in matching a message's address to a connection, I use the context on the 
connection to hold the host:port combination used to create it and match 
against that. This is in part because I was confused about the respective 
meaning of hostname and remote-hostname, and the facet that one has only a 
setter, the other only a getter. However it also seemed wrong to append the 
port to a 'hostname'  (which seems to be what the C impl does). Thoughts on 
that particularly welcome.

> Add support for Messenger API
> -
>
> Key: PROTON-118
> URL: https://issues.apache.org/jira/browse/PROTON-118
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.3
>
> Attachments: driver.patch, engine.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (PROTON-119) Engine can switch from SASL to plain AMQP transport too soon

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim resolved PROTON-119.
---

Resolution: Fixed

> Engine can switch from SASL to plain AMQP transport too soon
> 
>
> Key: PROTON-119
> URL: https://issues.apache.org/jira/browse/PROTON-119
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.3
>
> Attachments: sasl_engine.patch
>
>
> The engine gets output from the AMQP engine rather than SASL wrapper as soon 
> as the SASl negotiation is marked as done. In the case where the 'server' 
> only supports ANONYMOUS and immediately sends an outcome without actually 
> waiting for the initial frame from the client, this happens too soon, before 
> the init is sent (and even the SASL header).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (PROTON-119) Engine can switch from SASL to plain AMQP transport too soon

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim reassigned PROTON-119:
-

Assignee: Gordon Sim

> Engine can switch from SASL to plain AMQP transport too soon
> 
>
> Key: PROTON-119
> URL: https://issues.apache.org/jira/browse/PROTON-119
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.3
>
> Attachments: sasl_engine.patch
>
>
> The engine gets output from the AMQP engine rather than SASL wrapper as soon 
> as the SASl negotiation is marked as done. In the case where the 'server' 
> only supports ANONYMOUS and immediately sends an outcome without actually 
> waiting for the initial frame from the client, this happens too soon, before 
> the init is sent (and even the SASL header).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-118) Add support for Messenger API

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim updated PROTON-118:
--

Attachment: engine.patch
driver.patch

This is just an early preview of my initial stab at a messenger API. It doesn't 
yet do the reply-to munging, nor does it have the new acknowledgement stuff. 
Otherwise its more or less a straightforward port from the C version.

It works against the C implementation for simple send and receive examples, but 
does not yet support SSL (or SASL beyond ANONYMOUS).

The patch is split in two pieces for easier review. The driver patch makes some 
minor modifications to the driver API (adds ability to get at all connectors, 
as does the C version; changed from int to long for timeout; throw rather than 
swallow the IOExceptions from process). It also makes some more significant 
changes to the ConnectorImpl. This is largely so that it behaves like the C 
version (allowing a closer mirroring of the messenger impl).

The second patch adds the new messenger interface and an implementation. I've 
kept the separation between impl and interface that appears to be the pattern 
elsewhere but haven't added any factory yet which might be desirable to avoid 
code being tied directly to an impl class.

As I say, this is very much still work-in-progress but I thought it might be 
useful to get early feedback, collaborate with others interested etc etc.

> Add support for Messenger API
> -
>
> Key: PROTON-118
> URL: https://issues.apache.org/jira/browse/PROTON-118
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.3
>
> Attachments: driver.patch, engine.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (PROTON-118) Add support for Messenger API

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim reassigned PROTON-118:
-

Assignee: Gordon Sim

> Add support for Messenger API
> -
>
> Key: PROTON-118
> URL: https://issues.apache.org/jira/browse/PROTON-118
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.3
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-119) Engine can switch from SASL to plain AMQP transport too soon

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim updated PROTON-119:
--

Attachment: sasl_engine.patch

One possible fix... this simply adds a flag to track whether the init has been 
sent and uses that in deciding when to switch output.

> Engine can switch from SASL to plain AMQP transport too soon
> 
>
> Key: PROTON-119
> URL: https://issues.apache.org/jira/browse/PROTON-119
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
> Fix For: 0.3
>
> Attachments: sasl_engine.patch
>
>
> The engine gets output from the AMQP engine rather than SASL wrapper as soon 
> as the SASl negotiation is marked as done. In the case where the 'server' 
> only supports ANONYMOUS and immediately sends an outcome without actually 
> waiting for the initial frame from the client, this happens too soon, before 
> the init is sent (and even the SASL header).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-120) Link.delivery() signature takes offset and size which are not used

2012-11-05 Thread Gordon Sim (JIRA)

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

Gordon Sim updated PROTON-120:
--

Attachment: delivery_signature.patch

This patch changes the signature, removing the offset and size. The other 
option is to use the offset and size. If that route is intended, I can add a 
patch for that instead.

> Link.delivery() signature takes offset and size which are not used
> --
>
> Key: PROTON-120
> URL: https://issues.apache.org/jira/browse/PROTON-120
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.1, 0.2
>Reporter: Gordon Sim
>Priority: Minor
> Fix For: 0.3
>
> Attachments: delivery_signature.patch
>
>
> One option is that these should be used. Another is that they can be removed 
> from the API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (PROTON-120) Link.delivery() signature takes offset and size which are not used

2012-11-05 Thread Gordon Sim (JIRA)
Gordon Sim created PROTON-120:
-

 Summary: Link.delivery() signature takes offset and size which are 
not used
 Key: PROTON-120
 URL: https://issues.apache.org/jira/browse/PROTON-120
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.1, 0.2
Reporter: Gordon Sim
Priority: Minor
 Fix For: 0.3


One option is that these should be used. Another is that they can be removed 
from the API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (PROTON-119) Engine can switch from SASL to plain AMQP transport too soon

2012-11-05 Thread Gordon Sim (JIRA)
Gordon Sim created PROTON-119:
-

 Summary: Engine can switch from SASL to plain AMQP transport too 
soon
 Key: PROTON-119
 URL: https://issues.apache.org/jira/browse/PROTON-119
 Project: Qpid Proton
  Issue Type: New Feature
  Components: proton-j
Affects Versions: 0.1, 0.2
Reporter: Gordon Sim
 Fix For: 0.3


The engine gets output from the AMQP engine rather than SASL wrapper as soon as 
the SASl negotiation is marked as done. In the case where the 'server' only 
supports ANONYMOUS and immediately sends an outcome without actually waiting 
for the initial frame from the client, this happens too soon, before the init 
is sent (and even the SASL header).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (PROTON-118) Add support for Messenger API

2012-11-05 Thread Gordon Sim (JIRA)
Gordon Sim created PROTON-118:
-

 Summary: Add support for Messenger API
 Key: PROTON-118
 URL: https://issues.apache.org/jira/browse/PROTON-118
 Project: Qpid Proton
  Issue Type: New Feature
  Components: proton-j
Affects Versions: 0.1, 0.2
Reporter: Gordon Sim
 Fix For: 0.3




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (PROTON-117) Consider replacing org.apache.qpid.proton.engine.Sequence with java.util.Iterator

2012-11-05 Thread Hiram Chirino (JIRA)
Hiram Chirino created PROTON-117:


 Summary: Consider replacing org.apache.qpid.proton.engine.Sequence 
with java.util.Iterator
 Key: PROTON-117
 URL: https://issues.apache.org/jira/browse/PROTON-117
 Project: Qpid Proton
  Issue Type: Bug
Reporter: Hiram Chirino


The Sequence interface looks an like an Iterator, perhaps we should just use it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


Re: [VOTE] 0.2 RC4

2012-11-05 Thread Robbie Gemmell
Surely its going to be in /dist/qpid/proton since its a sub project?

Robbie

On 5 November 2012 16:11, Rafael Schloming  wrote:

> On Mon, Nov 5, 2012 at 3:54 PM, Darryl L. Pierce 
> wrote
> >
> > Will the final, official URL for the source be:
> >
> > http://www.apache.org/dist/proton/$VER/qpid-proton-c-$VER.tar.gz
> >
> > ? I'd like to clean up another rpmlint error where it doesn't like a
> > non-URI value for the source.
>
>
> Yes, with the caveat that I believe we (qpid) are encouraged to switch over
> to using svnpubsub for publishing releases at some point. I don't know
> if/how this will impact the convention for future releases beyond that
> point.
>
> --Rafael
>


[jira] [Commented] (PROTON-116) Proton sends explicit disposition for pre-settled messages

2012-11-05 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming commented on PROTON-116:


It's not illegal to send the spurious disposition, however you're correct that 
it's not needed.

> Proton sends explicit disposition for pre-settled messages
> --
>
> Key: PROTON-116
> URL: https://issues.apache.org/jira/browse/PROTON-116
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.2
>Reporter: Ted Ross
>Priority: Minor
>
> When proton sends pre-settled messages (the settled flag is set in the 
> transfer), it follows up with an explicit disposition frame for the message.
> I believe this disposition update is spurious and unneeded, though I haven't 
> found a definitive statement one way or the other in the protocol 
> specification.
> [0x1efaaa0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 8, null, false]
> [0x1efaaa0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, 
> true, false] (184)
> [0x1efaaa0:1] <- TRANSFER @20 [1, 1, b"\x01\x00\x00\x00\x00\x00\x00\x00", 0, 
> true, false] (184)
> [0x1efaaa0:1] <- TRANSFER @20 [1, 2, b"\x02\x00\x00\x00\x00\x00\x00\x00", 0, 
> true, false] (184)
> [0x1efaaa0:1] <- DISPOSITION @21 [false, 0, 2, true, null]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


Settlement [Was: Re: 0.2 RC2]

2012-11-05 Thread Justin Ross
Ted mentioned that with 0.2 came a change in settlement behavior. 
Deliveries are now pre-settled.


As a matter of default api behavior, what's the rationale for pre-settling 
rather than auto settling deliveries?  I have no particular preference; 
I'm aiming to understand the principle involved.


Justin

On Fri, 2 Nov 2012, Rafael Schloming wrote:


Hi, I put a new RC up with the library versions fixed. This shouldn't
invalidate any testing done on RC1, but for additional testing please use
RC2:

http://people.apache.org/~rhs/qpid-proton-0.2rc2/

--Rafael



[jira] [Created] (PROTON-116) Proton sends explicit disposition for pre-settled messages

2012-11-05 Thread Ted Ross (JIRA)
Ted Ross created PROTON-116:
---

 Summary: Proton sends explicit disposition for pre-settled messages
 Key: PROTON-116
 URL: https://issues.apache.org/jira/browse/PROTON-116
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.2
Reporter: Ted Ross
Priority: Minor


When proton sends pre-settled messages (the settled flag is set in the 
transfer), it follows up with an explicit disposition frame for the message.

I believe this disposition update is spurious and unneeded, though I haven't 
found a definitive statement one way or the other in the protocol specification.

[0x1efaaa0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 8, null, false]
[0x1efaaa0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, 
true, false] (184)
[0x1efaaa0:1] <- TRANSFER @20 [1, 1, b"\x01\x00\x00\x00\x00\x00\x00\x00", 0, 
true, false] (184)
[0x1efaaa0:1] <- TRANSFER @20 [1, 2, b"\x02\x00\x00\x00\x00\x00\x00\x00", 0, 
true, false] (184)
[0x1efaaa0:1] <- DISPOSITION @21 [false, 0, 2, true, null]


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


Re: [VOTE] 0.2 RC4

2012-11-05 Thread Rafael Schloming
On Mon, Nov 5, 2012 at 3:54 PM, Darryl L. Pierce  wrote
>
> Will the final, official URL for the source be:
>
> http://www.apache.org/dist/proton/$VER/qpid-proton-c-$VER.tar.gz
>
> ? I'd like to clean up another rpmlint error where it doesn't like a
> non-URI value for the source.


Yes, with the caveat that I believe we (qpid) are encouraged to switch over
to using svnpubsub for publishing releases at some point. I don't know
if/how this will impact the convention for future releases beyond that
point.

--Rafael


Re: [VOTE] 0.2 RC4

2012-11-05 Thread Rajith Attapattu
[x] Ship it. Reviewed the C code change with Rafi.

Rajith

On Mon, Nov 5, 2012 at 7:29 AM, Rob Godfrey  wrote:
> [X] Ship it! (Release RC4 as 0.2)
>
> Tested java and reviewed C change.
>
> -- Rob
>
> On 5 November 2012 13:19, Rafael Schloming  wrote:
>
>> Posted here: http://people.apache.org/~rhs/qpid-proton-0.2rc4/
>>
>> [ ] Ship it! (Release RC4 as 0.2)
>> [ ] No (We need another RC because...)
>>
>> The only difference between RC3 and RC4 for proton-c is a one line change
>> in engine.c that ensures that pn_transport_output will not fail to produce
>> output under particular conditions despite there being output to produce.
>> There was also a public accessor added in proton-j. Both of these are very
>> small and sufficiently isolated changes that they shouldn't impact any
>> testing that has been done on RC3. I've attached the total diff in case
>> anyone wants to check it out. I'm hoping we can still get enough votes to
>> do a release tonight so please have a look and give it your +1 if it checks
>> out.
>>
>> --Rafael
>>


Re: [VOTE] 0.2 RC4

2012-11-05 Thread Darryl L. Pierce
On Mon, Nov 05, 2012 at 07:19:30AM -0500, Rafael Schloming wrote:
> Posted here: http://people.apache.org/~rhs/qpid-proton-0.2rc4/
> 
> [X] Ship it! (Release RC4 as 0.2)
> [ ] No (We need another RC because...)
> 
> The only difference between RC3 and RC4 for proton-c is a one line change
> in engine.c that ensures that pn_transport_output will not fail to produce
> output under particular conditions despite there being output to produce.
> There was also a public accessor added in proton-j. Both of these are very
> small and sufficiently isolated changes that they shouldn't impact any
> testing that has been done on RC3. I've attached the total diff in case
> anyone wants to check it out. I'm hoping we can still get enough votes to
> do a release tonight so please have a look and give it your +1 if it checks
> out.

Will the final, official URL for the source be:

http://www.apache.org/dist/proton/$VER/qpid-proton-c-$VER.tar.gz

? I'd like to clean up another rpmlint error where it doesn't like a
non-URI value for the source.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgprHYchqOaf1.pgp
Description: PGP signature


Re: [VOTE] 0.2 RC4

2012-11-05 Thread Rob Godfrey
[X] Ship it! (Release RC4 as 0.2)

Tested java and reviewed C change.

-- Rob

On 5 November 2012 13:19, Rafael Schloming  wrote:

> Posted here: http://people.apache.org/~rhs/qpid-proton-0.2rc4/
>
> [ ] Ship it! (Release RC4 as 0.2)
> [ ] No (We need another RC because...)
>
> The only difference between RC3 and RC4 for proton-c is a one line change
> in engine.c that ensures that pn_transport_output will not fail to produce
> output under particular conditions despite there being output to produce.
> There was also a public accessor added in proton-j. Both of these are very
> small and sufficiently isolated changes that they shouldn't impact any
> testing that has been done on RC3. I've attached the total diff in case
> anyone wants to check it out. I'm hoping we can still get enough votes to
> do a release tonight so please have a look and give it your +1 if it checks
> out.
>
> --Rafael
>


[VOTE] 0.2 RC4

2012-11-05 Thread Rafael Schloming
Posted here: http://people.apache.org/~rhs/qpid-proton-0.2rc4/

[ ] Ship it! (Release RC4 as 0.2)
[ ] No (We need another RC because...)

The only difference between RC3 and RC4 for proton-c is a one line change
in engine.c that ensures that pn_transport_output will not fail to produce
output under particular conditions despite there being output to produce.
There was also a public accessor added in proton-j. Both of these are very
small and sufficiently isolated changes that they shouldn't impact any
testing that has been done on RC3. I've attached the total diff in case
anyone wants to check it out. I'm hoping we can still get enough votes to
do a release tonight so please have a look and give it your +1 if it checks
out.

--Rafael


Re: [VOTE] 0.2 RC3

2012-11-05 Thread Rafael Schloming
-1

Sadly I have to vote against myself due to a bug I just found. Will follow
up with RC4 presently.

--Rafael

On Sun, Nov 4, 2012 at 7:09 PM, Rafael Schloming  wrote:

> Hi, I did a bit more testing over the weekend and posted an RC3 here:
>
> http://people.apache.org/~rhs/qpid-proton-0.2rc3
>
> The only changes are fixing a minor bug in the ack stuff and adding the C
> examples. Given that the delta from 0.1 is quite contained, I'm going to
> optimistically call for a release vote based on RC3. Please check it out
> and give your +1 if it looks good. I'd like to do the same 24 hour thingy
> as last time so I can post the release tomorrow if there are no serious
> issues.
>
> [ ] Ship it! (Release 0.2 RC3 as 0.2)
> [ ] No! (We need to fix ...)
>
> --Rafael
>
>


[jira] [Updated] (PROTON-115) Expose API to access link name.

2012-11-05 Thread Rob Godfrey (JIRA)

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

Rob Godfrey updated PROTON-115:
---

Fix Version/s: 0.3

> Expose API to access link name.
> ---
>
> Key: PROTON-115
> URL: https://issues.apache.org/jira/browse/PROTON-115
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Reporter: Hiram Chirino
> Fix For: 0.3
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PROTON-115) Expose API to access link name.

2012-11-05 Thread Rob Godfrey (JIRA)

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

Rob Godfrey commented on PROTON-115:


Added getName() to Link in proton-j

> Expose API to access link name.
> ---
>
> Key: PROTON-115
> URL: https://issues.apache.org/jira/browse/PROTON-115
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Reporter: Hiram Chirino
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (PROTON-115) Expose API to access link name.

2012-11-05 Thread Hiram Chirino (JIRA)
Hiram Chirino created PROTON-115:


 Summary: Expose API to access link name.
 Key: PROTON-115
 URL: https://issues.apache.org/jira/browse/PROTON-115
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


Re: [VOTE] 0.2 RC3

2012-11-05 Thread Hiram Chirino
+1

[X] Ship it! (Release 0.2 RC3 as 0.2)

On Sun, Nov 4, 2012 at 7:09 PM, Rafael Schloming  wrote:

> Hi, I did a bit more testing over the weekend and posted an RC3 here:
>
> http://people.apache.org/~rhs/qpid-proton-0.2rc3
>
> The only changes are fixing a minor bug in the ack stuff and adding the C
> examples. Given that the delta from 0.1 is quite contained, I'm going to
> optimistically call for a release vote based on RC3. Please check it out
> and give your +1 if it looks good. I'd like to do the same 24 hour thingy
> as last time so I can post the release tomorrow if there are no serious
> issues.
>
> [ ] Ship it! (Release 0.2 RC3 as 0.2)
> [ ] No! (We need to fix ...)
>
> --Rafael
>



-- 

**

*Hiram Chirino*

*Engineering | Red Hat, Inc.*

*hchir...@redhat.com  | fusesource.com | redhat.com*

*skype: hiramchirino | twitter: @hiramchirino
*

*blog: Hiram Chirino's Bit Mojo *