request failed-return value 500

Anonymous
Topic 13181

Quote:
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.

Bruce Allen
Bruce Allen
Joined: 15 Oct 04
Posts: 958
Credit: 170,849,008
RAC: 0

request failed-return value 500

Quote:
The other thing I've noticed is that the minute logs don't always seem to have the full minute. I've seen examples of small bits of time missing at the start and the end of each minute. Maybe this is an artifact of the log slicing process. If we are unlucky, maybe your bit of the server log just happens to be missing. I'll post a query in Bruce's thread. Hopefully he'll see it.

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.

Bruce Allen
Bruce Allen
Joined: 15 Oct 04
Posts: 958
Credit: 170,849,008
RAC: 0

RE: So all we have to do is

Quote:
So all we have to do is work out what is wrong with the maths for your case. We simply must be looking in the wrong log slice.


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.)

Quote:
Please right click your clock and -> Adjust Date/Time and go to the Time Zone tab. You see your world map so please tell us what it says there for time zone. Thank you.


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.

Bruce Allen
Bruce Allen
Joined: 15 Oct 04
Posts: 958
Credit: 170,849,008
RAC: 0

RE: And after reading this

Quote:
And after reading this thread more thorough, I suspect you will not find
the mentioned incident in the scheduler logs, because no scheduler is
involved during upload !?


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.

Bruce Allen
Bruce Allen
Joined: 15 Oct 04
Posts: 958
Credit: 170,849,008
RAC: 0

RE: RE: He's probably got

Quote:
Quote:
He's probably got a fast internet connection and grepped through the entire log system. I was almost tempted to do this at one stage :).

Yes and no. The last scheduler reply is listed here and Brad posted it.


I thought that this was a potentially useful trick, so I linked the 'last scheduler contact' time to the appropriate scheduler log minute file.

Bruce Allen
Bruce Allen
Joined: 15 Oct 04
Posts: 958
Credit: 170,849,008
RAC: 0

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

Bruce Allen
Bruce Allen
Joined: 15 Oct 04
Posts: 958
Credit: 170,849,008
RAC: 0

RE: Problem solved!! The

Quote:
Problem solved!! The whole nine yards! :-)
Dear Brad had just about every protection software suite known to man installed ( about ten products - now un-installed ). Bless him! :-)
I guess the CGI scripts were getting blocked as defensive therapy - I understand they can be viewed with suspicion by such software. Now he's got choose one and re-install so as to not go bare.

Mike, Brad, congratulations! This was an inspiring saga with a happy ending!

Cheers,
Bruce

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.