On 6/12/13 11:10 AM, Benjamin Franksen wrote:
> On Monday, June 10, 2013 17:22:12 Carl Lionberger wrote:
>> We have several instances of a sequencer that occasionally start getting
>> messages such as this, every 10 seconds or so:
>>
>> sevr=fatal pvGet(ss sscanner, var PVL[23], pv SR08U___GDS1HS_BC03): failed
>> (timeout waiting for other get requests to finish)
>>
>> examining that channel with seqChanShow shows:
>>
>> #84 of 99:
>> Variable name: "PVL[23]"
>> type = long
>> count = 1
>> Value = 0
>> Assigned to "SR08U___GDS1HS_BC03"
>> Connected
>> Not monitored
>> Not sync'ed
>> Status = 10
>> Severity = 2
>> Message = get completion timeout
>> Time stamp = 2013-06-08 22:00:24.857905
>> Next? (+/- skip count)
>>
>> Looking at the code in seq_ca.c and seq_if.c, it seems that if a
>> synchronous pvGet ever fails to get a callback from channel access, the
>> "get completion timeout" message is set in the channel metadata and all
>> subsequent attempts to do pvGets on that channel will fail as in the first
>> message. The latter occurs because there is a get semaphore for each
>> channel that the callback is supposed to give.
>>
>> My thought is that if the callback doesn't come the semaphore should be
>> released in the same code that sets the "get completion timeout" message.
>
> This is a difficult question.
>
> Suppose I make this change in the sequencer code.
>
> Now imagine this scenario: your program will continue to issue pvGet request
> (even though the first one failed). Now, suppose the CA callback /does/
> arrive, only late. Maybe right after you issued your second request. Then the
> sequencer will think that the response (from CA) is to your second request,
> when in reality it is the response to the first request.
>
> I think what is really needed is a way to /cancel/ the request. I am not sure
> but I think the CA client API does not offer this possibility, at least not
> when using ca_get_callback.
>
> I find it very hard to judge what the correct behaviour is, here.
>
> Maybe Jeff can comment?
>
>> Or is there something the operator should be able to do, short of
>> restarting the sequencer?
>
> There is not, currently, but I could add something. Maybe letting the
> programmer explicitly "recover" from timeouts is better than doing it
> automatically, at least as long as (and assuming that) canceling pvGet
> requests is not supported by the CA client API.
Hi, Ben.
I think I've run into Carl's problem before too.
Could you supply the CA callback with a sequence number that would
uniquely identify the callback as being for a particular pvGet? This
way, you could ignore a callback if it arrives for a pvGet that has been
abandoned.
Thanks,
Lewis
- Replies:
- Re: pvGet timeout in sequencer 2.1.12 Benjamin Franksen
- References:
- pvGet timeout in sequencer 2.1.12 Carl Lionberger
- Re: pvGet timeout in sequencer 2.1.12 Benjamin Franksen
- Navigate by Date:
- Prev:
SEQ keep PV value during seq-init Fabian S.
- Next:
RE: Adding error msgs to dbAccess.c Allison, Stephanie
- 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: pvGet timeout in sequencer 2.1.12 Benjamin Franksen
- Next:
Re: pvGet timeout in sequencer 2.1.12 Benjamin Franksen
- 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
|