[ 
https://issues.apache.org/jira/browse/SOLR-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17927236#comment-17927236
 ] 

Chris M. Hostetter commented on SOLR-17351:
-------------------------------------------

Example...

{noformat}
   >     java.lang.AssertionError: ObjectTracker found 6 object(s) that were 
not released!!! [Input, Input, Input, Input, Input, Input]
   >     
org.eclipse.jetty.client.util.InputStreamResponseListener$Input:org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException:
 org.eclipse.jetty.client.util.InputStreamResponseListener$Input
   >            at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:54)
   >            at 
org.apache.solr.client.solrj.impl.Http2SolrClient$InputStreamReleaseTrackingResponseListener$ObjectReleaseTrackedInputStream.<init>(Http2SolrClient.java:1213)
   >            at 
org.apache.solr.client.solrj.impl.Http2SolrClient$InputStreamReleaseTrackingResponseListener.getInputStream(Http2SolrClient.java:1207)
   >            at 
org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:519)
   >            at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:260)
   >            at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:276)
   >            at 
org.apache.solr.filestore.DistribFileStore$FileInfo.fetchFileFromNodeAndPersist(DistribFileStore.java:192)
   >            at 
org.apache.solr.filestore.DistribFileStore.fetch(DistribFileStore.java:437)
   >            at 
org.apache.solr.filestore.ClusterFileStore.lambda$pullFileFromNode$5(ClusterFileStore.java:352)
   >            at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:212)
   >            at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
   >            at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
   >            at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:380)
   >            at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
   >            at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
   >            at java.base/java.lang.Thread.run(Thread.java:1583)
   > 
   >     
org.eclipse.jetty.client.util.InputStreamResponseListener$Input:org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException:
 org.eclipse.jetty.client.util.InputStreamResponseListener$Input
   >            at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:54)
   >            at 
org.apache.solr.client.solrj.impl.Http2SolrClient$InputStreamReleaseTrackingResponseListener$ObjectReleaseTrackedInputStream.<init>(Http2SolrClient.java:1213)
   >            at 
org.apache.solr.client.solrj.impl.Http2SolrClient$InputStreamReleaseTrackingResponseListener.getInputStream(Http2SolrClient.java:1207)
   >            at 
org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:519)
   >            at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:260)
   >            at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:276)
   >            at 
org.apache.solr.filestore.DistribFileStore$FileInfo.fetchFileFromNodeAndPersist(DistribFileStore.java:192)
   >            at 
org.apache.solr.filestore.DistribFileStore.fetch(DistribFileStore.java:437)
   >            at 
org.apache.solr.filestore.ClusterFileStore.lambda$pullFileFromNode$5(ClusterFileStore.java:352)
   >            at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:212)
   >            at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
   >            at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
   >            at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:380)
   >            at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
   >            at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
   >            at java.base/java.lang.Thread.run(Thread.java:1583)
...

{noformat}

> Cosmetic changes to v2 filestore "get file" API
> -----------------------------------------------
>
>                 Key: SOLR-17351
>                 URL: https://issues.apache.org/jira/browse/SOLR-17351
>             Project: Solr
>          Issue Type: Sub-task
>          Components: Package Manager, v2 API
>    Affects Versions: 9.6.1
>            Reporter: Jason Gerlowski
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Solr's filestore APIs fit well with the REST-ful design we're targeting with 
> our v2 APIs, with one large exception: the "get file" API current available 
> at {{GET /api/node/files/somePath.txt}}.  This API stands out for a few 
> reasons:
> 1. It uses a different path-prefix than all other filestore APIs.  (i.e. 
> {{/api/node/files}} instead of {{/api/cluster/files}})
> 2. It exposes 4 or 5 conceptually distinct operations. Obviously in the 
> "default" case it allows callers to retrieve filestore contents, but based on 
> query params it can instead:
>   - return filestore entry metadata (when {{meta=true}} is specified)
>   - instruct the receiving Solr node to pull a file from another node's 
> filestore and cache it locally (when {{getFrom=someOtherNode}} is specified)
>   - instruct the receiving Solr node to push its cached copy of a file out to 
> all other Solr nodes (when {{sync=true}} is specified)
> 3. Even in the default case of returning "raw" filestore contents, the API 
> can provide two different styles of response:
>   - if {{wt=json}} is specified Solr will take the filestore entry bytes, 
> attempt to stringify them, and then return a JSON object that uses this 
> string as the value for a "response" key.  It's unclear how this would work 
> for binary content 
>   - for all other values of "wt", the API will return the raw file content.
> We should reconsider this endpoint and see if it can't be massaged into being 
> more in line with our other v2 APIs.  Some cosmetic tweaks will go a long 
> way, but the biggest benefit is likely to come from breaking the endpoint up 
> into multiple distinct APIs.  In its current form, the API returns such a 
> variety of responses that it's hard to write client code for.  (I suspect 
> this is the main reason these "filestore" APIs were never made available in 
> SolrJ.)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to