Kay,
Does the thread remain stuck in that subroutine (in asAddClient in the
access security library attempting to register a new client) when you run tt
multiple times?
Here is an excerpt from the ADG concerning the mutex locking in the access
security library:
Because it is possible for multiple tasks to simultaneously modify the
access security database it is necessary to provide
locking. Rather than try to provide low level locking, the entire access
security database is locked during critical
operations. The only things this should hold up are access initialization,
CA searches, CA clears, and diagnostic routines.
It should NEVER cause record processing to wait. In addition CA gets and
puts should never be delayed. One exception
exists. If the ASG field of a record is changed then asChangeGroup is called
which locks.
All operations invoked from outside the access security library that cause
changes to the internal structures of the access
security database.routines lock.
It might be interesting to run this diagnostic on this IOC (I would use sp
to spawn it in case it hangs).
9.9.4 ascar
Format:
ascar(level)
Prints a report of the channel access links for the INP fields of the access
security rules. Level 0 produces a summary
report. Level 1 produces a summary report plus details on any unconnect
channels. Level 2 produces the summary nreport
plus a detail report on each channel.
Jeff
> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:[email protected]]
> Sent: Tuesday, April 25, 2006 9:55 AM
> To: tech talk
> Subject: Re: No more CA connections? R3.14.7, 3.14.8.2, CAJ
>
> Hi:
>
> Some new info about this issue...
> > The symptom: Everything on the IOC looks great,
> > but the IOC allows no new CA connections.
> > "casr" shows several existing CA connections,
> > and they in fact continue to work fine.
> >
> > Additional suspicious fact:
> > A "caget some_pv" ...will print an error message after 2 seconds,
> > but then hang for a total of ~30 seconds.
> > And "casr" on the IOC will show a new connection,
> > even though caget never got a value.
>
> This is the "casr 2" output for such a new connection that
> never returns a value to the client:
>
> TCP 172.31.72.101:55622(ics-accl-srv1): User="kasemir", V4.11, 1
> Channels, Priority=50
> Task Id=0xe32580, Socket FD=54
> Secs since last send 189.24, Secs since last receive 189.22
> Unprocessed request bytes=0, Undelivered response bytes=48
> State=up
> 372 bytes allocated
> SCL_LLRF:FCM21d:AFF_Mode(0--)
>
> Task trace for that IOC server thread:
>
> scl-llrf-ioc21d> tt 0xe32580
> 1fa774 vxTaskEntry +68 : 1b60b48 ()
> 1b60bb8 epicsThreadPrivateGet+f8 : camsgtask ()
> 1a777f4 camsgtask +36c: camessage ()
> 1a7c750 camessage +320: 1a79df0 ()
> 1a79df0 casUserNameInitiatingCurrentThread+2404: asAddClient ()
> 1a88cf8 asAddClient +110: epicsMutexLock ()
> 1b57888 epicsMutexLock +24 : semTake ()
> 1f0c74 semTake +13c: semMTake ()
>
> -Kay
- Replies:
- Re: No more CA connections? R3.14.7, 3.14.8.2, CAJ Kay-Uwe Kasemir
- References:
- Re: No more CA connections? R3.14.7, 3.14.8.2, CAJ Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: No more CA connections? R3.14.7, 3.14.8.2, CAJ Kay-Uwe Kasemir
- Next:
StripTool bogs down host? John Dobbins
- 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: No more CA connections? R3.14.7, 3.14.8.2, CAJ Kay-Uwe Kasemir
- Next:
Re: No more CA connections? R3.14.7, 3.14.8.2, CAJ Kay-Uwe Kasemir
- 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
|