Bruce mentions "3 minute latency". Does that mean search for an entry 3minutes later than time shown in my logs? 3min. earliar? 3min. +/-?
To clarify this, I've modified the message at the start of the logfiles. It now reads:
These files are posted approximately three minutes after the events are logged.

request failed-return value 500
)
Gary, I didn't see this in the other thread (but I'll check again). Could you please give me an example? The three-minute latency exists EXACTLY because I want to capture all events for a given minute, and sometimes events are logged with up to a three minute delay.
RE: So all we have to do is
)
Also possible that there was no scheduler contact at that time. (I'm not sure, I'm not sure which client side log snippet is relevant for this thread.)
Another way to figure out the UTC offset is for a user to look in the sched log directory and see what the most recent log file was. This is about three minutes old. Just comparing this with their computer's clock or the wallclock immediately shows their offset from UTC.
RE: And after reading this
)
Michael, this is correct. File upload does NOT use the scheduler and hence does not appear in the scheduler logs. File upload is an asyncronous process. It is designed this way because this design reduces strain/load on the database.
RE: RE: He's probably got
)
I thought that this was a potentially useful trick, so I linked the 'last scheduler contact' time to the appropriate scheduler log minute file.
Brad (and others!) I just
)
Brad (and others!)
I just wanted to say that I'm impressed by your dedication and committment. I think you're close to getting to the bottom of these problems. I'm rooting for you -- hang in there!!
Bruce
RE: Problem solved!! The
)
Mike, Brad, congratulations! This was an inspiring saga with a happy ending!
Cheers,
Bruce