Print

Print


	Thank you Andy. It answers a lot.

	I am wondering if someone has developed a
set of scripts/tools/whatever to follow and trace requests through
the system. The idea being that when we were tracing the recent
problems with some of our data which would never be accessible, the
process was rather manual and a bit painful:
- look at redirector's logs (two of them in STAR so need to find
  the proper one)
- find where the client was redirected (which supervisor)
- go to the supervisor, check the logs ... see what happens there
- find where the request was redirected ...
- go to the data-sever, look at the log ..
+ of course, we guessed the states

	If this kind of tracing could be achieved by a tool, would
be great. If none exists, will try thinking of something (even if
historical info is short, would be best than the steps above) and
with this goal in mind, the state diagram is rather important (and
we have a general picture from your description).

	Cheers,
	

On 2011/04/19 22:35, Andrew Hanushevsky wrote:
> Hi Jerome,
> 
> There is no comprehensive state diagram because the states are
> relatively complex. The basic sequence is:
> 
> do_Select->[do_State]->{do_Found | do_Fail |
> [do_Wait[->do_Found]->]do_Delay}
> 
> To start do_Select can be optionally followed by a do_State. This state
> is entered if do_Select resulted in a nil state or conditions indicate
> that do_State is still pending for one or more servers. This is followed
> by one of three states: do_Found (file found), do_Fail (file
> conclusively not found) or an optionally prefixed sequence of additional
> states that may resolve into a do_Found or a do_Delay.
> 
> The do_Have state is asynchronous and if entered when the corresponding
> state is do_Wait then do_Wait transitions to do_Found. However, note
> that do_Wait is optional and sometimes is not entered. Additionally,
> do_Wait is a temporary state and if do_Have does not occur when this
> state is active, we automatically transition to do_Delay.
> 
> The do_Found state redirects the client, do_Fail tells the client the
> file does not exist, and the do_Delay state tells the client to come
> back later. All are ending states.
> 
> Hope this answers things a bit.
> 
> Andy
> 
> -----Original Message----- From: Jerome LAURET
> Sent: Tuesday, April 19, 2011 8:05 AM
> To: xrootd-l
> Subject: simple question on flow diagram
> 
> 
> Is there a write-up somewhere documenting the state diagram
> related to your messages do_State, do_Have, do_Select etc ...?
> 
> Thank you,
> 

-- 
             ,,,,,
            ( o o )
         --m---U---m--
             Jerome