RE: Asyn not automatically reconnecting

[Mark Rivers <rivers@cars.uchicago.edu>]

Can you post the database, protocol file, and asynTrace output with all asynTrace bits on?

> -----Original Message-----
> From: Daykin, Evan [mailto:daykin@frib.msu.edu]
> Sent: Thursday, March 01, 2018 3:04 PM
> To: Mark Rivers <rivers@cars.uchicago.edu>; Torsten Bögershausen
> <torsten.bogershausen@esss.se>; tech-talk@aps.anl.gov
> Subject: RE: Asyn not automatically reconnecting
> 
> 
> I have tried a database with only a couple of records, and the behavior persists.
> 
> -----Original Message-----
> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
> Sent: Tuesday, February 27, 2018 4:57 PM
> To: Daykin, Evan <daykin@frib.msu.edu>; Torsten Bögershausen
> <torsten.bogershausen@esss.se>; tech-talk@aps.anl.gov
> Subject: Re: Asyn not automatically reconnecting
> 
> Can you try a very simple database with just one or two records talking to your server.  See
> if that works when the server shuts down gracefully.  If it does, but it fails with lots of
> records then we have a clue where to look.
> 
> 
> Mark
> 
> 
> 
> ________________________________
> From: Daykin, Evan <daykin@frib.msu.edu>
> Sent: Tuesday, February 27, 2018 3:53 PM
> To: Torsten Bögershausen; Mark Rivers; tech-talk@aps.anl.gov
> Subject: RE: Asyn not automatically reconnecting
> 
> >Sorry if this is the wrong question, but what is asyn 4.33-2 ?
> >"git tag" mentions R4-33, not "-2".
> 
> That's the revision in our debian repo, it is asyn 4-33.
> 
> > So from asyn everything seems to be OK.
> Maybe this is streamdevice and/or our vendor's software. We will investigate both avenues.
> 
> -----Original Message-----
> From: Torsten Bögershausen [mailto:torsten.bogershausen@esss.se]
> Sent: Tuesday, February 27, 2018 3:37 PM
> To: Daykin, Evan <daykin@frib.msu.edu>; Mark Rivers <rivers@cars.uchicago.edu>; tech-
> talk@aps.anl.gov
> Subject: Re: Asyn not automatically reconnecting
> 
> 
> 
> On 23/02/18 15:17, Daykin, Evan wrote:
> > Hi Mark,
> >
> > Thanks for the reply. We are using asyn 4.33-2 and Stream 2.6-3. The
> > protocol file has a ReplyTimeout of 2000ms.
> 
> Sorry if this is the wrong question, but what is asyn 4.33-2 ?
> "git tag" mentions R4-33, not "-2".
> 
> And to answer the other question:
>  >Here's something interesting: asyn behaves correctly for us *only* when the  >client
> application is killed with SIGKILL, rather than SIGTERM. This results  >in TCP
> retransmissions and/or refused connections, then normal operation after >a short while.  Is it
> possible asyn is [un]intentionally not retrying the >connection if it is closed gracefully?
> 
> 
> The code that I see producing "Read from broken connection" is this:
> 
>      /* If recv() returns 0 on a SOCK_STREAM (TCP) socket, the connection has closed */
>      if ((thisRead == 0) && (tty->socketType == SOCK_STREAM)) {
>          epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize,
>                        "%s connection closed",
>                        tty->IPDeviceName);
>          closeConnection(pasynUser,tty,"Read from broken connection");
> 
> ----------
> And then
> closeConnection(asynUser *pasynUser,ttyController_t *tty,const char *why) {
>      asynPrint(pasynUser, ASYN_TRACE_FLOW,
>                "Close %s connection (fd %d): %s\n", tty->IPDeviceName, tty->fd, why);
> 
> So from asyn everything seems to be OK.
> 
> It seems that the problem described here:
>  >2018/02/23 09:51:47.089 test-rf-dcu-n0001.cts:5001 read.
>  >The last line then repeats rapidly forever.
> 
> is caused by the caller into asyn, which is streamdevice ?
> There seem to be some improvements in streamdevice, but I am not familiar with the code.
> 
> Dirk, does there ring a bell  ?