On Wed, May 28, 2008 at 4:09 PM, Robert Greig <[EMAIL PROTECTED]> wrote:
> 2008/5/28 Rajith Attapattu <[EMAIL PROTECTED]>: > > > You can do this in the trunk client while using only the JMS API. > > If you know your message sizes (payload) then you can set > > -Dmessage_size_before_sync=x and then it will issue a sync after that > amount > > of bytes are transfered. > > OK, but I think most users will think in terms of messages rather than > bytes? Did you add this based on a real user requirement? > This was added for a completely different reason. That is to control our replay buffer and avoid memory issues. I just mentioned this as a possible option. I totally agree that the option below is the one that makes more sense. > > This will of course not be effective if you have varying message sizes. > > We could easily add a jvm argument to track messages. Ex > > Dmessage_count_before_sync=x. > > Setting that to 1 will give you what you want. > > You could also do this per connection or destination by specifying it as > an > > option. > > I think we'd want to add this. > > > There was also some discussion on making the session entirely sync or > async > > based on an argument. > > In such a case every AMQP command will be synchrnous. I think C++ client > > already has this option (or trying to add it). > > Maybe we could do this for JMS folks who want that kinda behaviour by > > specifying a jvm argument or connection argument. > > Maybe, I think we want to have enough flexibility to enable users to > tune bits they want while having sensible defaults. Having all sync or > all async may not be what people want - for example I can see that > people will want sync publish but async ack since most people design > their systems (in my experience) for at least once message delivery. I suggested this as a convinience for some people you want everything synchronous. The default should always be async. This is in addition to the above I suggested. > > > RG > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
