qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance D." <lan...@gmail.com>
Subject Re: Single threaded Client
Date Thu, 09 May 2013 04:34:09 GMT
Honestly, I'm not going to make a case one way or the other.  As a general
rule, I like my middleware to divorce me, the user, from the underlining
implementation.  That said, I also want more control over how long the
middleware takes to do what I asked for.

As an alternative to exposing OS-provided timeouts or some other timer
functionality, would adding a non-blocking/passive open() call be
reasonable and plausible for the C++ client?

Thanks again?

On Wed, May 8, 2013 at 2:17 PM, Andrew Stitcher <astitcher@redhat.com>wrote:

> On Mon, 2013-05-06 at 20:26 -0400, Lance D. wrote:
> > Thanks all for that advice.  You all are exploring the same paths that
> I've
> > explored in some manner.  I've got requirements that force my code to
> have
> > traceable paths, which makes multi-threading within the application
> > difficult.  Right now, the option I like the best is probably the
> heartbeat
> > option solution.
> Note that the heartbeat solution is the way that you are supposed to do
> this, although it may not be adequately documented.
> >
> > On a side note, what are the chances that we could update the API to
> expose
> > the underlying socket and/or provide the ability to tweak the socket
> > options.  The API already exposes the Nagle option, so I don't see that
> it
> > would be that blasphemous to add in other, similar options.
> There is a low chance you could persuade me it would be a good idea to
> do this! I might be persuaded that doing the opposite makes some sense
> though (in other words importing an existing socket and using that).
> The reason for this is that the underlying code uses an abstraction over
> sockets and that is purely internal - there may not always be a socket
> to expose and trying to do so would just make things hard for not a huge
> gain in my opinion. However importing an existing socket would work
> within the existing code structure to some extent.
> BTW exposing the tcp-nodelay setting was intended to allow the user to
> trade off latency against throughput, rather than to expose a socket
> option specifically. I originally suggested a naming along those lines,
> but tcp-nodelay stuck.
> In the tests we've run, we found that tcp-nodelay is the better setting
> in nearly every circumstance. So we've now made that the default setting
> for the C++ code on trunk.
> Andrew
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message