On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu <rajit...@gmail.com>wrote:
> On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross <tr...@redhat.com> wrote: > > > > On 03/05/2013 02:14 PM, Rajith Attapattu wrote: > >> > >> > >> This is a good explanation that we need to put in the docs, as > >> Application developers certainly need to know how it behaves. > >> If one were to use the current C impl, it certainly gives the > >> impression that put() is meant to write messages into your internal > >> buffer and send() will actually write it to the wire. > >> Unfortunately some applications will depend on this behaviour, even > >> though it's not advisable > >> > >> If we are to change from say #2 to #1 or even #3 we need to release > >> note it prominently. > >> > >> I think the best solution is to make this behaviour configurable, and > >> advertise the default very prominently. > >> This way application developers will know exactly what they are > >> getting instead of us making changes underneath. > >> > >> Rajith > >> > > > > Making this configurable multiplies the size of the test matrix. Can't > we > > make this simpler? > > I do understand your concern here, but the Java impl already does both > #1 and #2 and Rafi wants to do #3 in the future. > The old JMS client does something similar. > > I agree that if we just do option #2 (as you suggest below), then the > application can easily do #1 and #3 on top of that. > But I'm sure they will like if the library implements those strategies > for them and they have the ability to pick a strategy. > I don't see why we'd make this configurable. All three options actually fit the same general semantics. Even if you're optimistically trying to transmit every single time put is called it's entirely possible for the socket to be blocked every single time you try. If this were to happen the implementation of #1 would appear to behave precisely the same as #2 behaves. In other words if you're coding correctly against the API you can't assume that put will or won't have transmitted anything regardless of which strategy is used internally. --Rafael
