Re: [VOTE] Release Apache Qpid Proton-J 0.26.0

2018-02-23 Thread Robbie Gemmell 
On 22 February 2018 at 18:39, Robbie Gemmell  wrote:
> Hi folks,
>
> I have put together a spin for a Qpid Proton-J 0.26.0 release, please
> test it and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.26.0-rc1/
>
> The maven artifacts are staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1130
>
> The JIRAs assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12342429
>
> Regards,
> Robbie
>
> P.S. If you want to test things out using maven with your own build
> you can temporarily add this to your poms to access the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1130
> 
>   
>
> The dependency for proton-j would then be:
>
>   
> org.apache.qpid
> proton-j
> 0.26.0
>   

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked the LICENCE and NOTICE files in the archives.
- Used mvn apache-rat:check to verify licence headers in the source archive.
- Ran the source build and tests.
- Used the staging repo to run the Qpid JMS client master build and tests.
- Used the staging repo to run the ActiveMQ Artemis master build and
AMQP tests (also using the earlier client build).

Robbie

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

Re: [VOTE] Release Apache Qpid Proton-J 0.26.0

2018-02-23 Thread Gordon Sim 

On 22/02/18 18:39, Robbie Gemmell wrote:

Hi folks,

I have put together a spin for a Qpid Proton-J 0.26.0 release, please
test it and vote accordingly.

The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.26.0-rc1/

The maven artifacts are staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1130

The JIRAs assigned are:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12342429




+1, built from source and ran tests

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

Re: [VOTE] Release Apache Qpid Proton-J 0.26.0

2018-02-23 Thread Keith W 
+1

* Ran Apache RAT against the source bundle
* Built and ran tests from source (Java 1.8.0_162-b12, Mac OS X 10.11.6)
* Ran Broker-J's JMS client integrations test suites:
qpid-systests-jms_1.1,qpid-systests-jms_2.0,end-to-end-conversion-tests
using staged maven artefacts

On 22 February 2018 at 21:02, Timothy Bish  wrote:
> +1
>
> * Validated signatures and checksums
> * Checked for license and notice files in binary and source archives
> * Ran mvn apache-rat:check to validate source files have licenses
> * Built from source and ran the tests
> * Build ActiveMQ, ActiveMQ Artemis and Qpid JMS using the staged bits and
> ran the AMQP tests
>
>
> On 02/22/2018 01:39 PM, Robbie Gemmell wrote:
>>
>> Hi folks,
>>
>> I have put together a spin for a Qpid Proton-J 0.26.0 release, please
>> test it and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.26.0-rc1/
>>
>> The maven artifacts are staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1130
>>
>> The JIRAs assigned are:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12342429
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test things out using maven with your own build
>> you can temporarily add this to your poms to access the staging repo:
>>
>>
>>  
>>staging
>>
>> https://repository.apache.org/content/repositories/orgapacheqpid-1130
>>  
>>
>>
>> The dependency for proton-j would then be:
>>
>>
>>  org.apache.qpid
>>  proton-j
>>  0.26.0
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

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

Re: QPID Proton 0.19 Python: Exit MessagingHandler.run()

2018-02-23 Thread Alan Conway 
I seem to remember at some point there was a bug in the reactor which
caused events to get stuck and repeated in on_stop. In that case it was
related to scheduled events but this sounds similar.
Very odd that it works differently on different platforms. Perhaps
differences in the behavior of select or error handling when closing file
descriptors? Internally stop() works by writing to a FD to wake up the
select loop and the process of shutting down would close that FD, so
perhaps there's a bug/race condition that is being handled differently on
each platform and causing one to get stuck in a loop.

Deserves a JIRA I think, sounds  like there's a problem somewhere in proton.

On Fri, Feb 23, 2018 at 3:52 AM, andi welchlin 
wrote:

