Closed GoogleCodeExporter closed 9 years ago
As StreamSendAsync can be used to submit a batch request, it should parse into
a feed, not an entry.
That CreateAndParseFeed is not used looks like a typical case of "i searched
the whole service.cs file for that
usage pattern, but missed the one asyncservice.cs" to me.
Original comment by fman...@gmail.com
on 25 Nov 2009 at 10:22
I created a patch for this.
- Moved ParseFeed up in the AsyncData class.
- Chained all the constructors in the AsyncData hierarchy to remove code
duplication.
- Added StreamSendFeedAsync and StreamSendStreamAsync that call the private
StreamSendAsync with ParseFeed value
- Created a HandleResponseStream method, that gets the stream, and decides
whether to copy it into a memory stream,
or parse it into a feed. Puts the result in the AsyncData.
- Changed the AsyncStreamSendWorker and איק AsyncQueryWorker to use the
above HandleResponseStream.
- Created CopyResponseToMemory just to create the memory stream from the
resulting stream (not really needed, as
eventually it is only being called from one location)
Original comment by ATGard...@gmail.com
on 25 Nov 2009 at 10:52
Attachments:
Oopsy - didn't return the stream in case the StreamSendStreamAsync is called.
Need to change in asyncservice.cs line #86 - move the line out of the "if"
statement.
Will that be ok - returning the stream whether it is an AsyncQueryData or
AsyncSendData?
Original comment by ATGard...@gmail.com
on 25 Nov 2009 at 11:02
Maybe even simply
--------------------
uri = data.UriToUse;
feedObject = data.Feed;
stream = data.DataStream;
AsyncSendData sData = data as AsyncSendData;
if (sData != null)
{
entryObject = sData.Entry;
}
--------------------
The feed or stream can be null, all depending on how the response was handled.
Or maybe some code paths will result in both of them being not null?
Original comment by ATGard...@gmail.com
on 25 Nov 2009 at 11:06
You should not return the stream if you have a feed - this will only increase
likelyhood of memory leaks, and if
the feed was created, most likely the stream is useless (as not unwindable).
Original comment by fman...@gmail.com
on 25 Nov 2009 at 2:25
I changed the HandleResponseStream to
-----------------------
if (data.ParseFeed)
{
Tracing.TraceCall("Using Atom always.... ");
data.Feed = CreateAndParseFeed(responseStream, data.UriToUse);
data.DataStream = null;
}
else
{
data.DataStream = CopyResponseToMemory(data, responseStream, contentLength);
}
-----------------------
that way the data contains either a stream, or a feed.
Original comment by ATGard...@gmail.com
on 25 Nov 2009 at 2:43
Did you put those changes into the patch?
Frank Mantek
Original comment by fman...@gmail.com
on 30 Nov 2009 at 10:24
I will put that in the patch on Sunday, if you'd like.
Original comment by ATGard...@gmail.com
on 3 Dec 2009 at 6:20
Here is my fixed patch, with the HandleResponseStream and the AsyncData
construtor.
Original comment by ATGard...@gmail.com
on 6 Dec 2009 at 7:36
Attachments:
Thanks for the work. Applied, tested, and checked in.
Frank
Original comment by fman...@gmail.com
on 8 Dec 2009 at 1:43
This issue was closed by revision r963.
Original comment by fman...@gmail.com
on 8 Dec 2009 at 1:43
Original issue reported on code.google.com by
ATGard...@gmail.com
on 25 Nov 2009 at 9:32