thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrique Mendonça <henri...@apache.org>
Subject Re: thrift c++ client and recovering connection
Date Sun, 20 Jul 2014 08:12:40 GMT
Hi Denis,

You can write something like a singleton connection manager to keep your
connection open, i.e. client = mngr.getClient();
You can have a look on a singleton pattern for example but be careful since
sockets are normally not thread safe. You cannot share sockets between
threads without proper synchronisation.
I wanted to add a sample of this on the contrib folder, but my code is not
reusable as it is. Please, let us know if you have something ;)
I hope it helped.

Best,
Henrique


On 19 July 2014 20:24, Phillip Simbwa <simbwa@gmail.com> wrote:

> As suggested by Nevo, you have the option to recreate the whole connection
> setup on the client side.  Its probably the most logical and easiest way.
>
> But you may also consider setting the send and receive timeouts options on
> the client side to avoid premature connection breaks.
> Then on the server side, you could actually setup monit to monitor and
> restart the server app in case it dies mysteriously for some reason.
>
> That should should sort you out.
>
>
>
>
>
>
> On Sat, Jul 19, 2014 at 12:59 PM, Denis Samoilov <samoilov@gmail.com>
> wrote:
>
> > hm, i am not sure. Because connection pooling is more than one
> connection.
> > I need just one but keep it always available (reconnect on errors).
> >
> > On July 17, 2014 at 6:01:38 PM, Phillip Simbwa (simbwa@gmail.com) wrote:
> >
> > Are you looking for the equivalent of connection pooling on the client
> > side?
> >
> >
> > On Fri, Jul 18, 2014 at 2:01 AM, Denis Samoilov <samoilov@gmail.com>
> > wrote:
> >
> > > hi community,
> > >
> > > currently i use per call connection but due increase of communication
> > > thinking to move to the model with always open connection. In this case
> > I
> > > need to handle situation when connection is lost and reopen it.
> > >
> > > What is right way to do this? Do I need to recreate client after
> > connection
> > > lost? Because simply transport->open() does not work. Also, what would
> > be
> > > correct exception to catch (currently i think to reconnect on any
> > > exception)?
> > >
> > > Thank you!
> > >
> >
> >
> >
> > --
> > - Phillip.
> >
> > "Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in
> > waht
> > oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the
> > frist
> > and lsat ltteer are in the rghit pclae.
> > The rset can be a toatl mses and
> > you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed
> > ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it
> > out aynawy."
> >
> >
>
>
> --
> - Phillip.
>
> "Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in
> waht
> oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist
> and lsat ltteer are in the rghit pclae.
>  The rset can be a toatl mses  and
> you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed
> ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it
> out aynawy."
>

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