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 <[email protected]>
Sent: Tuesday, February 27, 2018 3:53 PM
To: Torsten Bögershausen; Mark Rivers; [email protected]
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:[email protected]]
Sent: Tuesday, February 27, 2018 3:37 PM
To: Daykin, Evan <[email protected]>; Mark Rivers <[email protected]>; [email protected]
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 ?
- References:
- Asyn not automatically reconnecting Daykin, Evan
- RE: Asyn not automatically reconnecting Daykin, Evan
- RE: Asyn not automatically reconnecting Daykin, Evan
- Navigate by Date:
- Prev:
RE: Asyn not automatically reconnecting Daykin, Evan
- Next:
Re: Idea for new Display Manager Whitney R. Armstrong
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Asyn not automatically reconnecting Daykin, Evan
- Next:
RE: Asyn not automatically reconnecting Daykin, Evan
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|