IIRC, the definition of the outgoing-window was largely motivated by the
need to express to receivers certain conditions under which they may be
required to settle deliveries in order to receive more. For example if an
implementation uses a fixed sized array to store deliveries, and this array
is k
As promised, here is the first alpha for 0.10. It's posted in the usual
places:
Source code is here:
http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/
Java binaries are here:
https://repository.apache.org/content/repositories/orgapacheqpid-1036
Please check it out and follow up wi
I'd like to see something in the release to do with the session
outgoing-window problems that mean the new JMS client can't currently
send to ServiceBus.
As mentioend elsewhere earlier, a very basic change that leaves the
current default behaviour as it stands but would enable me to
configure the
On 6 July 2015 at 18:57, Rafael Schloming wrote:
> FWIW, my changes in this area really represent the minimum diff necessary
> to get the reactor branch to land. None of this is related to the reactor
> changes per se,
Yes, it almost seems like a change in default behaviour of a sasl
enabled serv
On Mon, 2015-07-06 at 11:28 -0700, Rafael Schloming wrote:
> +1
>
> The only issue that has me worried here is the sasl interop story between
> proton-c and proton-j. I can cut a release later today just to give us
> something to poke at, but there may still be sasl work needed.
I have a blocking
[
https://issues.apache.org/jira/browse/PROTON-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615620#comment-14615620
]
Andrew Stitcher commented on PROTON-201:
[~cliffjansen], I believe this is include
[
https://issues.apache.org/jira/browse/PROTON-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-201:
---
Assignee: Cliff Jansen (was: Andrew Stitcher)
> Provide a C++ Messenger and Message class
> -
Andrew Stitcher created PROTON-934:
--
Summary: Build tests fail if Java is not available
Key: PROTON-934
URL: https://issues.apache.org/jira/browse/PROTON-934
Project: Qpid Proton
Issue Type:
[
https://issues.apache.org/jira/browse/PROTON-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-933.
Resolution: Fixed
Fix Version/s: 0.10
> Cyrus SASL GSSAPI plugin can error if sent lo
[
https://issues.apache.org/jira/browse/PROTON-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615592#comment-14615592
]
ASF subversion and git services commented on PROTON-933:
Commit c6
Andrew Stitcher created PROTON-933:
--
Summary: Cyrus SASL GSSAPI plugin can error if sent long buffers.
Key: PROTON-933
URL: https://issues.apache.org/jira/browse/PROTON-933
Project: Qpid Proton
+1
The only issue that has me worried here is the sasl interop story between
proton-c and proton-j. I can cut a release later today just to give us
something to poke at, but there may still be sasl work needed.
--Rafael
On Mon, Jul 6, 2015 at 9:57 AM, Flavio Percoco wrote:
> On 06/07/15 12:35
On 6 July 2015 at 18:28, Andrew Stitcher wrote:
> On Mon, 2015-07-06 at 13:14 -0400, Andrew Stitcher wrote:
>> On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
>> > ...
>> > The old toggle only used to define whether sasl was required or not
>> > (which it historically was once you enabled
On 6 July 2015 at 18:14, Andrew Stitcher wrote:
> On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
>> ...
>> The old toggle only used to define whether sasl was required or not
>> (which it historically was once you enabled the sasl layer, and the
>> toggle was never implemented in proton-
FWIW, my changes in this area really represent the minimum diff necessary
to get the reactor branch to land. None of this is related to the reactor
changes per se, it just so happens the reactor tests include several tests
that check interop between proton-c and proton-j and these tests keep
stumbl
On 6 July 2015 at 18:24, aconway wrote:
> On Mon, 2015-07-06 at 17:31 +0100, Gordon Sim wrote:
>> On 07/06/2015 05:22 PM, aconway wrote:
>> > On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
>> > > On 07/06/2015 04:08 PM, Rafael Schloming wrote:
>> > > > Any sort of missing class really should
On Mon, 2015-07-06 at 13:14 -0400, Andrew Stitcher wrote:
> On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
> > ...
> > The old toggle only used to define whether sasl was required or not
> > (which it historically was once you enabled the sasl layer, and the
> > toggle was never implement
On Mon, 2015-07-06 at 17:31 +0100, Gordon Sim wrote:
> On 07/06/2015 05:22 PM, aconway wrote:
> > On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
> > > On 07/06/2015 04:08 PM, Rafael Schloming wrote:
> > > > Any sort of missing class really should be a compile time
> > > > exception, which
> >
On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
> ...
> The old toggle only used to define whether sasl was required or not
> (which it historically was once you enabled the sasl layer, and the
> toggle was never implemented in proton-j), whereas IIRC the new
> 'requireAuth' governs that b
On 6 July 2015 at 16:48, Gordon Sim wrote:
> On 07/06/2015 04:08 PM, Rafael Schloming wrote:
>>
>> Any sort of missing class really should be a compile time exception, which
>> I think means you must have stale class files *somewhere*. You could try
>> doing a find checkout -name "*.class" just as
On 06/07/15 12:35 -0400, Ken Giusti wrote:
Hi all,
I remember recently that there was a rumor that we may be able to start the
release of 0.10 at the end of june.
Now that my july 4th long weekend has worn off - what's left to be done before
we can cut an alpha?
Yup, I shot a request and th
On 6 July 2015 at 16:51, Andrew Stitcher wrote:
> On Mon, 2015-07-06 at 11:30 -0400, Rafael Schloming wrote:
>> I wired in allowSkip in a very minimal way just to restore the ability to
>> force the old behaviour. It would be a fairly trivial to change the name of
>> course,
>
> I'm not sure if th
Hi all,
I remember recently that there was a rumor that we may be able to start the
release of 0.10 at the end of june.
Now that my july 4th long weekend has worn off - what's left to be done before
we can cut an alpha?
--
-K
On 07/06/2015 05:22 PM, aconway wrote:
On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really should be a compile time
exception, which
I think means you must have stale class files *somewhere*. You
could try
doing a
On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
> On 07/06/2015 04:08 PM, Rafael Schloming wrote:
> > Any sort of missing class really should be a compile time
> > exception, which
> > I think means you must have stale class files *somewhere*. You
> > could try
> > doing a find checkout -nam
On Mon, 2015-07-06 at 11:30 -0400, Rafael Schloming wrote:
> I wired in allowSkip in a very minimal way just to restore the ability to
> force the old behaviour. It would be a fairly trivial to change the name of
> course,
I'm not sure if that really applies as the method is on a different
object
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really should be a compile time exception, which
I think means you must have stale class files *somewhere*. You could try
doing a find checkout -name "*.class" just as a sanity check.
I have deleted all the .class files t
Github user ted-ross commented on the pull request:
https://github.com/apache/qpid-proton/pull/39#issuecomment-118902728
I'd like to see this pull request move forward. On Dan's points above:
1) I agree with Andrew that using __LINE__ as an error code should be
changed to sim
[
https://issues.apache.org/jira/browse/PROTON-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615189#comment-14615189
]
ASF subversion and git services commented on PROTON-925:
Commit 3c
[
https://issues.apache.org/jira/browse/PROTON-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615190#comment-14615190
]
ASF subversion and git services commented on PROTON-930:
Commit 3c
I wired in allowSkip in a very minimal way just to restore the ability to
force the old behaviour. It would be a fairly trivial to change the name of
course, however it appears there are a bunch of other related changes that
go along with it, e.g. adding a bunch of accessors and fixing the error
be
On Mon, 2015-07-06 at 10:56 -0400, Rafael Schloming wrote:
> On Mon, Jul 6, 2015 at 9:52 AM, Robbie Gemmell
> wrote:
>
> > Is this change allowing clients to skip the SASL layer when connecting
> > to servers that have enabled the SASL layer? If so, how is the new
> > default behaviour disabled?
Any sort of missing class really should be a compile time exception, which
I think means you must have stale class files *somewhere*. You could try
doing a find checkout -name "*.class" just as a sanity check. Also, it's
possible something in your local maven repo is somehow coming into play,
maybe
On 07/06/2015 02:23 PM, Robbie Gemmell wrote:
On 6 July 2015 at 14:17, Gordon Sim wrote:
On 07/06/2015 01:24 PM, Rafael Schloming wrote:
Can you try doing an mvn clean and seeing if it is still an issue?
I see the same thing after mvn clean
Does cleaning the checkout as a whole make any
On Mon, Jul 6, 2015 at 9:52 AM, Robbie Gemmell
wrote:
> Is this change allowing clients to skip the SASL layer when connecting
> to servers that have enabled the SASL layer? If so, how is the new
> default behaviour disabled?
>
Yes, it was necessary to allow the tests to pass.
> The existing b
Is this change allowing clients to skip the SASL layer when connecting
to servers that have enabled the SASL layer? If so, how is the new
default behaviour disabled?
The existing but unimplemented 'allowSkip' method previously intended
to enable such behaviour still doesn't do anything, so is ther
On 6 July 2015 at 14:17, Gordon Sim wrote:
> On 07/06/2015 01:24 PM, Rafael Schloming wrote:
>>
>> Can you try doing an mvn clean and seeing if it is still an issue?
>
>
> I see the same thing after mvn clean
>
Does cleaning the checkout as a whole make any difference?
To preview what woudl be d
That seemed to do the trick. Running the maven build in a clean
checkout in clean terminal now works, so long as you use a version of
Java able to build the recent source; the compilation issue is still
there otherwise:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/
https://builds.
On 07/06/2015 01:24 PM, Rafael Schloming wrote:
Can you try doing an mvn clean and seeing if it is still an issue?
I see the same thing after mvn clean
Can you do a git pull and give it another shot?
I believe what is happening is that when maven launches the jython tests,
it doesn't seem to include the jython shim in the class path. For some
reason, this isn't an issue of the .class files that jython generates are
hanging around in the source tr
Were you running it after having previously used the cmake build in
the same terminal?
I do indeed have the definition in ctypes, with the cproton file
importing everything from ctypes. The maven build failed when I ran it
directly in my git-clean'ed checkout. It then passed when run
indirectly vi
Can you try doing an mvn clean and seeing if it is still an issue?
A class entirely missing like that is usually due to mvn not recompiling
everything that is impacted by a given change.
--Rafael
On Mon, Jul 6, 2015 at 8:11 AM, Gordon Sim wrote:
> All the ProtonJInterop tests fail for me, and
All the ProtonJInterop tests fail for me, and the python-test then
hangs. The error for each is something like:
2: proton_tests.reactor_interop.ReactorInteropTest. \
2: Error: Could not find or load main class
org.apache.qpid.proton.ProtonJInterop
2: test_protonc_to_protonj_1 .
On 07/06/2015 11:04 AM, Gordon Sim wrote:
On 07/06/2015 10:52 AM, Robbie Gemmell wrote:
This seems to be resulting in segfaults running the tests on Windows:
https://ci.appveyor.com/project/ke4qqq/qpid-proton/build/0.10-SNAPSHOT-master.122
1: proton_tests.message.CodecTest.testRoundTrip
..
[
https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-927:
--
Fix Version/s: (was: 0.10)
> absolute-expiry-time and creation-time are encoded as 0 if not set
> --
[
https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-927:
---
Assignee: (was: Gordon Sim)
The new test was reported to have segfaulted on windows:
https://ci
[
https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14614915#comment-14614915
]
ASF subversion and git services commented on PROTON-927:
Commit 23
I just ran a maven-only clean build locally with no problems.
You should have PN_MILLIS_MAX defined in
proton-j/src/main/resources/ctypes.py, and this should be imported from
proton-j/src/main/resources/cproton.py. Can you verify that this is as
expected?
--Rafael
On Mon, Jul 6, 2015 at 5:50 AM,
On 07/06/2015 10:52 AM, Robbie Gemmell wrote:
This seems to be resulting in segfaults running the tests on Windows:
https://ci.appveyor.com/project/ke4qqq/qpid-proton/build/0.10-SNAPSHOT-master.122
1: proton_tests.message.CodecTest.testRoundTrip
pass
1: proton_tests.
This seems to be resulting in segfaults running the tests on Windows:
https://ci.appveyor.com/project/ke4qqq/qpid-proton/build/0.10-SNAPSHOT-master.122
1: proton_tests.message.CodecTest.testRoundTrip
pass
1: proton_tests.message.CodecTest.testRoundTripWithTimes ...
The recent changes on Proton-J seemed to have created some issues:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/1032/console
The module currently requries Java 7 to compile, which is a slightly
out of sync with the compiler source+target still being set to Java 6
(which the above
51 matches
Mail list logo