|
First, thanks to all who wrote "I see your
drivel". This time I rcvd my own msg back (a first), so was surprised that
others had had to suffer repeats. Scott,, the GSKit error does indeed appear in httpapi_debug.txt.
Other than innocent entries, and the rqs/rpy XML, here is exactly how the
latest file ends: (GSKit) An operation
which is not valid for the current SSL session state was attempted. ssl_error(5): (GSKit) An
operation which is not valid for the current SSL session state was attempted. SetError() #44: CommSSL_read: read:(GSKit) An operation which is not
valid for the current SSL http_close(): entered Regarding the alleged double-rqs bursts, they were always
highly intermittent (occurring maybe once every 25 runs, otherwise flawless). After
I complained to UPS that they were sending bookmarks, then returning "no
more data" after the follow-up rqs, they eventually produced logs that claimed to show my application was
occasionally emitting a 2nd rqs while the 1st was still being processed. Their
app had already locked the “next” file, so a “no more data”
response was sent, in response to the 2nd rqs, right before the
data-response to the original (1st in this sequence) rqs. Anyway, since I wrote to the forum, the thing has been
running perfectly (other than the GSKit thing, which does no harm whatever). It
seemed pretty clear to me UPS had made a code change, because I sure haven’t,
but they categorically denied it. Unfortunately, I have no debug log from the
era when the alleged error was occurring. Let it go… Thanks, P.S. I will utter the standard, but nevertheless heartfelt,
paean of gratitude to Scott for this software. “THANKS! Saved our a**!.” -----Original Message----- Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx> > I've sent several posts, with problems, attesting to the fact I
long > since downloaded the beta-version and have been using it. Nobody
ever > replies. Eg., here was my most recent: (please reply that this is > visible, even if you cannot help - THANKS): I'm seeing your message. > The problem is that UPS have presented evidence that, somewhere in
the > guts of the httpapi code, double-requests are generated, ie. a 2nd
rqs > is occasionally being emitted before the UPS response has been
received. > Coincidentally or not, the 2nd rqs is emitted about 10-11 secs
after the > 1st. Do you have a debug file of when this is happening? Or, do you know of
a way to reproduce it? I can't think of any way that the code in HTTPAPI could do this, unless
you call it twice, of course. > P.P.S. An error constantly seen in the joblog is: (GSKit) An
operation > which is not valid for the current SSL session state was
attempted. I > don't think this is remotely connected with the above problem, but
I > thought I'd mention this fact. You find this in the job log, not in the httpapi_debug.txt log? That's very strange. Can you tell
me how to reproduce that message? ----------------------------------------------------------------------- This is the FTPAPI mailing list.
To unsubsribe from the list send mail to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr ----------------------------------------------------------------------- |