From dev-return-356370-archive-asf-public=cust-asf.ponee.io@lucene.apache.org Tue May 21 04:27:21 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id E7E17180627 for ; Tue, 21 May 2019 06:27:20 +0200 (CEST) Received: (qmail 71788 invoked by uid 500); 21 May 2019 04:08:50 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 62494 invoked by uid 99); 21 May 2019 04:04:34 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2019 04:04:34 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id BEBE5E2D93 for ; Tue, 21 May 2019 04:04:25 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id A557025822 for ; Tue, 21 May 2019 04:04:25 +0000 (UTC) Date: Tue, 21 May 2019 04:04:25 +0000 (UTC) From: "Noble Paul (JIRA)" To: dev@lucene.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (SOLR-13471) exceptions during response writing can cause javabin to write a corrupt/missleading response that may caus exceptions or non-sense data when unmarshaled by javabin MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SOLR-13471?page=3Dcom.atlassian= .jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1684= 4486#comment-16844486 ]=20 Noble Paul commented on SOLR-13471: ----------------------------------- bq.Perhaps there should be a special "TAG" that means "Ignore everything yo= u've already recieved and start over" that we should emit at the begining o= f every marshal() call? I would refrain from this unless we see this same error being shown up else= where bq.in the specific case of this "Search is temporarily disabled" functional= ity... We should go down this route. If a search request comes in and we are in a = search disabled state, the request should "fail fast" > exceptions during response writing can cause javabin to write a corrupt/m= issleading response that may caus exceptions or non-sense data when unmarsh= aled by javabin > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------- > > Key: SOLR-13471 > URL: https://issues.apache.org/jira/browse/SOLR-13471 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public)=20 > Reporter: Hoss Man > Priority: Major > Attachments: SOLR-13471.patch, SOLR-13471.patch > > > Diagnoses/hypothosis summarized/re-worded from comment below... > https://issues.apache.org/jira/browse/SOLR-13471?focusedCommentId=3D16840= 999&page=3Dcom.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel= #comment-16840999 > * Assume request execution happens successfully > * then, when the QueryResponseWriter goes to marshal the response, assume= there is some exception writing the results -- perhaps due to the Resolver= w/ ResultContext + Searcher (could be an IOException) > ** the Exception from attempting to write the response may propogate all = the way up to the "try" in HttpSolrCall.call() ... which once caught is the= n passed to "sendError" > ** sendError creates a completely new SolrQueryResponse, sets the excepti= on on it, and asks the QueryResponseWriter to write it out > *** *BUT* the OutputStream has already had a bunch of data written to it = ... which may be resulting in a byte sequence that confuses the unmarshal c= ode and may result in weird exceptions -- *or worse: validly structured, bu= t corrupt data* > The fundemental problem is that when HttpSolrCall to "start over" writtng= the response =E2=80=93 but the JavaBinCodec doesn't have any way to recogn= ize that ... it can read partial data and then be confused by the "new" dat= a that comes after it > *Perhaps there should be a special "TAG" that means "Ignore everything yo= u've already recieved and start over" that we should emit at the begining o= f every marshal() call?* > ---- > Original bug report > {panel} > I haven't dug into this, or been able to reproduce it (let alone get any = additional logging/debugging/breakpoint info) but in a few very sporadic, v= ery rare, instances of running TestReplicationHandlerDiskOverFlow, I trigge= red ClassCastException's in JavaBinCodec unmarshal code -- indicating that = there is some disconnect in expectations between the marshal & unmarshal co= de paths... > {noformat} > [junit4] 2> 13342 ERROR (Thread-19) [ ] o.a.s.h.TestReplicationHa= ndlerDiskOverFlow Query Thread Failure > [junit4] 2> =3D> org.apache.solr.client.solrj.impl.HttpSol= rClient$RemoteSolrException: Error from server at http://127.0.0.1:54505/so= lr/collection1: class java.lang.Boolean cannot be cast to class java.lang.S= tring (java.lang.Boolean and java.lang.String are in module java.base of lo= ader 'bootstrap') > [junit4] 2> =09at org.apache.solr.client.solrj.impl.HttpSolrClient.e= xecuteMethod(HttpSolrClient.java:622) > [junit4] 2> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteS= olrException: Error from server at http://127.0.0.1:54505/solr/collection1:= class java.lang.Boolean cannot be cast to class java.lang.String (java.lan= g.Boolean and java.lang.String are in module java.base of loader 'bootstrap= ') > [junit4] 2> =09at org.apache.solr.client.solrj.impl.HttpSolrClient.e= xecuteMethod(HttpSolrClient.java:622) ~[java/:?] > [junit4] 2> =09at org.apache.solr.client.solrj.impl.HttpSolrClient.r= equest(HttpSolrClient.java:255) ~[java/:?] > [junit4] 2> =09at org.apache.solr.client.solrj.impl.HttpSolrClient.r= equest(HttpSolrClient.java:244) ~[java/:?] > [junit4] 2> =09at org.apache.solr.client.solrj.SolrRequest.process(S= olrRequest.java:207) ~[java/:?] > [junit4] 2> =09at org.apache.solr.client.solrj.SolrClient.query(Solr= Client.java:987) ~[java/:?] > [junit4] 2> =09at org.apache.solr.client.solrj.SolrClient.query(Solr= Client.java:1002) ~[java/:?] > [junit4] 2> =09at org.apache.solr.handler.TestReplicationHandlerDisk= OverFlow.lambda$testDiskOverFlow$1(TestReplicationHandlerDiskOverFlow.java:= 154) ~[test/:?] > [junit4] 2> =09at java.lang.Thread.run(Thread.java:834) [?:?] > [junit4] 2> Caused by: java.lang.ClassCastException: class java.lang= .Boolean cannot be cast to class java.lang.String (java.lang.Boolean and ja= va.lang.String are in module java.base of loader 'bootstrap') > [junit4] 2> =09at org.apache.solr.common.util.JavaBinCodec.readOrder= edMap(JavaBinCodec.java:223) ~[java/:?] > [junit4] 2> =09at org.apache.solr.common.util.JavaBinCodec.readObjec= t(JavaBinCodec.java:298) ~[java/:?] > [junit4] 2> =09at org.apache.solr.common.util.JavaBinCodec.readVal(J= avaBinCodec.java:280) ~[java/:?] > [junit4] 2> =09at org.apache.solr.common.util.JavaBinCodec.unmarshal= (JavaBinCodec.java:193) ~[java/:?] > [junit4] 2> =09at org.apache.solr.client.solrj.impl.BinaryResponsePa= rser.processResponse(BinaryResponseParser.java:50) ~[java/:?] > [junit4] 2> =09at org.apache.solr.client.solrj.impl.HttpSolrClient.e= xecuteMethod(HttpSolrClient.java:620) ~[java/:?] > [junit4] 2> =09... 7 more > =20 > {noformat} > It's possible that something about the test code (or code being tested) i= s doing something it should not be doing, and adding something "unexpeted" = to the response object -- but either the unmarshal code needs to be _as for= giving_ as marshal code, or the marshal code should fail fast -- not produc= e a binary stream that the unmarshal code can't parse. > {panel} -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org