[jira] [Commented] (SOLR-11361) After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing?
[ https://issues.apache.org/jira/browse/SOLR-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239148#comment-16239148 ] Richard Rominger commented on SOLR-11361: - Best that I can tell, this is no longer happening with Solr 6.6.2 > After Restarting Solr 6.6.1 Seems to cause Error if Application is > Reading/Writing? > --- > > Key: SOLR-11361 > URL: https://issues.apache.org/jira/browse/SOLR-11361 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 > Environment: Windows 10 VM >Reporter: Richard Rominger >Priority: Major > Labels: newbie, upgrade, windows > > I have just updated from Solr 6.2.1 to 6.6.1. I put into place a fresh 6.6.1 > and mounted our Core (umslogs). This loaded perfectly fine on port 8181 and > our application is able to write/read data. > The problem started when I restart Solr 6.6.1 and the below error appeared > after Solr 6.6.1 came up accessible via the web page. > > *HttpSolrCall > null:org.apache.solr.core.SolrCoreInitializationException: SolrCore 'umslogs' > is not available due to init failure: null * > Next my testing lead me to start up Solr on port 8282 that no application is > connecting/reading/writing to. On this test umslogs core loads is perfectly > fine after erroring above. > Next my testing lead me to close +our application+ that writes/reads to Solr > 8181umslogs core and shutdown Solr 8282 umslogs core. Then I restarted > Solr back on Poret 8181 and the umslogs core loads properly and our > application that that writes/reads to Solr 8181 is once again operational. > Our application has used Solr 4.10.x, then Solr 6.2.x okay. Then again I do > not doubt that I might have done something wrong with the 6.6.1 upgrade that > is causing the above behavior -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179704#comment-16179704 ] Richard Rominger edited comment on SOLR-11297 at 9/25/17 8:22 PM: -- I meant in 6.6.1 (which would spawn 6.6.2?) - which was the next version I wanted to test and where I ran into problems. was (Author: odie3): I meant in 6.6.2 - which was the next version I wanted to test and where I ran into problems. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Fix For: 7.1 > > Attachments: SOLR-11297.patch, SOLR-11297.patch, SOLR-11297.patch, > SOLR-11297.sh, solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. > One critical detail to this issue: The cores are all perfectly functional. > If somebody is seeing an error message that results in a core not working at > all, then it is likely a different issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179704#comment-16179704 ] Richard Rominger commented on SOLR-11297: - I meant in 6.6.2 - which was the next version I wanted to test and where I ran into problems. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Fix For: 7.1 > > Attachments: SOLR-11297.patch, SOLR-11297.patch, SOLR-11297.patch, > SOLR-11297.sh, solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. > One critical detail to this issue: The cores are all perfectly functional. > If somebody is seeing an error message that results in a core not working at > all, then it is likely a different issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176841#comment-16176841 ] Richard Rominger commented on SOLR-11297: - so, all this stuff about patching is this in a Solr 6.1.x download? > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: SOLR-11297.patch, SOLR-11297.patch, SOLR-11297.sh, > solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172156#comment-16172156 ] Richard Rominger edited comment on SOLR-11297 at 9/19/17 6:44 PM: -- So it's possible my SOLR-11361 is a real issue? That Jan fellow made me feel a little dumb, though to be honest I likely did not write up my issue properly (as it was my 1st one here on this site). was (Author: odie3): So it's possible my SOLR-11361 is a real issue? That Ian fellow made me feel a little dumb, though to be honest I likely did not write up my issue properly (as it was my 1st one here on this site). > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: SOLR-11297.patch, SOLR-11297.sh, solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172156#comment-16172156 ] Richard Rominger commented on SOLR-11297: - So it's possible my SOLR-11361 is a real issue? That Ian fellow made me feel a little dumb, though to be honest I likely did not write up my issue properly (as it was my 1st one here on this site). > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: SOLR-11297.patch, SOLR-11297.sh, solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170429#comment-16170429 ] Richard Rominger commented on SOLR-11297: - agreed. 6.6.0 seems to load my core okay - even though WebGUI has [Red] Fault errors for me. Which that is enough for me not to use 6.6.0 as a Production candidate. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170333#comment-16170333 ] Richard Rominger commented on SOLR-11297: - I can say for my test bed using 6.6.0 / 6.6.1 it's pretty reproducible. I am running Windows 10 1703 for my testing. I go back to 6.2.1 and it stable as a rock. When the problem kicks in, all I have to do is shutdown Solr and restart it on a different port and it loads up fine. Then I shutdown for a bit of time and I can then restart on the port that I really want Solr running on. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11361) After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing?
[ https://issues.apache.org/jira/browse/SOLR-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169937#comment-16169937 ] Richard Rominger commented on SOLR-11361: - I've done that after the fact but then found my issue was already reported and being looked into by Erick Erickson in SOLR-11297. So I think there is more than a question but a issue going on here but regardless this SOLR-11361 at best a duplicate. > After Restarting Solr 6.6.1 Seems to cause Error if Application is > Reading/Writing? > --- > > Key: SOLR-11361 > URL: https://issues.apache.org/jira/browse/SOLR-11361 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 > Environment: Windows 10 VM >Reporter: Richard Rominger > Labels: newbie, upgrade, windows > > I have just updated from Solr 6.2.1 to 6.6.1. I put into place a fresh 6.6.1 > and mounted our Core (umslogs). This loaded perfectly fine on port 8181 and > our application is able to write/read data. > The problem started when I restart Solr 6.6.1 and the below error appeared > after Solr 6.6.1 came up accessible via the web page. > > *HttpSolrCall > null:org.apache.solr.core.SolrCoreInitializationException: SolrCore 'umslogs' > is not available due to init failure: null * > Next my testing lead me to start up Solr on port 8282 that no application is > connecting/reading/writing to. On this test umslogs core loads is perfectly > fine after erroring above. > Next my testing lead me to close +our application+ that writes/reads to Solr > 8181umslogs core and shutdown Solr 8282 umslogs core. Then I restarted > Solr back on Poret 8181 and the umslogs core loads properly and our > application that that writes/reads to Solr 8181 is once again operational. > Our application has used Solr 4.10.x, then Solr 6.2.x okay. Then again I do > not doubt that I might have done something wrong with the 6.6.1 upgrade that > is causing the above behavior -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169349#comment-16169349 ] Richard Rominger commented on SOLR-11297: - I think my issue ( https://issues.apache.org/jira/browse/SOLR-11361 ) is basically a duplicate of this reported issue. In my testing I can shut my Solr/Core down (I only have one) and then bring it up on a new port number and there are no locking errors. If I close Solr/Core again and go to the original port number the lock error is back. Lastly, I think if I just close Solr/Core and wait a fair amount of time, the lock error goes away. I updated from 6.2.1 to 6.6.1 last night (and long ago on 4.10 before that). I then moved down to 6.6.0 and while I get the lock error, the core is operational (6.6.1 is will not even show in the drop down for cores once the lock error kicks in). > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11361) After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing?
[ https://issues.apache.org/jira/browse/SOLR-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169325#comment-16169325 ] Richard Rominger edited comment on SOLR-11361 at 9/17/17 4:16 PM: -- I just went and grabbed Solr 6.6.0 and unpacked it. Then I copied my umslog core from 6.6.1 and ran the same tests. The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 For the record, I am running from Windows Command Line just using the -p 8181 or 8282 argument. Is this because of this error *Lock held by this virtual machine:*. After a bit of time Solr 6.6.0 had the same error but the Core was still operational. I stop 8181, move to port 8282 and there are no hard errors listed. I move back to 8181 and the error is back. Lastly I shut down Solr and just wait 30 minutes (perhaps more was not really counting) and 8181 comes up with no hard errors. was (Author: odie3): I just went and grabbed Solr 6.6.0 and unpacked it. Then I copied my umslog core from 6.6.1 and ran the same tests. The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 For the record, I am running from Windows Command Line just using the -p 8080 argument. Is this because of this error *Lock held by this virtual machine:*. After a bit of time Solr 6.6.0 had the same error but the Core was still operational. I stop 8181, move to port 8282 and there are no hard errors listed. I move back to 8181 and the error is back. Lastly I shut down Solr and just wait 30 minutes (perhaps more was not really counting) and 8181 comes up with no hard errors. > After Restarting Solr 6.6.1 Seems to cause Error if Application is > Reading/Writing? > --- > > Key: SOLR-11361 > URL: https://issues.apache.org/jira/browse/SOLR-11361 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 > Environment: Windows 10 VM >Reporter: Richard Rominger > Labels: newbie, upgrade, windows > > I have just updated from Solr 6.2.1 to 6.6.1. I put into place a fresh 6.6.1 > and mounted our Core (umslogs). This loaded perfectly fine on port 8181 and > our application is able to write/read data. > The problem started when I restart Solr 6.6.1 and the below error appeared > after Solr 6.6.1 came up accessible via the web page. > > *HttpSolrCall > null:org.apache.solr.core.SolrCoreInitializationException: SolrCore 'umslogs' > is not available due to init failure: null * > Next my testing lead me to start up Solr on port 8282 that no application is > connecting/reading/writing to. On this test umslogs core loads is perfectly > fine after erroring above. > Next my testing lead me to close +our application+ that writes/reads to Solr > 8181umslogs core and shutdown Solr 8282 umslogs core. Then I restarted > Solr back on Poret 8181 and the umslogs core loads properly and our > application that that writes/reads to Solr 8181 is once again operational. > Our application has used Solr 4.10.x, then Solr 6.2.x okay. Then again I do > not doubt that I might have done something wrong with the 6.6.1 upgrade that > is causing the above behavior -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11361) After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing?
[ https://issues.apache.org/jira/browse/SOLR-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169325#comment-16169325 ] Richard Rominger edited comment on SOLR-11361 at 9/17/17 4:15 PM: -- I just went and grabbed Solr 6.6.0 and unpacked it. Then I copied my umslog core from 6.6.1 and ran the same tests. The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 For the record, I am running from Windows Command Line just using the -p 8080 argument. Is this because of this error *Lock held by this virtual machine:*. After a bit of time Solr 6.6.0 had the same error but the Core was still operational. I stop 8181, move to port 8282 and there are no hard errors listed. I move back to 8181 and the error is back. Lastly I shut down Solr and just wait 30 minutes (perhaps more was not really counting) and 8181 comes up with no hard errors. was (Author: odie3): I just went and grabbed Solr 6.6.0 and unpacked it. Then I copied my umslog core from 6.6.1 and ran the same tests. The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 For the record, I am running from Windows Command Line just using the -p 8080 argument. > After Restarting Solr 6.6.1 Seems to cause Error if Application is > Reading/Writing? > --- > > Key: SOLR-11361 > URL: https://issues.apache.org/jira/browse/SOLR-11361 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 > Environment: Windows 10 VM >Reporter: Richard Rominger > Labels: newbie, upgrade, windows > > I have just updated from Solr 6.2.1 to 6.6.1. I put into place a fresh 6.6.1 > and mounted our Core (umslogs). This loaded perfectly fine on port 8181 and > our application is able to write/read data. > The problem started when I restart Solr 6.6.1 and the below error appeared > after Solr 6.6.1 came up accessible via the web page. > > *HttpSolrCall > null:org.apache.solr.core.SolrCoreInitializationException: SolrCore 'umslogs' > is not available due to init failure: null * > Next my testing lead me to start up Solr on port 8282 that no application is > connecting/reading/writing to. On this test umslogs core loads is perfectly > fine after erroring above. > Next my testing lead me to close +our application+ that writes/reads to Solr > 8181umslogs core and shutdown Solr 8282 umslogs core. Then I restarted > Solr back on Poret 8181 and the umslogs core loads properly and our > application that that writes/reads to Solr 8181 is once again operational. > Our application has used Solr 4.10.x, then Solr 6.2.x okay. Then again I do > not doubt that I might have done something wrong with the 6.6.1 upgrade that > is causing the above behavior -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11361) After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing?
[ https://issues.apache.org/jira/browse/SOLR-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169325#comment-16169325 ] Richard Rominger edited comment on SOLR-11361 at 9/17/17 3:37 PM: -- I just went and grabbed Solr 6.6.0 and unpacked it. Then I copied my umslog core from 6.6.1 and ran the same tests. The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 For the record, I am running from Windows Command Line just using the -p 8080 argument. was (Author: odie3): I just went and grabbed Solr 6.6.0 and unpacked. Then I copied my umslog core from 6.6.1 and ran the same tests. The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 > After Restarting Solr 6.6.1 Seems to cause Error if Application is > Reading/Writing? > --- > > Key: SOLR-11361 > URL: https://issues.apache.org/jira/browse/SOLR-11361 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 > Environment: Windows 10 VM >Reporter: Richard Rominger > Labels: newbie, upgrade, windows > > I have just updated from Solr 6.2.1 to 6.6.1. I put into place a fresh 6.6.1 > and mounted our Core (umslogs). This loaded perfectly fine on port 8181 and > our application is able to write/read data. > The problem started when I restart Solr 6.6.1 and the below error appeared > after Solr 6.6.1 came up accessible via the web page. > > *HttpSolrCall > null:org.apache.solr.core.SolrCoreInitializationException: SolrCore 'umslogs' > is not available due to init failure: null * > Next my testing lead me to start up Solr on port 8282 that no application is > connecting/reading/writing to. On this test umslogs core loads is perfectly > fine after erroring above. > Next my testing lead me to close +our application+ that writes/reads to Solr > 8181umslogs core and shutdown Solr 8282 umslogs core. Then I restarted > Solr back on Poret 8181 and the umslogs core loads properly and our > application that that writes/reads to Solr 8181 is once again operational. > Our application has used Solr 4.10.x, then Solr 6.2.x okay. Then again I do > not doubt that I might have done something wrong with the 6.6.1 upgrade that > is causing the above behavior -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11361) After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing?
[ https://issues.apache.org/jira/browse/SOLR-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169325#comment-16169325 ] Richard Rominger commented on SOLR-11361: - I just went and grabbed Solr 6.6.0 and unpacked. Then I copied my umslog core from 6.6.1 and ran the same tests. The problem that I am seeing in v6.6.1 does not appear to happen in v6.6.0 > After Restarting Solr 6.6.1 Seems to cause Error if Application is > Reading/Writing? > --- > > Key: SOLR-11361 > URL: https://issues.apache.org/jira/browse/SOLR-11361 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 > Environment: Windows 10 VM >Reporter: Richard Rominger > Labels: newbie, upgrade, windows > > I have just updated from Solr 6.2.1 to 6.6.1. I put into place a fresh 6.6.1 > and mounted our Core (umslogs). This loaded perfectly fine on port 8181 and > our application is able to write/read data. > The problem started when I restart Solr 6.6.1 and the below error appeared > after Solr 6.6.1 came up accessible via the web page. > > *HttpSolrCall > null:org.apache.solr.core.SolrCoreInitializationException: SolrCore 'umslogs' > is not available due to init failure: null * > Next my testing lead me to start up Solr on port 8282 that no application is > connecting/reading/writing to. On this test umslogs core loads is perfectly > fine after erroring above. > Next my testing lead me to close +our application+ that writes/reads to Solr > 8181umslogs core and shutdown Solr 8282 umslogs core. Then I restarted > Solr back on Poret 8181 and the umslogs core loads properly and our > application that that writes/reads to Solr 8181 is once again operational. > Our application has used Solr 4.10.x, then Solr 6.2.x okay. Then again I do > not doubt that I might have done something wrong with the 6.6.1 upgrade that > is causing the above behavior -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11361) After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing?
Richard Rominger created SOLR-11361: --- Summary: After Restarting Solr 6.6.1 Seems to cause Error if Application is Reading/Writing? Key: SOLR-11361 URL: https://issues.apache.org/jira/browse/SOLR-11361 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.6.1 Environment: Windows 10 VM Reporter: Richard Rominger I have just updated from Solr 6.2.1 to 6.6.1. I put into place a fresh 6.6.1 and mounted our Core (umslogs). This loaded perfectly fine on port 8181 and our application is able to write/read data. The problem started when I restart Solr 6.6.1 and the below error appeared after Solr 6.6.1 came up accessible via the web page. *HttpSolrCall null:org.apache.solr.core.SolrCoreInitializationException: SolrCore 'umslogs' is not available due to init failure: null * Next my testing lead me to start up Solr on port 8282 that no application is connecting/reading/writing to. On this test umslogs core loads is perfectly fine after erroring above. Next my testing lead me to close +our application+ that writes/reads to Solr 8181umslogs core and shutdown Solr 8282 umslogs core. Then I restarted Solr back on Poret 8181 and the umslogs core loads properly and our application that that writes/reads to Solr 8181 is once again operational. Our application has used Solr 4.10.x, then Solr 6.2.x okay. Then again I do not doubt that I might have done something wrong with the 6.6.1 upgrade that is causing the above behavior -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
