It would sure be helpful to have stack traces to go along with these.
>This one probably rasied it head due to the reload_into_ims patch I sent. Thi
s
>would happen if two REFRESH requests came in for the same object and tripped
>over each other. I'm guessing the race condition was always there, but now
>it's exercised because of the higher number of REFRESH requests coming in. I'm
>going for the solution of simply shutting down the connection and let the user
>retry as a quick fix. Would someone care to speculate how this event MAY get
>triggered? Then fix?
>
>Assertion failed: entry->store_status != STORE_ABORTED, file client_side.c,
>line 393
Yes, presumably you are making an IMS request against an entry which
is STORE_PENDING. Then that pending entry gets aborted. Hopefully
its been aborted by the server-side. The client-side should not
abort it even if the first client cuts its connection.
It probably safe to remove this assertion. Another approach would be
to require cached entries to be STORE_COMPLETE before making IMS
requests against them.
>This one is tricky and I'm not certain as to how much damage would occur if
>it was ignored. This also occurs the most... This might be caused by me
>using ACLs to prevent forwarding loops??
>
>Assertion failed: fwdState->fail.err_code, file forward.c, line 62
It means that we failed to forward the request without putting any
content in the store entry. If we failed to forward it, then we
should at least fill the entry with an error message saying so.
I'm guessing the users just get "document contains no data" messages
from their browsers.
>I'm guessing that this assertion is pretty safe to just return since the objec
t
>will otherwise be STORE_OK or STORE_ABORTED. If it's STORE_OK then it's
>already finished writing, so who cares? If it's already STORE_ABORTED,
>then who cares. The object is ABORTED and that's what the caller wanted
>to happen already.
>
>Assertion failed: e->store_status == STORE_PENDING, file store.c, line 481
If the status is STORE_OK, then the caller should not be aborting it.
If its already STORE_ABORTED then we should not be aborting it again.
Duane W.
Received on Tue Jul 29 2003 - 13:15:51 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:51 MST