RE: Does RH MRG End of Life have an Effect on QPID?
Hi Tom, I don't speak for Red Hat, but I can say that Red Hat != Apache Qpid. The Apache Qpid future is still bright with plenty of effort behind it on all the various facets (C++, Java, proton, dispatch, etc.) I have customers that have placed large bets on Apache Qpid-based systems. They expect returns. -Steve Huston > -Original Message- > From: tom peterson [mailto:2tompeter...@gmail.com] > Sent: Thursday, December 04, 2014 1:24 PM > To: users@qpid.apache.org; d...@qpid.apache.org > Subject: Does RH MRG End of Life have an Effect on QPID? > > It seems RH is EOL'ing MRG and is pushing A-MQ (ActiveMQ underneath) as > their enterprise messaging solution. Does this change in direction have an > effect QPID's status moving forward? We are looking at using QPID on a > project but want to make sure that it is not being EOL'd as well. > > Thanks for any advice you can render. > > tom
landing proton engine examples on 'trunk'
I believe it would be beneficial to land the examples I have been evolving on the examples branch to the master. There is still some internal work, the examples need some rationalisation and of course feedback is still actively sought and welcomed which may refine and further shape things. However all that I think can be done on the master and having the code there will make broader collaboration and wider review more likely. The patch I propose to commit is https://reviews.apache.org/r/28770/ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Qpid client disconnect notification
(Adding users@ to get more input)
> -Original Message-
> From: srodof [mailto:sfodor...@gmail.com]
> Sent: Friday, December 05, 2014 11:16 AM
> To: d...@qpid.apache.org
> Subject: Qpid client disconnect notification
>
> I have a qpid sender c++ and multiple qpid receivers in Java, using c++
> broker.
>
> I would like to know in c++ every time a java client disconnect.
>
> Looking into this forum i found that creating a c++ receiver that listens to
> qmf.default.topic/agent.ind.event.org_apache_qpid_broker.#;
> {node:{type:topic}}
> i get every disconnect msg on the broker.
>
> The problem is that the disconnect msg doesn't provide the topic name or
> the username. For some reason reports user:anonymous, which is wrong.
What auth mechanism did the Java client use? The username used in that
authentication is what should be reported.
-Steve
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
JCA Adapter module ([jira] [Created] (QPID-6229) Enable non-transacted connections with AMQP-08, -09, -091)
Are there any committers out there who are familiar with the JCA component and can review (and apply) the patch attached to QPID-6229 supplied last month by one of our user community. I'm not familiar enough with the workings of that component to know if there would be any unintended side-effects. Thanks, Rob -- Forwarded message -- From: Nathan Kunkee (JIRA) Date: 17 November 2014 at 20:56 Subject: [jira] [Created] (QPID-6229) Enable non-transacted connections with AMQP-08, -09, -091 To: d...@qpid.apache.org Nathan Kunkee created QPID-6229: --- Summary: Enable non-transacted connections with AMQP-08, -09, -091 Key: QPID-6229 URL: https://issues.apache.org/jira/browse/QPID-6229 Project: Qpid Issue Type: Bug Components: JCA Affects Versions: 0.30, 0.29 Environment: Glassfish 4, Wildfly 8.1 Reporter: Nathan Kunkee Currently, jca/src/main/java/org/apache/qpid/ra/QpidRAManagedConnection.java does not distinguish between transacted setups and non-transacted setups. It will always try and create a _xaSession, even if the user has declined by setting the connection factory to NoTransaction, or setting the property UseLocalTx to true. The attached patch changes the setup() method in QpidRAManageConnection to only create _xaSession objects when transactions have been requested. Without this patch, it is impossible to use the JCA adapter with older protocols (amqp-08, -09, -091). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: In memory/embedded Java client testing
On 4 December 2014 at 01:13, Nathan Kunkee wrote: > Hi all, > > I have a project that successfully passes messages between Glassfish 4, > Qpid 0.30 JCA adapter (see also the issues I logged), and RabbitMQ 3.3.4. I > am now looking to add some integration tests in Java for the entire message > flow, so through producers and consumers. As the InVM version of the broker > was retired, the only guide I've found for this is the following > stackoverflow post: > > http://stackoverflow.com/questions/2176043/example-of- > standalone-apache-qpid-amqp-junit-test > > Sadly, that's probably about the best way to do it at the moment - It shouldn't be a *huge* piece of work for us to recreate something like the old InVM transport, but it's just not something we've prioritized so far. I'll take a look at it over the weekend to see how big a piece of work it might be. Similarly it would be nice if we provided a way to set up configuration in memory for an embedded broker for testing purposes so you don't have to write out config files... I'll take a look at that as well. > Is there any other or easier way to incorporate the Qpid Java broker into > testing? Does anyone have any suggestions for how to inject mock objects > related to Qpid into my testing? > > I appreciate any ideas you have! Thank you, > Nathan > Sorry I can't be more help right now. -- Rob > > > This email message is a private communication. The information > transmitted, including attachments, is intended only for the person or > entity to which it is addressed and may contain confidential, privileged, > and/or proprietary material. Any review, duplication, retransmission, > distribution, or other use of, or taking of any action in reliance upon, > this information by persons or entities other than the intended recipient > is unauthorized by the sender and is prohibited. If you have received this > message in error, please contact the sender immediately by return email and > delete the original message from all computer systems. Thank you. > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
