Hello all,
I tried to stop the Proton MessagingHandler by calling
self.container.stop() but this causes an endless loop (cpu goes to 100%).
So I just could help myself to throw an exception. But I think this is not
a good solution.
Can someone tell me, how I can leave container.run() gracefully?
On 22/02/18 07:53, andi welchlin wrote:
Hello Gordon,
thank you for the hint. This was exactly what I needed.
Now I call close and in the method on_connection_closed() I stop the
container.
The connection is then closed remotely.
Would be nice to reflect this in the Proton examples.
When the
On 22/02/18 08:05, andi welchlin wrote:
Hello all,
I tried to stop the Proton MessagingHandler by calling
self.container.stop() but this causes an endless loop (cpu goes to 100%).
So I just could help myself to throw an exception. But I think this is not
a good solution.
Can someone tell me, h
Yes, sure:
#!/usr/bin/env python3
from proton.reactor import Container
from proton.handlers import MessagingHandler
from proton import Message, Connection
import threading
import sys
class AmqpReceiver(MessagingHandler):
def __init__(self):
super().__init__(prefetch=50)
self
The container is single-threaded, so invoking methods on it from another
thread is not safe (it would be nice if close() were an exception here,
but I guess it is not).
What you can do is inject an application defined event into the loop to
do the shutdown. E.g. as in attached modification to
Hello Gordon,
I tried somthing similar, but it hangs, anyway.
When I run your program with the changes it hangs. The output ist:
andreas:/home/andreas/src/python/test_dmitry_restart_receiver
>./test_shutdown.py
run container
press enteron start
call stop
call join
on_stop
on_stop
on_stop
on_sto
On 22/02/18 10:33, andi welchlin wrote:
Hello Gordon,
I tried somthing similar, but it hangs, anyway.
When I run your program with the changes it hangs.
What platform are you on? (It works for me with python 3.5.4 on fedora
25 with latest python-qpid-proton).
--
+1
I checked things over as follows:
- Verified the signature and checksum files.
- Checked LICENCE+NOTICE files present.
- Ran mvn apache-rat:check to check the licence headers.
- Built the router on Fedora 26 against an install of Proton 0.20.0
and ran the tests.
- Ran the JMS client exampl
Proton 0.19.0
Ubuntu 16.04 LTS with all patches installed
Python 3.5.2
I will try with Proton 0.20
On Thu, Feb 22, 2018 at 12:06 PM, Gordon Sim wrote:
> On 22/02/18 10:33, andi welchlin wrote:
>
>> Hello Gordon,
>>
>> I tried somthing similar, but it hangs, anyway.
>>
>> When I run your progra
https://issues.apache.org/jira/browse/DISPATCH-893 should probably
have been included too. I overlooked it on an earlier skim as it was
resolved without a fix version assigned.
More of a reason for a 1.0.2 or ensuring 1.1.0 isnt too distant,
rather than cause for a respin.
Robbie
On 22 February
I tested with Proton 0.20.0 and it is still the same.
On Thu, Feb 22, 2018 at 12:43 PM, andi welchlin
wrote:
> Proton 0.19.0
> Ubuntu 16.04 LTS with all patches installed
> Python 3.5.2
>
> I will try with Proton 0.20
>
>
> On Thu, Feb 22, 2018 at 12:06 PM, Gordon Sim wrote:
>
>> On 22/02/18 10
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
?
Regards,
Andreas
On Thu, Feb 22, 2018 at 1:14 PM, andi welchlin
wrote:
> I tested with Proton 0.20.0 and it is still the same.
>
> On Thu,
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
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
Thank you for the hints.
I can confirm that the throughput is far better with QPID Proton 0.20 (and
the C++ Broker 0.37).
The new results are:
15 seconds for a 300 MB message
23 seconds for a 500 MB message
47 seconds for a 800 MB message
(all numbers are averages)
Kind Regards,
Andreas
On We
Hi all,
Can you provide me an example...
On my side I got:
2018-02-22 18:24:01,288 WARN - Open of resource:(JmsConsumerInfo: {
ID:14d11742-f82d-4ca6-8568-d0b173feb6ca:1:1:1, destination = topic }) failed:
Could not find destination for source
'Source{address=topic,durable=none,expiryPolicy=l
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.
+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 A
18 matches
Mail list logo