[
https://issues.apache.org/jira/browse/TIKA-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104165#comment-18104165
]
Hudson commented on TIKA-4804:
------------------------------
SUCCESS: Integrated in Jenkins build Tika ยป tika-main-jdk17 #1535 (See
[https://ci-builds.apache.org/job/Tika/job/tika-main-jdk17/1535/])
TIKA-4804: complete the call in fetchAndParseServerSideStreaming (#3008)
(github:
[https://github.com/apache/tika/commit/84dd8827a234554cf9e503bdb583468c7379a6c9])
* (edit)
tika-grpc/src/test/java/org/apache/tika/pipes/grpc/TikaGrpcServerTest.java
* (edit)
tika-grpc/src/main/java/org/apache/tika/pipes/grpc/TikaGrpcServerImpl.java
* (edit) CHANGES.txt
> tika-grpc: fetchAndParseServerSideStreaming never sends a terminal signal
> --------------------------------------------------------------------------
>
> Key: TIKA-4804
> URL: https://issues.apache.org/jira/browse/TIKA-4804
> Project: Tika
> Issue Type: Bug
> Components: tika-pipes
> Affects Versions: 3.0.0, 4.0.0
> Reporter: Davide Polato
> Priority: Major
> Labels: grpc, pipes
> Attachments: TerminalSignalLocalDiagnostic.java
>
>
> h3. Summary
> {{TikaGrpc.fetchAndParseServerSideStreaming}} delivers its reply and then
> never
> closes the call. This happens on the success path, not only on error. gRPC
> does
> not close a call when the handler returns: for a server-streaming method the
> server must call {{onCompleted()}}, and this handler never does.
> The client sees one message and then waits until its deadline, or forever if
> it
> set none. Each call also leaves server-side call state alive.
> h3. Where
> {{TikaGrpcServerImpl.fetchAndParseServerSideStreaming}} calls
> {{fetchAndParseImpl}} and returns. {{fetchAndParseImpl}} calls only
> {{onNext(...)}}.
> For contrast, in the same class:
> * unary {{fetchAndParse}} calls {{fetchAndParseImpl}} and then
> {{onCompleted()}} -- correct
> * {{fetchAndParseBiDirectionalStreaming}} forwards the client's
> {{onCompleted}} -- correct
> Only the server-streaming variant is missing the terminal signal.
> h3. Affected versions
> Present in every released version that ships tika-grpc: 3.0.0, 3.0.0-BETA2,
> 3.1.0, 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.3.0, 3.3.1, 3.3.2, and the 4.0.0 alpha
> and
> beta tags. The handler has had this shape since the RPC was introduced.
> h3. Reproduction
> Attached: TerminalSignalLocalDiagnostic.java. Drop it into
> tika-grpc/src/test/java/org/apache/tika/pipes/grpc/ and run
> {noformat}
> mvn -pl tika-grpc test -Dtest=TerminalSignalLocalDiagnostic
> {noformat}
> It fetches one real file through an in-process server with an async stub and
> waits up to 10 seconds for a terminal signal on four RPCs:
> {noformat}
> v1 fetchAndParse (unary) messages=1 terminal=YES onCompleted
> v1 fetchAndParseServerSideStreaming messages=1 terminal=NO -- HUNG
> v2 fetchAndParse (unary) messages=1 terminal=YES onCompleted
> v2 fetchAndParseServerSideStreaming messages=1 terminal=NO -- HUNG
> sanity fetch status = PARSE_SUCCESS
> {noformat}
> The test then fails in GrpcCleanupExtension with
> {noformat}
> PostconditionViolationException: One or more Resources couldn't be released
> {noformat}
> because those two calls are still open. That failure is part of the finding,
> not
> noise: two independent signals, one cause.
> h3. Scope notes
> * Measured against 4.0.0-SNAPSHOT. The 3.x handlers are structurally
> identical,
> so the same result is expected there, but I have not executed the probe
> against
> a 3.x build.
> * The v2 experimental service (TIKA-4766) inherits the shape from v1. Fixing
> v1
> does not automatically fix v2; both need the terminal signal.
> * Found while working on TIKA-4795. Unrelated to that ticket's feature and
> independent of it.
> h3. Fix
> One line per handler: call {{responseObserver.onCompleted()}} after
> {{fetchAndParseImpl}}, matching what the unary handler already does. Happy to
> put up a patch with a regression test if that is wanted -- the probe above
> turns
> into one directly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
