Yes, if you google JMS delivery mode you'll see what I mean - persistent is
the default for send() on a MessageProducer.
Marnie
On Thu, Jun 10, 2010 at 6:01 PM, Lahiru Gunathilake wrote:
> On Thu, Jun 10, 2010 at 9:53 PM, Marnie McCormack <
> marnie.mccorm...@googlemail.com> wrote:
>
> > Whats y
Hello Chuck,
thank you for your guide how to start with new .NET binding. I will look into
that and let you know my results.
Kind regards,
Petr
> Původní zpráva
> Od: Chuck Rolke
> Předmět: Re: maximum of messages received from the exchange
> Datum: 10.6.2010 1
Thanks for the quick replies. We are concerned not with splitting a single
message, but distributing overflow messages to the journal.
Is it possible to create a queue with both ring and flow-to-disk policies with
a journal larger than the in-memory queue? (Image attached). When element 2000
On Thu, Jun 10, 2010 at 9:53 PM, Marnie McCormack <
marnie.mccorm...@googlemail.com> wrote:
> Whats your message delivery mode ?
>
It's JMS !
Thanks
Lahiru
>
> Marnie
>
> On Thu, Jun 10, 2010 at 5:12 PM, Lahiru Gunathilake >wrote:
>
> > Hi Marnie,
> >
> > Thanks for the reply, what do you mean
Whats your message delivery mode ?
Marnie
On Thu, Jun 10, 2010 at 5:12 PM, Lahiru Gunathilake wrote:
> Hi Marnie,
>
> Thanks for the reply, what do you mean by persistent messaging ? from our
> ESB side we do not have failover configuration but we can always configure
> a
> failover scenario to
Hi Marnie,
Thanks for the reply, what do you mean by persistent messaging ? from our
ESB side we do not have failover configuration but we can always configure a
failover scenario to piont to another qpid instance and from the other esb
we can register all the qpid instances as listeners so those
Hi Lahiru,
Are you using persistent messaging and also do you use failover on client
connections ?
There's currently no clustering support, but I can give you some ideas about
using multiple brokers and depolyment models we've used.
Regards,
Marnie
On Thu, Jun 10, 2010 at 2:29 PM, Lahiru Gunath
On Thu, 2010-06-10 at 08:10 -0500, Wes Parish wrote:
> We have a broker with a modest amount of RAM, but a very large disk capacity.
> Can we create a small in-memory queue, but a large associated journal (for
> persistence)? Basically, we want to allow a persistent queue to hold a
> larger nu
You may want to try using a new binding that provides a thin interop layer
between your C# client and the C++ Messaging API.
To get started with this:
1. Create a Debug build of the cpp/qpid-cpp.sln, the normal cpp build.
2. Open solution cpp/bindings/qpid/dotnet/org.apache.qpid.messaging.sln a
Hi Wes,
Can you provide some more clarification. Do you mean that a single message
might be larger than the RAM that you have and you want to use the persistent
queue to store parts/all of that message? Or do you, more probably mean, that
you can deal with whole messages but you just may not b
On Thu, Jun 10, 2010 at 6:59 PM, Lahiru Gunathilake wrote:
> Hi all,
>
> I am using Qpid as the message storage between two ESB instances and one
> ESB is sending messages to Qpid and other guy is picking those messages from
> Qpid since the first ESB is not allowed to create a connection in to th
Hi all,
I am using Qpid as the message storage between two ESB instances and one ESB
is sending messages to Qpid and other guy is picking those messages from
Qpid since the first ESB is not allowed to create a connection in to the
Zone where second ESB is running. So in this scenario we are having
We have a broker with a modest amount of RAM, but a very large disk capacity.
Can we create a small in-memory queue, but a large associated journal (for
persistence)? Basically, we want to allow a persistent queue to hold a larger
number of elements than the broker has physical RAM to store i
13 matches
Mail list logo
