I'm surprised that calling Connection.stop() doesn't abort failover.
Nevertheless, to abort failover I believe you can just return false from
org.apache.qpid.jms.ConnectionListener.preFailover(). I guess your
implementation would return false if the application was trying to shut
down.
I don't t
Hi Marco,
It sounds like you haven't configured the number of retries in your
connection URL.
The connection URL options are described here, along with some examples:
http://qpid.apache.org/releases/qpid-0.22/programming/book/QpidJNDI.html
During a normal client application shutdown, note that y
Hi Marco,
Try this:
((AMQConnection)yourJmsConnection).setConnectionListener(
new org.apache.qpid.jms.ConnectionListener() {
...
public void failoverComplete() {
...
}
...
}
Phil
On 24 July 2013 09:26, pela wrote:
> Hi,
>
> I'm building a client with JMS API and want
Hi Rajib,
There are many reasons why an operation can time out.
Can you provide more of your client log, especially the stack trace of the
exception?
Do you see any errors or warning in your broker or client log before the
problem occurs?
What makes you think this is a "slow consumer issue", an
broker (broker A). Still I'm a student. This is one of my research
> project. Is this fundamentally correct ? Is this possible to achieve
> through java brokers.
>
> Regards,
> Anu
>
>
> On Sat, May 11, 2013 at 1:13 PM, Phil Harvey wrote:
>
>> Hi Anu,
>>
Hi Anu,
I've moved this conversation to the users list because I think that's a
better place for it.
Could you expand on your question please - I'm not sure what you mean by
"Java broker network".
If you're referring to a federated group of interconnected brokers, this
isn't currently supported
I replied on the proton@ list.
Setting aside Proton, I'd be interested to know why using the existing Java
or C++ Qpid Broker is not appropriate for you.
Phil
On 26 April 2013 09:31, Maki Camara wrote:
> Any help guys, I think it might be easy for most of you, unfortunately
> it's not my case
Hi Michal,
Yes, that is correct. As you probably guessed, the empty section in the
documentation is there because this store has been considered in the past
but not fully implemented.
The Derby store actually only has a light dependency on Derby and would
only require very minor changes to work
ransport.jms.JMSListener .
> >
> > Thanks for the help.
> > David
> >
> > -Original Message-
> > From: philharveyonl...@googlemail.com
> > [mailto:philharveyonl...@googlemail.com] On Behalf Of Phil Harvey
> > Sent: Sunday, December 09, 2012 12:57 AM
> > To:
Hi David,
You can't exactly encrypt it, but you can avoid hard coding it. You can
refer to system properties in config.xml using the form ${mypassword}.
Expose system properties to the broker before starting it like so:
export QPID_OPTS='-Dmypassword=password1'
I think the broker automatically
g.apache.axis2.transport.jms.JMSListener and there is no such an
> option.
>
> Thanks,
> David
>
>
>
> -Original Message-
> From: philharveyonl...@googlemail.com
> [mailto:philharveyonl...@googlemail.com] On Behalf Of Phil Harvey
> Sent: Saturday, December 08
Hi David,
I assume you're talking about encrypting the stored URL string, and not
about encrypting the details sent over the wire to the broker. I think the
only way to do this is to store it in a secure JNDI context, e.g. one
provided by a Java application server. This is in line with the appro
Hi Gordon,
Yes, you're right - jmsSession.rollback() does result in an AMQP
message.release command.
Phil
On 8 November 2012 08:44, Gordon Sim wrote:
> On 11/08/2012 08:30 AM, Phil Harvey wrote:
>
>> The delivery count is incremented each time the message is rejected by
Jan,
I'm not sure which broker you're using. If you're using the Java Broker,
note that you can configure it to send messages to the dead letter queue
after N attempts with this sort of thing in your virtualhosts.xml:
...
1
...
The delivery count is incremented each tim
Hi,
Qpid uses odd-numbered versions to refer to internal in-progress work.
Hence 0.19 will never be formally released.
The next official Qpid version will be 0.20, due in a few weeks. Details
of the 0.20 schedule are here:
https://cwiki.apache.org/qpid/020-release.html
Phil
On 26 October 201
Hi Praveen,
The Java broker does not currently support federation. I believe that
there are no concrete plans to add this functionality, although it has been
informally discussed within the dev community.
I believe that there was previously some support for federation in the Java
broker (hence t
Have you considered JMS durable subscriptions?
They are described here:
http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/basics.html
On 2 October 2012 11:43, Sajith Kariyawasam wrote:
> Hi all,
>
> My requirement is to notify a cluster of nodes, when an event is occurred..
> nodes
Hi,
Is there anything unusual about your scenario? For example, are your
messages large, or is there a slow network connection to the broker, or are
your client or broker machines heavily loaded? In common with most
messaging brokers, Qpid can process many thousands of messages per second
so the
No worries, I'm glad it's working now.
Given the configuration you provided, I would not expect you to be seeing
topic-like behaviour. Could you provide details of how your JMS clients are
looking up shiftqueue please, both for the producers and the consumer, eg
an excerpt from your JNDI propertie
I think that file contains a similar problem - see my comment below,
shiftqueue
amq.direct
4235264
2117632
360
Hi,
That virtualhosts.xml file doesn't look right to me. I think the
element should be renamed to , i.e the same name as your virtual
host.
I suspect that Qpid is quietly ignoring the element.
Phil
On 25 September 2012 15:42, oggie wrote:
> > When you use topics, a private temp queue is cr
Hi Sajith,
Apart from the fact that you have ~1000 nodes, what other non-functional
requirements do you have? For example:
- What is the acceptable time lag between the application being deployed
and a node receiving notification?
- What frequency of application deployments do you expect?
- Whic
22 matches
Mail list logo
