[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Change by pfreixes : -- keywords: +patch pull_requests: +7095 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: Yeps, any update on this bug and the fix proposed? -- ___ Python tracker ___

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: The Java client https://gist.github.com/pfreixes/13fedf2a589c260e6c7c64ae73653bb1 Works as is expected the buffer can be read till it gets empty, no matter when the RST was sent. -- ___ Python tracker

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Guido van Rossum added the comment: There's no need. You seem to have accidentally shown a use case for getting the buffered data -- it can contain an error message explaining why the connection was closed. -- ___ Python tracker

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: The following links point to three different implementations of the same scenario using a Twisted, Node and Python blocking clients that try to reproduce the same scenario. - Twisted https://gist.github.com/pfreixes/0d8b24b98567e557d6059b3308aa07ca - Node

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: fair enough. I'm out with few chances to grab a computer. I'll be back in a week with more information. El 07/07/2017 20:14, "Yury Selivanov" escribió: > > Yury Selivanov added the comment: > > I looked at the PR and it looks good. The

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Yury Selivanov added the comment: I looked at the PR and it looks good. The intent is also clear. But the idea of delaying exceptions in StreamReader read methods still feels finicky. To go forward with this we need more examples than just nodejs. And it doesn't really matter what trio and

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Guido van Rossum added the comment: IMO you haven't demonstrated a need, you are just complaining that you don't like it. -- ___ Python tracker ___

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: I would like to focus the issue as was initially described, Im still convinced that this is a buggy behaviour. As has been seen other systems such as python sync or nodejs behaves as is expected. This last one is IMHO something that can be skipped. Im wondering how

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Guido van Rossum added the comment: But half closed state is already supported. On Jul 7, 2017 2:37 AM, "Dima Tisnek" wrote: > > Dima Tisnek added the comment: > > It seems Guido sets a higher bar on the proposed change. > > @pfreixes, if you can show that this change

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Dima Tisnek added the comment: It seems Guido sets a higher bar on the proposed change. @pfreixes, if you can show that this change is needed to implement "TCP half-closed" state (i.e. when remote calls shutdown(SHUT_WR) after it's done sending data but continues to recv(), then local is

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: I think that we are not in the same page, the following snippet is a nodejs client that emulates the same: var net = require('net'); var sleep = require('sleep'); var client = new net.Socket(); client.connect(6379, '127.0.0.1', function() {

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Guido van Rossum added the comment: We seem to have a failure to communicate. I'm sure your example code "works", but you're not showing what's in the data it receives that is important for the app to read (your example just prints it). And surely your app should be robust even if the

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: As was said, the assumption here is the data that came to the buffer must be available. For example, the next snippet shows a Redis client that expects the data message plus the RST packet, where the redis-server was configured to accept max N connections, the

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Dima Tisnek added the comment: My 2c: Pau's concern seems valid, in a sense that stream should work like TCP. That's what most users would assume -- read out data until the end, only then you can see what the actual error was (socket closed, or timeout or hard error) However, I suspect the

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Guido van Rossum added the comment: The Redis example doesn't sound valid to me, as (IIUC) it closes the connection immediately? -- ___ Python tracker

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: One of the disadvantages with the Exception is that you are relying on how the events are being succeeded, and this is something that you can't predict. With just a different delay between the data and the RST packet and you might get the data in two different ways,

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Yury Selivanov added the comment: > But IMHO the example it's just that an example, if the connection at some point was not broken/closed/... and some data came into the buffer, this data should be put available for the user. In my experience, you never want to recover any data from broken

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

pfreixes added the comment: Yeps, I have an example related to Redis [1], the server warns that the connection will be closed because you reached out the maximum number of connections. But IMHO the example it's just that an example, if the connection at some point was not broken/closed/... and

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Guido van Rossum added the comment: Do you have a specific use case where it's important to access the remaining data? ISTM that this is happening when the connection is lost and then it shouldn't matter how much of the data you read or not -- the connection was broken before the remote side

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

Changes by pfreixes : -- pull_requests: +2664 ___ Python tracker ___ ___ Python-bugs-list

[issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption

New submission from pfreixes: Current implementation of StreamReader does not take care of the status of the buffer, once an exception has been set via `set_exception` any call to the read methods won't be able to get the missing data still pending to be processed. >From the point of view of