| 2260
|
|
|
Jason Stephenson |
7 months ago
|
 |
|
| 2259
|
|
|
Jason Boyer |
7 months ago
|
|
|
| 2258
|
|
|
Jason Stephenson |
10 months ago
|
|
|
| 2257
|
|
|
Jason Boyer |
1 year ago
|
|
|
| 2256
|
|
|
Jason Stephenson |
1 year ago
|
|
|
| 2255
|
|
|
Jason Stephenson |
1 year ago
|
|
|
| 2254
|
|
|
Jason Stephenson |
1 year ago
|
|
|
| 2253
|
|
|
Jason Stephenson |
1 year ago
|
|
|
| 2252
|
|
|
Chris Sharp |
1 year ago
|
|
|
| 2251
|
|
|
Galen Charlton |
1 year ago
|
|
|
| 2250
|
|
LP#1970469: fix responses streamed out of order due to chunking
If a streaming method starts off sending a couple small responses
followed by a large one, the responses can end up received out of
order under this scenario:
- The initial small responses get stashed to be sent out as a bundle
- The large response, if big enough to require chunking, gets sent
out as a set of partial responses. However, any messages queued
up to go out as a bundle remain in the queue.
- When the method completes, or if further responses result in
exceeding the maximum bundle size, the queued messages get sent
_after_ the chunked response.
This affects services written in C and Perl.
To test
-------
C service
=========
[1] Add the following stored procedure to an Evergreen database:
CREATE OR REPLACE FUNCTION public.lp1970469_sample() RETURNS SETOF TEXT AS $$
BEGIN
RETURN NEXT 'abc';
RETURN NEXT 'def';
RETURN NEXT rpad('long', 65000, 'x');
RETURN NEXT 'xyz';
RETURN;
END;
$$ LANGUAGE PLPGSQL IMMUTABLE;
[2] Run the following srfsh command:
srfsh# open-ils.cstore open-ils.cstore.json_query.atomic {"from":["public.lp1970469_sample"]}
[3] Note that longxxxxx* response is returned first, followed by abc,
def, and xyz.
[4] Apply the patch and repeat step 2. This time, the responses should
be returned in the expected order.
Perl service
============
[1] In an Evergreen database, attach a couple hundred items to
a record.
[2] Run the following srfsh command:
srfsh# request open-ils.supercat open-ils.supercat.record.holdings_xml.retrieve BIBID, "-", null, 1
[3] If enough items were attached, the first response streamed will
start with a <volume> element rather than the <holdings> element
and the overall response will not be well-formed XML.
[4] Apply the patch and repeat step 2. This time, the parts of the
response should be in the expected order.
Note that this test scenario models an Evergreen glitch seen in the
wild that causes requests for
https://EGSERVER//opac/extras/supercat/retrieve/marcxml-full/record/BIBID
to fall if there are a lot of items attached to the bib.
Signed-off-by: Galen Charlton <gmc@equinoxOLI.org>
Signed-off-by: Mike Rylander <mrylander@gmail.com>
|
Galen Charlton |
1 year ago
|
|
|
| 2249
|
|
|
Bill Erickson |
2 years ago
|
|
|
| 2248
|
|
|
Jason Boyer |
2 years ago
|
|
|
| 2247
|
|
|
Galen Charlton |
2 years ago
|
|
|
| 2246
|
|
|
Jason Stephenson |
2 years ago
|
|
|
| 2245
|
|
|
Jason Boyer |
2 years ago
|
|
|
| 2244
|
|
|
Jason Boyer |
2 years ago
|
|
|
| 2243
|
|
|
Jason Boyer |
2 years ago
|
|
|
| 2242
|
|
|
kenstir |
2 years ago
|
|
|
| 2241
|
|
|
Jason Stephenson |
3 years ago
|
|
|
collapse all