Change #8440
Category | None |
Changed by | Galen Charlton <gmc | @equinoxOLI.org>
Changed at | Wed 27 Apr 2022 18:45:09 |
Repository | git://git.evergreen-ils.org/OpenSRF.git |
Project | OpenSRF |
Branch | master |
Revision | 42eddc6429a7768a573b5d51d5fed6f381a55cff |
Comments
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>
Changed files
- src/libopensrf/osrf_application.c
- src/perl/lib/OpenSRF/AppSession.pm