hanism - and the ability to sync
> to disk for every write is usually a property of the Store used by
> the broker. For amq 5.0 - the default store is the amq store -
> where the property is syncOnWrite, default is off.
> On Sep 21, 2007, at 12:44 AM, tendlu wrote:
>
James or Hiram?
tendlu wrote:
>
> Tibco has a configuration to mark a queue "fail safe". This means the
> messages for a "fail safe" queue is synchronously written to the disk. In
> other words, no buffering is done for write (probably uses fsync -- that
>
Tibco has a configuration to mark a queue "fail safe". This means the
messages for a "fail safe" queue is synchronously written to the disk. In
other words, no buffering is done for write (probably uses fsync -- that
gaurantees the data is flushed to the disk). If the server goes down, no
message
You are correct. The Session was shared among threads and it was a bug in the
test case. A Session per thread solved the problem.
Thanks a lot James.
James.Strachan wrote:
>
> On 9/7/07, tendlu <[EMAIL PROTECTED]> wrote:
>> Not all messages(persistent) to a queue are sen
Not all messages(persistent) to a queue are sent to the broker if messages
are sent from multiple threads. Each thread creates its own connection and
session.
Please let me know if I am missing something or is this a bug?
--
View this message in context:
http://www.nabble.com/Help%21-Missing-m
Any clues?
tendlu wrote:
>
> Using ActiveMQ 4.1
>
> I have a producer that does the following -
>
> 1. main thread creates a Connectionfactory using tcp
> 2. creates a few threads - say 5
> 3. each thread creates a new Connection and a new Session using the
> conne
Using ActiveMQ 4.1
I have a producer that does the following -
1. main thread creates a Connectionfactory using tcp
2. creates a few threads - say 5
3. each thread creates a new Connection and a new Session using the
connectionfactory created in the main thread. Session is created with
auto-ack
