Comments:

Flat Nested Threaded Embedded

Oldest First Newest First

Author	Thread:
fred.waid	problems with the WebTransfer object and APLWebservices Posted: Thursday, August 05, 2004 2:14 PM (EST) The first issue with APL closing is specific to 2000 and applies to Com and Com+ objects in certain states.  We are already working on a solution to this issue.   We will have a fix for the error thrown when a Dispose occurs in the next version, sometime this week.   On the third issue, could you look at the server log and see if all of the transactions (posts) have a content length.  We are specifically looking for any which are missing a content length, or perhaps have a content length which would be invalid, such as enormously large, or 0.   There is also the potential for a race condition to exist using SendOject with short timeouts.  If you send a valid header, including a content length, then terminate the connection just before the entire post is sent, then reconnect with the same Com Object, sending another post, the Windows stack will in some cases reuse the last socket and then the server would take the next header as the rest of the post from the previous transaction.  The server would then not recognize the incoming data as valid and make the related call to APL with a null argument.     We are adding a new option to the server to log the entire transaction.  When selected, this has the potential to create very large log files, but should give us the additional information we need to determine what is happening.
Owen.Shelksohn	problems with the WebTransfer object and APLWebservices Posted: Thursday, August 05, 2004 4:34 PM (EST) Thanks for your quick answers. Do you have an estimate of the timescale until a fix for the first issue will be available? Like weeks versus months?    I haven't had logging on because the logs get very large. I will turn it on for at least a day and see if any of the requests are as you describe.   About the short timeout possibility; how short is short? I'm using 30 seconds right now. If windows reusing the COM object is the problem, is it therefore a possible workaround to delete and recreate the WebTransfer object for each request? I'll try that and see if anything changes.
fred.waid	problems with the WebTransfer object and APLWebservices Posted: Thursday, August 05, 2004 4:43 PM (EST) I do not believe that deleting the COM object will help.  It is the underlying Windows Socket layer that periodically reuses the same socket if referenced too quickly.  As you are using 30 seconds, this should not be the issue.   We will put up the new Server with additional logging options this week as well.  I think that will give us a lot of insight.   As for the APL interpreter fix, we do not have a definite timeline as yet, but it is an active issue.
Owen.Shelksohn	problems with the WebTransfer object and APLWebservices Posted: Friday, August 06, 2004 1:14 PM (EST) I see this in the log:   Failed to deserialize. Reason: Attempting to deserialize an empty stream.   but I haven't seen any entries with a too large or too small content length. Does this tell you anything more about where the problem is?   Also, I made all processes on one machine use a 30 second timeout, and had them delete/recreate the webtransfer object each time. You were right in that this changed nothing.
Jairo.Lopez	problems with the WebTransfer object and APLWebservices Posted: Friday, August 06, 2004 1:25 PM (EST) Owen,   What is the entry in the log just before the error?
Owen.Shelksohn	problems with the WebTransfer object and APLWebservices Posted: Friday, August 06, 2004 1:29 PM (EST) they always look normal:   ===================================== 2004-08-05 11:40:22Z POST /exchangeRobotAPLData HTTP/1.1 Content-Type: application/octet-stream Content-Length: 327 Expect: 100-continue Connection: Close Host: 127.0.0.1:8801 ===================================== 2004-08-05 11:40:23Z Failed to deserialize. Reason: Attempting to deserialize an empty stream. ===================================== 2004-08-05 11:40:23Z POST /exchangeRobotAPLData HTTP/1.1 Content-Type: application/octet-stream Content-Length: 365 Expect: 100-continue Connection: Close Host: 127.0.0.1:8801 =====================================