On 29 January 2010 08:15, Fred Moore <fred.moor...@gmail.com> wrote: > 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? > > The only implication is that any modifications you make to he message after a send may or may not be visible to the broker. Once you treat the message as immutable after a send there is not down side.
> 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())? > > The defaults are fine. It will use async send for all messages and a sync send for the transaction commit, but with a memory limit and sendFailIfNoSpace, any of the individual sends may fail and as they are sent async, you need to register an exception listener to catch that potential failure. > 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 > > > -- http://blog.garytully.com Open Source Integration http://fusesource.com
