More - Post Command Problem looks like a RunRev problem?

Mark Smith lists at futilism.com
Mon Nov 17 07:00:52 EST 2008


Dave, I wonder if it would be worth trying to do the post using curl  
(or some other tool) to see if the problem still occurs?

Also, have you looked at what actual bytes the truncated response  
ends with ie. is the server sending back something weird?

Best,

Mark

On 17 Nov 2008, at 11:29, Dave wrote:

> Hi All,
>
> Please see below for the history of this problem. Since then I have  
> some more information:
>
> I installed WireShark and recreated the problem. When I look at the  
> captured information, it looks as if the response is being sent and  
> received by server/client ok. It shows a number of TCP packets (TCP  
> Segment of a reassembled PDU) and then one block that shows as HTTP/ 
> XML. When I select this block it shows the packet reassembled as  
> 23782 bytes. However when the error occurs, the response return by  
> the RunRev post command only shows the first 2736 bytes, e.g. the  
> rest of the reassembled block is truncated. I have the dumps as  
> text files but they are too big to post here.
>
> When I looked up the post command in RunRev it says it is part of  
> the internet library, however I can't find any source code for  
> this. Is it available? I'd like to add some trace information so I  
> can see if this library is being passed the whole block and if so  
> why is it going wrong on this block.
>
> Is there another way to do this in RunRev? e.g. A alternative to  
> the "post" command?
>
> Any ideas or suggestions on how to fix or even get a handle of this  
> problem would be greatly appreciated.
>
> All the Best
> Dave
>
> ------
>
> I read records from a database, format them, and add them to a  
> block of data. There is a blocking factor variable, it is set to  
> 200, so I read 200 records from the database, block them into one  
> big block and send it to the server via a "post" command. The  
> Server then sends a response which can be variable in length, the  
> response is in XML format. This process works well 99% of the time,  
> but sometimes, (and this can be reproduced if the right data (or  
> the wrong data in this case!) is present in the database). When  
> this happens the response from the server is truncated in the  
> middle of an XML node. As far as I can tell the difference is that  
> by chance, a group of 200 records has caused the response to be  
> over a certain size.
>
> If I set the BlockingFactor to 50, the problem goes away, but this  
> causes a major slowdown.
>
> ------
>
> It is sending one block at a time, each block contains N records.  
> There are around 10,500 records in the database.
>
> Each record has an XML node in the reply, depending on the content  
> of the record sent, it will return different data of variable size.  
> It appears if the block returned is greater than a certain size, it  
> is truncated.
>
> Basically the process is:
>
> repeat for all Records in Database
> Read Record From Database
> Encode as XML
> Add to end of SendDataBlock
>
> if the number of records in SendDataBloack > SendBlockingFactor then
>   post SendDataBlock
>   get response
>   process response
>   put empty into SendDataBlock
> end if
>
> end repeat
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list