> When I jump with gdb into clean_stop.py while it hangs:
>
> (gdb) where
> #0  0x7f586bada827 in futex_abstimed_wait_cancelable (private=0,
> abstime=0x0, expected=0, futex_word=0x7f5864000c10) at
> ../sysdeps/unix/sysv/linux/futex-internal.h:205
> #1  do_futex_wait (sem=sem@entry=0x7f5864000c10, abstime=0x0) at
> sem_waitcommon.c:111
> #2  0x7f586bada8d4 in __new_sem_wait_slow (sem=0x7f5864000c10,
> abstime=0x0) at sem_waitcommon.c:181
> #3  0x7f586bada97a in __new_sem_wait (sem=) at
> sem_wait.c:29
> #4  0x00514195 in PyThread_acquire_lock_timed ()
> #5  0x00517f66 in ?? ()
> #6  0x004e9ba7 in PyCFunction_Call ()
> #7  0x005372f4 in PyEval_EvalFrameEx ()
> #8  0x00540199 in ?? ()
>
>
> And I can confirm that with Debian it does not hang.
>
> Does anyone have an idea what the reason could be?
>
> On Thu, Feb 22, 2018 at 4:49 PM, andi welchlin 
> wrote:
>
> > My output with tracing:
> >
> > run container
> > on start
> > press enter[0x7f2f6c008f90]:  -> SASL
> > [0x7f2f6c008f90]:  <- SASL
> > [0x7f2f6c008f90]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_
> SYMBOL[:ANONYMOUS,
> > :AMQPLAIN, :PLAIN]]
> > [0x7f2f6c008f90]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> > initial-response=b"anonymous"]
> > [0x7f2f6c008f90]:0 <- @sasl-outcome(68) [code=0]
> > [0x7f2f6c008f90]:  -> AMQP
> > [0x7f2f6c008f90]:0 -> @open(16) [container-id="7c856344-8010-
> 44dc-ac56-bbdcddb52acd",
> > hostname="localhost:amqp", channel-max=32767]
> > [0x7f2f6c008f90]:0 -> @begin(17) [next-outgoing-id=0,
> > incoming-window=2147483647, outgoing-window=2147483647]
> > [0x7f2f6c008f90]:0 -> @attach(18) [name="7c856344-8010-44dc-
> > ac56-bbdcddb52acd-test.awe.queue", handle=0, role=true,
> > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> > [address="test.awe.queue", durable=0, timeout=0, dynamic=false],
> > target=@target(41) [durable=0, timeout=0, dynamic=false],
> > initial-delivery-count=0]
> > [0x7f2f6c008f90]:0 -> @flow(19) [incoming-window=2147483647
> > <(214)%20748-3647>, next-outgoing-id=0, outgoing-window=2147483647,
> > handle=0, delivery-count=0, link-credit=50, drain=false]
> > [0x7f2f6c008f90]:  <- AMQP
> > [0x7f2f6c008f90]:0 <- @open(16) [container-id="rabbit@andreas-
> VirtualBox",
> > channel-max=32767, idle-time-out=6, properties={:"cluster_name"="
> > rabbit@andreas-VirtualBox", :copyright="Copyright (C) 2007-2015 Pivotal
> > Software, Inc.", :information="Licensed under the MPL.  See
> > http://www.rabbitmq.com/;, :platform="Erlang/OTP", :product="RabbitMQ",
> > :version="3.5.7"}]
> > [0x7f2f6c008f90]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
> > incoming-window=65535, outgoing-window=65535, handle-max=4294967295]
> > [0x7f2f6c008f90]:0 <- @attach(18) [name="7c856344-8010-44dc-
> > ac56-bbdcddb52acd-test.awe.queue", handle=0, role=false,
> > snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> > [address="test.awe.queue", durable=0, timeout=0, dynamic=false,
> > default-outcome=@released(38) [], outcomes=@PN_SYMBOL[:"amqp:
> accepted:list",
> > :"amqp:rejected:list", :"amqp:released:list"]], initial-delivery-count=0]
> > *[0x7f2f6c008f90]:0 <- @flow(19) [next-incoming-id=0,
> > incoming-window=65535, next-outgoing-id=0, outgoing-window=65535,
> handle=0,
> > delivery-count=0, link-credit=50, available=0, drain=false]*
> >
> > call stop
> > call join
> > on_stop
> > on_stop
> > on_stop
> > on_stop
> >  [ a log of stop lines deleted ] ...
> > on_stop
> > on_stop
> > on_stop
> > on_stop
> > Exception ignored in: 
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/proton/wrapper.py", line 95, in
> > __del__
> > pn_decref(self._impl)
> >   File "/usr/lib/python3/dist-packages/proton/wrapper.py", line 63, in
> > __getattr__
> > attrs = self.__dict__["_attrs"]
> > KeyError: ('_attrs',)
> > ^CTraceback (most recent call last):
> >   File "./clean_stop.py", line 67, in 
> > handler._stop()
> >   File "./clean_stop.py", line 44, in _stop
> > self.thread.join()
> >   File "/usr/lib/python3.5/threading.py", line 1054, in join
> > self._wait_for_tstate_lock()
> >   File "/usr/lib/python3.5/threading.py",

Re: QPid Proton CPP

2018-02-23 Thread Alan Conway 
On Fri, Feb 23, 2018 at 5:43 AM, Baptiste Robert  wrote:

