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 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. RG
