Files locked after indexing
Asked Answered
A

2

6

I have the following workflow in my (web)application:

  • download a pdf file from an archive
  • index the file
  • delete the file

My problem is that after indexing the file, it remains locked and the delete-part throws an exception.

Here is my code-snippet for indexing the file:

try
{
   ContentStreamUpdateRequest req = new ContentStreamUpdateRequest("/update/extract");
   req.addFile(file, type);
   req.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true);

   NamedList<Object> result = server.request(req);

   Assert.assertEquals(0, ((NamedList<?>) result.get("responseHeader")).get("status"));
}

Do I miss something?

EDIT:

I tried this way too, but with the same result...

ContentStream contentStream = null;

    try
    {
      contentStream = new ContentStreamBase.FileStream(document);

      ContentStreamUpdateRequest req = new ContentStreamUpdateRequest(UPDATE_EXTRACT_REQUEST);
//      req.addFile(document, context.getProperty(FTSConstants.CONTENT_TYPE_APPLICATION_PDF));
      req.addContentStream(contentStream);
      req.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true);

      NamedList<Object> result = server.request(req);

      if (!((NamedList<?>) result.get("responseHeader")).get("status").equals(0))
      {
        throw new IDSystemException(LOG, "Document could not be indexed. Status returned: " +
                                         ((NamedList<?>) result.get("responseHeader")).get("status"));
      }
    }
    catch (FileNotFoundException fnfe)
    {
      throw new IDSystemException(LOG, fnfe.getMessage(), fnfe);
    }
    catch (IOException ioe)
    {
      throw new IDSystemException(LOG, ioe.getMessage(), ioe);
    }
    catch (SolrServerException sse)
    {
      throw new IDSystemException(LOG, sse.getMessage(), sse);
    }
    finally
    {
      try
      {
        if(contentStream != null && contentStream.getStream() != null)
        {
          contentStream.getStream().close();
        }
      }
      catch (IOException ioe)
      {
        throw new IDSystemException(LOG, ioe.getMessage(), ioe);
      }
    }
Alemannic answered 26/2, 2014 at 8:33 Comment(0)
L
3

This seems like a bug,

a patch is proposed here https://issues.apache.org/jira/browse/SOLR-1744

Also checkout http://lucene.472066.n3.nabble.com/ContentStreamUpdateRequest-addFile-fails-to-close-Stream-td485429.html

you can check if the stream is not null and close it.

Lisbethlisbon answered 7/3, 2014 at 3:54 Comment(3)
The bug is old and marked as closed fixed already for versions 1.4.1, 1.5, 3.1, 4.0-ALPHA (I'm using 4.6.0), but it seams, at least for me, that it isn't. I opened another issue. What astonishes me, is that nobody else reported this problem...Alemannic
In the meanwhile I adopted the solution in the second link and that fixed the problem. I hope the guys will look anyway at the problem (I opened a JIRA too).Alemannic
Maybe the bug for patch they did in older version didn't get carried over to the latest version.Lisbethlisbon
D
3

It may be due to lock acquired by file system. Instead of addFile(), you can try the following.

ContentStreamUpdateRequest req = new ContentStreamUpdateRequest("/update/extract");
ContentStreamBase.FileStream fileStream = new FileStream(file);
req.addContentStream(fileStream);

Shishir

Dorey answered 28/2, 2014 at 13:59 Comment(1)
I tried this possibility too, but with the same result... (see edit in question)Alemannic
L
3

This seems like a bug,

a patch is proposed here https://issues.apache.org/jira/browse/SOLR-1744

Also checkout http://lucene.472066.n3.nabble.com/ContentStreamUpdateRequest-addFile-fails-to-close-Stream-td485429.html

you can check if the stream is not null and close it.

Lisbethlisbon answered 7/3, 2014 at 3:54 Comment(3)
The bug is old and marked as closed fixed already for versions 1.4.1, 1.5, 3.1, 4.0-ALPHA (I'm using 4.6.0), but it seams, at least for me, that it isn't. I opened another issue. What astonishes me, is that nobody else reported this problem...Alemannic
In the meanwhile I adopted the solution in the second link and that fixed the problem. I hope the guys will look anyway at the problem (I opened a JIRA too).Alemannic
Maybe the bug for patch they did in older version didn't get carried over to the latest version.Lisbethlisbon

© 2022 - 2024 — McMap. All rights reserved.