You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Denis Samoilov <sa...@gmail.com> on 2014/07/18 01:01:53 UTC
thrift c++ client and recovering connection
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!
Re: thrift c++ client and recovering connection
Posted by Denis Samoilov <sa...@gmail.com>.
thank you! this is what I do now but decided to check that i do not miss simpler way.
On July 18, 2014 at 9:59:23 AM, Nevo Hed (nhed+thriftusr@aereo.com) wrote:
Hi Denis
I don't know whats the "right" way, but I know that I recreate the whole
stack on a reconnection
i.e.:
sock = boost::shared_ptr<TSocket> socket(new TSocket(..., ...));
trans = boost::shared_ptr<TTransport>(new TFramedTransport(sock));
boost::shared_ptr<TProtocol> protocol(new TBinaryProtocol(trans));
client = boost::shared_ptr<MyClient>(new MyClient(protocol));
trans->open();
On Thu, Jul 17, 2014 at 7:01 PM, Denis Samoilov <sa...@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!
>
Re: thrift c++ client and recovering connection
Posted by Nevo Hed <nh...@aereo.com>.
Hi Denis
I don't know whats the "right" way, but I know that I recreate the whole
stack on a reconnection
i.e.:
sock = boost::shared_ptr<TSocket> socket(new TSocket(..., ...));
trans = boost::shared_ptr<TTransport>(new TFramedTransport(sock));
boost::shared_ptr<TProtocol> protocol(new TBinaryProtocol(trans));
client = boost::shared_ptr<MyClient>(new MyClient(protocol));
trans->open();
On Thu, Jul 17, 2014 at 7:01 PM, Denis Samoilov <sa...@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!
>
Re: thrift c++ client and recovering connection
Posted by Henrique Mendonça <he...@apache.org>.
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 <si...@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 <sa...@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 <sa...@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."
>
Re: thrift c++ client and recovering connection
Posted by Phillip Simbwa <si...@gmail.com>.
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 <sa...@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 <sa...@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."
Re: thrift c++ client and recovering connection
Posted by Denis Samoilov <sa...@gmail.com>.
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 <sa...@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."
Re: thrift c++ client and recovering connection
Posted by Phillip Simbwa <si...@gmail.com>.
Are you looking for the equivalent of connection pooling on the client side?
On Fri, Jul 18, 2014 at 2:01 AM, Denis Samoilov <sa...@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."