> Hi everybody,
>
> I'm struggling a little bit with the global architecture of proton cpp. I'm
> trying to code a wrapper to simplify the utilization for a end user.
> This wrapper is divided in two classes, a "client" that launch the
> proton::container in a separate thread, and a handler that inherate
> proton::messaging_handler. My "client" part is supposed to allow the user
> to create a new connection, send message, close the connection, etc..
> But I encounter strange behavior from proton, like why when I called a
> close on a connection, then my container exit from his thread (return from
> the run) ?
>

Do  you have some sample code? Possibly there is some confusion about the
threading rules. For example to close a connection from a thread other than
the event handling thread, you need to use a work-queue.
Have you looked at the cpp/multithreaded_* examples?



Same issue with the proton::reconnection_options, it does not works
> properly, if I simulate a broker crash and then relaunch it, my connection
> wait while the container is offline but after the restart I get a transport
> error.
>
It should work - if you can show some sample code we can figure out why
not.

>
> So I supposed my problem here is that I not fully understand the philosophy
> of proton. In my mind it was : one container that handle multiple
> connections, and the container can close/open connections from different
> thread.
>
That's correct, although there are some rules about what you can do from
what thread. Take a look at
proton-c/bindings/cpp/docs/mt.md


>
> Oh and lastly, I do not understand why the proton::error_condition does not
> have an error code (proper enum, not string).
>

It represents an AMQP error condition which has a name, description and
some optional "info" - not an operating system error. In cases where we
generate error conditions internally because of OS errors we usually
include the OS error description in the description but there's no access
to an OS-specific error code.

The condition name acts a bit like an error "type", but it is not a closed
set. For IO related errors we use "proton:io", there are some AMQP standard
names which can be used for errors on the wire, but an application is free
to invent others:

InternalError = "amqp:internal-error"
NotFound  = "amqp:not-found"
UnauthorizedAccess= "amqp:unauthorized-access"
DecodeError   = "amqp:decode-error"
ResourceLimitExceeded = "amqp:resource-limit-exceeded"
NotAllowed= "amqp:not-allowed"
InvalidField  = "amqp:invalid-field"
NotImplemented= "amqp:not-implemented"
ResourceLocked= "amqp:resource-locked"
PreconditionFailed= "amqp:precondition-failed"
ResourceDeleted   = "amqp:resource-deleted"
IllegalState  = "amqp:illegal-state"
FrameSizeTooSmall = "amqp:frame-size-too-small"

QPid Proton CPP

2018-02-23 Thread Baptiste Robert 
Hi everybody,

I'm struggling a little bit with the global architecture of proton cpp. I'm
trying to code a wrapper to simplify the utilization for a end user.
This wrapper is divided in two classes, a "client" that launch the
proton::container in a separate thread, and a handler that inherate
proton::messaging_handler. My "client" part is supposed to allow the user
to create a new connection, send message, close the connection, etc..
But I encounter strange behavior from proton, like why when I called a
close on a connection, then my container exit from his thread (return from
the run) ?
Same issue with the proton::reconnection_options, it does not works
properly, if I simulate a broker crash and then relaunch it, my connection
wait while the container is offline but after the restart I get a transport
error.

So I supposed my problem here is that I not fully understand the philosophy
of proton. In my mind it was : one container that handle multiple
connections, and the container can close/open connections from different
thread.

Oh and lastly, I do not understand why the proton::error_condition does not
have an error code (proper enum, not string).

Thanks you,

-- 
Baptiste Robert

Re: QPID Proton 0.19 Python: Exit MessagingHandler.run()

2018-02-23 Thread andi welchlin 
When I jump with gdb into clean_stop.py while it hangs:

(gdb) where
#0  0x7f586bada827 in futex_abstimed_wait_cancelable (private=0,
abstime=0x0, expected=0, futex_word=0x7f5864000c10) at
../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x7f5864000c10, abstime=0x0) at
sem_waitcommon.c:111
#2  0x7f586bada8d4 in __new_sem_wait_slow (sem=0x7f5864000c10,
abstime=0x0) at sem_waitcommon.c:181
#3  0x7f586bada97a in __new_sem_wait (sem=) at
sem_wait.c:29
#4  0x00514195 in PyThread_acquire_lock_timed ()
#5  0x00517f66 in ?? ()
#6  0x004e9ba7 in PyCFunction_Call ()
#7  0x005372f4 in PyEval_EvalFrameEx ()
#8  0x00540199 in ?? ()


And I can confirm that with Debian it does not hang.

Does anyone have an idea what the reason could be?

On Thu, Feb 22, 2018 at 4:49 PM, andi welchlin 
wrote:

