Re: ***UNCHECKED*** Re: trouble connecting to Azure Service Bus from OS X

[Roddie Kieley]

Did you have any further luck after? I had suspected that if you were to
utilize ANONYMOUS sasl instead of PLAIN that that might avoid the issue
mentioned above, but wanted to take a look at the specific container image
you were using to confirm what was inside that would cause it to work ok
vs. the macports install to not.

On Fri, Jan 26, 2018 at 2:20 PM, George David  wrote:

> I'm not exactly sure what you're asking. I used the official python 2.7.14
> docker image and installed python-qpid-proton using pip. You can see what's
> available here: https://hub.docker.com/_/python/
> `
>
> On Thu, Jan 25, 2018 at 7:01 PM Roddie Kieley  wrote:
>
> > Hi, while I have not run into your specific problem I had previously run
> > into some issues when utilizing the cyrus sasl implementation on OSX
> which
> > I documented via PROTON-1695 - '[OSX] Cyrus SASL plugins do not load
> > leading to missing mechanisms' [1]. It appears that you are utilizing the
> > sasl plain mechanism which I did have issues with.
> >
> > Looking at the python docs for running on OSX I'm not seeing the link for
> > the dockerfile, can you point me in the right direction?
> >
> >
> > Roddie
> > ---
> > [1] - https://issues.apache.org/jira/browse/PROTON-1695
> > [2] - https://docs.python.org/2/using/mac.html
> >
> > On Thu, Jan 25, 2018 at 1:52 PM, George David 
> wrote:
> >
> > > macOs High Sierra 10.13.12
> > > python: 2.7.14 (macports)
> > > qpid-proton: 0.19.0 (macports)
> > > python-qpid-proton: 0.19.0 (pipenv)
> > >
> > > I created two python scripts, 1 to write to a service bus topic and 1
> to
> > > read. When I try to either read or write, Here is a snippet of code I
> use
> > > to send a message:
> > >
> > > conn = BlockingConnection(broker, allowed_mechs="PLAIN")
> > > receiver = conn.create_receiver(entity_name)
> > > msg = receiver.receive()
> > > receiver.accept()
> > > conn.close()
> > >
> > > I get the following error:
> > >
> > > Traceback (most recent call last):
> > >   File "send.py", line 30, in 
> > > conn = BlockingConnection(broker, allowed_mechs="PLAIN")
> > >   File
> > > "[redacted]/.local/share/virtualenvs/amqp-service-bus-
> > > lvrxBNPB/lib/python2.7/site-packages/proton/utils.py",
> > > line 226, in __init__
> > > msg="Opening connection")
> > >   File
> > > "[redacted]d/.local/share/virtualenvs/amqp-service-bus-
> > > lvrxBNPB/lib/python2.7/site-packages/proton/utils.py",
> > > line 300, in wait
> > > "Connection %s disconnected: %s" % (self.url, self.disconnected))
> > > proton.ConnectionException: Connection amqps://send:[redacted]@[
> namespace
> > > redacted].servicebus.windows.net:amqps/ disconnected:
> > > Condition('proton:io', 'getaddrinfo([namespace-redacted].
> > > servicebus.windows.net, amqps): nodename nor servname provided, or not
> > > known')
> > >
> > >
> > > I have tested this code successfully on my ubuntu machine and using the
> > > official python:2.7.14 docker image running on my mac.
> > >
> > >
> > > My initial attempts to use qpid proton was to install
> python-qpid-proton.
> > > That failed because clang couldn't find "sys/timerfd.h". Then I found
> > that
> > > macports offered a qpid-proton. I installed that then installed the
> > python
> > > package with no issues.
> > >
> > > Has anyone else has run into this?
> > > Any tips to help me debug this issue?
> > >
> > > Thanks!
> > >
> >
>

[Proton-J] Create exchange / queues and bind them using proton-j library

[dexter]

Hi,

I'm trying to create dynamically an exchange type topic and some queues and 
bind them with the topic using a bindingKey using the latest Java library
proton-j-0.25.0.jar on a Apache Qpid Broker-J 7.0.0 server.

If the exchange / queues are in place (created using RabbitMQ library
amqp-client-5.1.2.jar) my app works. But I want to create the exchange and
the queues using only proton-j library, because is supports AMQP 1.0
Protocol.

I searched over this forum and over the GitHub examples but I could not find
a solution.

As I understand Receiver and Sender have some properties to set address,
durability, expiryPolicy and more. The address is in the format of
"exchangeName/bindingKey". 

Does the proton-j library support ExchangeDeclare, QueueDeclare and
QueueBind ? If yes, is there and example ? If no, what library should I use
to manage exchanges / queues on a Broker with AMQP 1.0 Protocol support ?

Thank you,
Marius



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

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

Re: JMS Client failover error stops message consumption

[bryand]

I have example code for the issue I am running into with session.commit()
during message consumption.  Here is my test code 
TestTxnConsumeExample.java
  
and the debug output  qpid-session-cmt-consume-error.log

 
.  What happens is message consumption starts, I cause failover to happen on
the server and a JMSException occurs during the session.commit() call when
failover is in progress:

2018-01-30 13:43:51,249 [10.0.51.42:5672] - INFO  FailoverRoundRobinServers 
- Delay between connect retries:1000
Failed: javax.jms.JMSException: Session exception occurred while trying to
commit: Session sync was interrupted by failover.
javax.jms.JMSException: Session exception occurred while trying to commit:
Session sync was interrupted by failover.
at 
org.apache.qpid.client.AMQSession.toJMSException(AMQSession.java:3757)
at org.apache.qpid.client.AMQSession.commit(AMQSession.java:927) 

After failover completes on the client side it no longer can receive any
messages.



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

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

Re: JMS Client failover error stops message consumption

[bryand]

Keith, I think part of the issue I was having is that I wasn't defining
enough retry attempts in my connection url.  I've noticed the server side
failover usually takes up to 45 seconds and what I had set as options in the
connection url didn't cover that.

However, I am still having issues when utilizing session transactions.  I
stated earlier in this thread that session transactions were working
correctly for me.  That really wasn't accurate.  The issue I keep running
into is when I try a session commit (either after receiving or sending a
message) and a failover is in progress the session.commit() raises a
JMSException and I don't believe it should.  And what is really strange
about the session.commit() calls is that an exception is only raised when
the code does a try/catch around that session.commit() call.  If I don't do
a try/catch around that method call failover is successful and life is
great.  I know this makes no sense but I've been able to reproduce it
several times and have log files and my source code attached so you can
hopefully reproduce it.

My test code is here:
TestTxnExample.java
  .  It
has the try/catch around the session.commit() call and results in this
attached failure situation where the commit call throws an exception during
failover and the code stops processing.  qpid-session-cmt-error.log
 
.  I've actually added a sleep of 1 minute to the code when the JMSException
is thrown to try and give the qpid client code time to finish failover
processing and then I continue in the loop to send the next message.  When I
do that the previous message that the commit was called for was not
recovered by the qpid client and it is not persisted.  Also, I get a
different JMSExcepion that states a rollback needs to be done (or was done -
can't remember).

This log file is from a test I did of the same example code but I didn't
wrap the session.commit() call in a try/catch
qpid-session-cmt-success.log
 
.  You can see where failover was successful on the client and I validated
all messages were sent and persisted correctly in the broker.

I noticed that if I leave the try/catch around the session.commit() call but
add a sleep of 200 milliseconds after committing each message in the loop
failover is always successful and a JMSException is never raised when doing
a session.commit() call.  It almost seems like a threading/race condition
issue but that's just a complete guess.

Bryan





--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

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

Re: qpid journal files

[rammohan ganapavarapu]

Any help understanding this?

On Jan 29, 2018 9:34 AM, "rammohan ganapavarapu" 
wrote:

> Hi,
>
> I am using qpid-cpp-server-1.35 version and i see lot journal files in
> "/data/qls/p001/efp/2048k" dir and some files under
> "/data/qls/p001/efp/2048k/in_use" also i see symlinks under
> "/data/qls/jrnl2/*/*", can some one explain what are these different
> locations and what are the current serving file(s)? how to set limit on the
> number of those files and how to purge unused files with out stoping
> processes.
>
> Thanks,
> Ram
>

Re: [ANNOUNCE] Apache Qpid Proton 0.20.0 released

[Ken Giusti]

I've posted the corresponding python source package to Pypi:

https://pypi.python.org/pypi/python-qpid-proton/0.20.0

Holler if you find any issues, thanks

On Tue, Jan 30, 2018 at 7:04 AM, Robbie Gemmell  wrote:

> The Apache Qpid (http://qpid.apache.org) community is pleased to announce
> the immediate availability of Apache Qpid Proton 0.20.0.
>
> Apache Qpid Proton is a messaging library for the Advanced Message Queuing
> Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be
> used
> in a wide range of messaging applications including brokers, clients,
> routers, bridges, proxies, and more.
>
> The release is available now from our website:
> http://qpid.apache.org/download.html
>
> Release notes can be found at:
> http://qpid.apache.org/releases/qpid-proton-0.20.0/release-notes.html
>
> Thanks to all involved,
> Robbie
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>


-- 
-K

Re: Link handling after detach(close=false)

[Gordon Sim]

On 30/01/18 12:03, Hudalla Kai (INST/ECS4) wrote:

Is it also ok for the receiver to send an attach with close=true in response to 
the reouter's detach (close=false), effectively closing the link for good?


No, that would not work. The close actually needs to get to the broker, 
which is where the subscription is held. However the detach from the 
router is an indication that 'connection' to the broker has been lost. 
It is in some ways similar to losing the tcp connection when directly 
subscribed to a broker.


In order to close the link for good, you would need to re-establish the 
link (through the router, to the broker) and then close it.


*However*, if you don't want the subscription to survive such 
disconnection, you can simply avoid making it durable and expiring on 
link detach. Then the distinction between detach with closed=true and 
closed=false is irrelevant.


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

[ANNOUNCE] Apache Qpid Proton 0.20.0 released

[Robbie Gemmell]

The Apache Qpid (http://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid Proton 0.20.0.

Apache Qpid Proton is a messaging library for the Advanced Message Queuing
Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used
in a wide range of messaging applications including brokers, clients,
routers, bridges, proxies, and more.

The release is available now from our website:
http://qpid.apache.org/download.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-proton-0.20.0/release-notes.html

Thanks to all involved,
Robbie

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

Re: Link handling after detach(close=false)

[Hudalla Kai (INST/ECS4)]

On 30.01.2018 11:28, Gordon Sim wrote:
On 30/01/18 06:15, Kai wrote:
Gordon,

by "it" you are referring to the consumer/receiver, correct?

Yes, the application receiving messages.

Is it also ok for the receiver to send an attach with close=true in response to 
the reouter's detach (close=false), effectively closing the link for good?
-
To unsubscribe, e-mail: 
users-unsubscr...@qpid.apache.org
For additional commands, e-mail: 
users-h...@qpid.apache.org


--

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Ullsteinstraße 128
12109 Berlin
GERMANY
www.bosch-si.com

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 
148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: 
Dr. Stefan Ferber, Michael Hahn

[ANNOUNCE] Apache Qpid JMS 0.29.0 released

[Robbie Gemmell]

The Apache Qpid (http://qpid.apache.org) community is pleased to
announce the immediate availability of Apache Qpid JMS 0.29.0.

This is the latest release of our newer JMS client supporting the
Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464,
http://www.amqp.org), based around the Apache Qpid Proton protocol
engine and implementing the AMQP JMS Mapping as it evolves at OASIS.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-jms-0.29.0/release-notes.html

Thanks to all involved,
Robbie

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

Re: Link handling after detach(close=false)

[Gordon Sim]

On 30/01/18 06:15, Kai wrote:

Gordon,

by "it" you are referring to the consumer/receiver, correct?


Yes, the application receiving messages.

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

Re: JMS Client failover error stops message consumption

[Keith W]

Bryan

Thanks for the attachment.  I hope to have time to look in detail
later this week.  Hopefully there will be a workaround.   I mostly see
the failover feature used with transactional JMS applications so this
may explain why the problem you report is unfamiliar to me.

Keith.



On 25 January 2018 at 19:29, bryand  wrote:
> I have been doing more testing of different scenarios regarding transacted
> sessions and different acknowledgement nodes and here is what I've found
> regarding this topic/behavior:
>
> My initial tests (and what I provided logs for) didn't use transactions and
> used auto acknowledge:
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>
> I also tested with client acknowledgement:
> Session session = connection.createSession(false,
> Session.CLIENT_ACKNOWLEDGE);
> and had the same behavior occur - message consumption stopped after the
> second failover.
>
> I then tested with using transactions (which is our normal use case but not
> 100% of the time):
> Session session = connection.createSession(transacted,
> Session.SESSION_TRANSACTED);
> and this test was successful.  I failed over multiple times (at least 3) and
> each time message consumption continued.  Messages that could not be
> committed because a failover was in progress were redelivered correctly once
> the client connected to the new master node.
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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

C++ imperative client API

[VERMEULEN Olivier]

Hello,

We already discussed with some of you our need @Murex for a C++ imperative 
client API.
I remember Justin saying that you were making progress on this subject but I 
can't seem to find any information about it.
Could you give us a quick status on this? Note that we would also be interested 
in contributing to the development of this new client.

Thanks,
Olivier
***

This e-mail contains information for the intended recipient only. It may 
contain proprietary material or confidential information. If you are not the 
intended recipient you are not authorised to distribute, copy or use this 
e-mail or any attachment to it. Murex cannot guarantee that it is virus free 
and accepts no responsibility for any loss or damage arising from its use. If 
you have received this e-mail in error please notify immediately the sender and 
delete the original email received, any attachments and all copies from your 
system.