This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Retain 4.9.2 index optimization not running

Running retain 4.92, Windows 2019, DB is SQL Server 2017

This is a fairly new install for us (as of March 2021) We initially had 4.9.1 then upgraded to this version to address some 'bugs'.

I know the index optimization has ran in the past because I've seen a date on the Index Maintenance  indicating this (I believe it was manually last optimized in June?).

But now it jusy won't run . Under server configuration, Maintenance I have this configured

But when I check the index tab, it shows me the optimization hasn't run.


I try to manually start it, and looks like it runs, but a few minutes later it just returns to this screen and the date never gets updated.
I don't see anything in the logs indicating it's run either (if i"m looking in the right logs that is..the Retain server logs) 

Anyone else have this issue on this version?

  • 0  

    Same here, after upgrade to 4.9.2 index optimization stopped working.

    David

  • 0   in reply to   

    Mine is working, I use 4.9.2.0. But my Retain is based on SuSE.

    how much (free) disc space do have? Retain is telling you how much it needs for optimization ...


    Use "Verified Answers" if your problem/issue has been solved!

  • 0 in reply to   

    I have 742GB free. Index optimization says it will take 165 GB...

  • 0   in reply to 

    do you also have such space on your server's C:  

    just thinking if something was set to use a different location for the index optimization.  shouldn't but we know things like that get messed up.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    hi  Where would I find that ? Checking the storage tab under Server configuration in Retain shows that the index path is e:\Retain\index which is the index partition on the Server (742 GB free). C has 11GB free.

    Is there anywhere else this would be configured?

  • 0 in reply to   

    hi  Where would I find that ? Checking the storage tab under Server configuration in Retain shows that the index path is e:\Retain\index which is the index partition on the  retain server (742 GB free). C has 111 GB free.

    Is there anywhere else this would be configured?

  • 0   in reply to 

    I don't know of any other spot.  just not sure what your SQL engine does and it if makes any use of your C:     On the system I'm looking at, there are 18GB free on root for a system with an index about half the size of yours, running MySQL.      so possibly you might be tripping your C: being on the tight side, making a basic check if there is stuff that can be cleared up there might help.   So many issues can be fixed (or made easier to fix) just by doing some basic cleanup on any platform, especially on Windows.

    Have you looked at the indexer logs?    is it at least trying?  and if so what error messages is it kicking up.
    they would be in (as per TID 7019349)
    [drive]:\Program Files\Beginfinite\Retain\Tomcat [n]\logs  (where "n" is the Tomcat version).

    where I see Indexer.YYYY-MM-DD.log.zip for everyday

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    Thanks - I tried to manually run it twice this morning , to see what would happen and this is what I see in the logs (just copied it once, but the next instance when I ran produced the exact same errors:)

    08:06:57, 309[Thread-6706619] [ERROR] SolrCloudIndexingFunctions:
    org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: localhost:8081/.../0368173d-b6f5-4163-bb9a-5dc08b53505e_403
    at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1110) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:504) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:525) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    at com.gwava.indexing.solrcloud.impl.SolrCloudIndexingFunctions.optimizeIndex(SolrCloudIndexingFunctions.java:215) [retain-index-4.9.20.jar:?]
    at com.gwava.management.IndexOptimizer.run(IndexOptimizer.java:201) [classes/:?]
    at java.lang.Thread.run(Thread.java:834) [?:?]
    Caused by: java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method) ~[?:?]
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:115) ~[?:?]
    at java.net.SocketInputStream.read(SocketInputStream.java:168) ~[?:?]
    at java.net.SocketInputStream.read(SocketInputStream.java:140) ~[?:?]
    at sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:467) ~[?:?]
    at sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:461) ~[?:?]
    at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) ~[?:?]
    at sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1349) ~[?:?]
    at sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:958) ~[?:?]
    at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) ~[httpcore-4.4.13.jar:4.4.13]
    at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) ~[httpcore-4.4.13.jar:4.4.13]
    at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280) ~[httpcore-4.4.13.jar:4.4.13]
    at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) ~[httpcore-4.4.13.jar:4.4.13]
    at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) ~[httpcore-4.4.13.jar:4.4.13]
    at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) ~[httpcore-4.4.13.jar:4.4.13]
    at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) ~[httpcore-4.4.13.jar:4.4.13]
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56) ~[httpclient-4.5.12.jar:4.5.12]
    at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542) ~[solr-solrj-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:37:52]
    ... 13 more

  • 0   in reply to 

    what is the CPU and drive access doing at the time?  be watching TaskManager as you run it.

    is the system suddenly busy trying to respond when you launch the optimize or is that part of the server (localhost:8081/.../0368173d-b6f5-4163-bb9a-5dc08b53505e_403) just not awake?

    a test on that system is to try pointing a browser or telnet to localhost:8081 to see if you get any response, or do we have a conflicting definition of localhost.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    System seems to be ok when launching the indexing optimization.

    I can connect to that port on the retain server.

    I'm not sure if this even matters, but when I try to copy that https:// link (localhost:8081/.../0368173d-b6f5-4163-bb9a-5dc08b53505e_403) into the browser  on the retain server, this is what comes back in the browser.

    HTTP Status 404 – Not Found


    Type Status Report

    Message /hpi/0368173d-b6f5-4163-bb9a-5dc08b53505e_403

    Description The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.


    Apache Tomcat/9.0.33