Hi Gary, thanks for your answer... a few more related questions (remember that we only use persistent msgs in transacted sessions):
1\ You suggest copyMsgOnSend=false as a way to alleviate some the effects of performing sync send(): what is the QoS/functional price to pay when copyMsgOnSend is turned off? 2\ What are the main parameters to tune to try to make transacted sync send() "as *async as possible" (e.g. paying the sync price at commit() time but not every single send())? Cheers, F. On Thu, Jan 28, 2010 at 6:00 PM, Gary Tully <gary.tu...@gmail.com> wrote: > If you don't want to use an ExceptionListener then you need to have every > send synced with the broker, so you need alwaysSyncSend. > However, this will give the worst latency so you may want to have a pool of > producers on separate connections so that you can get some parallelism. > > If you can live with using an ExceptionListener then the default (asyncSend > for messages in a transaction) will work fine. > Also set copuMsgOnSend=false to save some cycles on each send. > > > On 28 January 2010 16:47, Fred Moore <fred.moor...@gmail.com> wrote: > > > Hi folks, > > > > we have a fast producer sending persistent messages in transaction and > > committing them every X msgs or Y seconds, our requirements are: > > > > 1\ ability to minimize the send() latency (and overall performance) > > > > 2\ ability to detect any JMSExceptions at commit() time (or at send() > time) > > and catching them in the producer thread without resorting to using > > ExceptionListeners()... this is to allow us to perform a timely detection > > and management of <systemUsage> related JMSExceptions. > > > > What is the "golden mix" of these queue connection factory attributes > that > > you recommend in this scenario: > > > > * useAsyncSend > > * alwaysSessionAsync > > * alwaysSyncSend > > * sendAcksAsync > > > > Cheers, > > F. > > > > > > -- > http://blog.garytully.com > > Open Source Integration > http://fusesource.com >