> My output with tracing:
>
> run container
> on start
> press enter[0x7f2f6c008f90]:  -> SASL
> [0x7f2f6c008f90]:  <- SASL
> [0x7f2f6c008f90]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS,
> :AMQPLAIN, :PLAIN]]
> [0x7f2f6c008f90]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous"]
> [0x7f2f6c008f90]:0 <- @sasl-outcome(68) [code=0]
> [0x7f2f6c008f90]:  -> AMQP
> [0x7f2f6c008f90]:0 -> @open(16) 
> [container-id="7c856344-8010-44dc-ac56-bbdcddb52acd",
> hostname="localhost:amqp", channel-max=32767]
> [0x7f2f6c008f90]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7f2f6c008f90]:0 -> @attach(18) [name="7c856344-8010-44dc-
> ac56-bbdcddb52acd-test.awe.queue", handle=0, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="test.awe.queue", durable=0, timeout=0, dynamic=false],
> target=@target(41) [durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> [0x7f2f6c008f90]:0 -> @flow(19) [incoming-window=2147483647
> <(214)%20748-3647>, next-outgoing-id=0, outgoing-window=2147483647,
> handle=0, delivery-count=0, link-credit=50, drain=false]
> [0x7f2f6c008f90]:  <- AMQP
> [0x7f2f6c008f90]:0 <- @open(16) [container-id="rabbit@andreas-VirtualBox",
> channel-max=32767, idle-time-out=6, properties={:"cluster_name"="
> rabbit@andreas-VirtualBox", :copyright="Copyright (C) 2007-2015 Pivotal
> Software, Inc.", :information="Licensed under the MPL.  See
> http://www.rabbitmq.com/;, :platform="Erlang/OTP", :product="RabbitMQ",
> :version="3.5.7"}]
> [0x7f2f6c008f90]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
> incoming-window=65535, outgoing-window=65535, handle-max=4294967295]
> [0x7f2f6c008f90]:0 <- @attach(18) [name="7c856344-8010-44dc-
> ac56-bbdcddb52acd-test.awe.queue", handle=0, role=false,
> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
> [address="test.awe.queue", durable=0, timeout=0, dynamic=false,
> default-outcome=@released(38) [], outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> :"amqp:rejected:list", :"amqp:released:list"]], initial-delivery-count=0]
> *[0x7f2f6c008f90]:0 <- @flow(19) [next-incoming-id=0,
> incoming-window=65535, next-outgoing-id=0, outgoing-window=65535, handle=0,
> delivery-count=0, link-credit=50, available=0, drain=false]*
>
> call stop
> call join
> on_stop
> on_stop
> on_stop
> on_stop
>  [ a log of stop lines deleted ] ...
> on_stop
> on_stop
> on_stop
> on_stop
> Exception ignored in: 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/proton/wrapper.py", line 95, in
> __del__
> pn_decref(self._impl)
>   File "/usr/lib/python3/dist-packages/proton/wrapper.py", line 63, in
> __getattr__
> attrs = self.__dict__["_attrs"]
> KeyError: ('_attrs',)
> ^CTraceback (most recent call last):
>   File "./clean_stop.py", line 67, in 
> handler._stop()
>   File "./clean_stop.py", line 44, in _stop
> self.thread.join()
>   File "/usr/lib/python3.5/threading.py", line 1054, in join
> self._wait_for_tstate_lock()
>   File "/usr/lib/python3.5/threading.py", line 1070, in
> _wait_for_tstate_lock
> elif lock.acquire(block, timeout):
> KeyboardInterrupt
>
>
> On Thu, Feb 22, 2018 at 4:26 PM, Gordon Sim  wrote:
>
>> On 22/02/18 15:22, andi welchlin wrote:
>>
>>> Hi Gordon,
>>>
>>> I saw that your first line is:
>>>
>>> #!/usr/bin/env python
>>>
>>>
>>> Does clean_stop.py also work for you when you change it to:
>>>
>>> #!/usr/bin/env python3
>>>
>>> ?
>>>
>>>
>> Yes (output with tracing on below):
>>
>> $ PN_TRACE_FRM=1 ./clean_stop.py run container
>>> press enteron start
>>> [0x7f39ac009120]:  -> SASL
>>> [0x7f39ac009120]:  <- SASL
>>> [0x7f39ac009120]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SY
>>> MBOL[:ANONYMOUS]]
>>> [0x7f39ac009120]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
>>> initial-response=b"anonymous@localhost.localdomain"]
>>> [0x7f39ac009120]:0 <- @sasl-outcome(68) [code=0]
>>> [0x7f39ac009120]:  -> AMQP
>>> [0x7f39ac009120]:0 -> @open(16) 
>>>