Background: Our YouTrack database got corrupted. The relevant bug report is here: https://youtrack.jetbrains.com/issue/JT-48235#comment=27-2952375 Now I'm trying to fix the corrupted state of the Xodus database that YouTrack uses internally.
Problem: The database contains entities that have links to deleted entities. My question is: How do I delete or repair these broken links?
After shutting down YouTrack I used Xodus Entity Browser to inspect the database.
I came up with two possible solutions:
Recreate the deleted Entity. In my case that was Sprint[86-191]. This did not work because creating a new Entity did not allow me to choose the number 191 again. Instead it created Sprint[86-208].
Remove the broken link. Did not work because in order to remove the link, Xodus expects consistency of the database resulting in the following stack trace:
jetbrains.xodus.browser.web.EntityNotFoundException: jetbrains.exodus.entitystore.EntityRemovedInDatabaseException: Sprint was removed.
at jetbrains.xodus.browser.web.db.StoreService.getEntity(StoreService.kt:204) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreService.access$getEntity(StoreService.kt:14) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreService$getEntity$1.invoke(StoreService.kt:168) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreService$getEntity$1.invoke(StoreService.kt:14) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreServiceKt$transactional$1.compute(StoreService.kt:229) ~[xodus-entity-browser.jar:na]
at jetbrains.exodus.entitystore.PersistentEntityStoreImpl.computeInTransaction(PersistentEntityStoreImpl.java:596) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreServiceKt.transactional(StoreService.kt:229) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreService.transactional(StoreService.kt:218) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreService.getEntity(StoreService.kt:167) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.resources.Entities$registerRouting$1$2.invoke(Entities.kt:37) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.resources.Entities$registerRouting$1$2.invoke(Entities.kt:10) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.WebConfigKt$safeGet$1.invoke(WebConfig.kt:61) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.WebConfigKt$safeGet$1.invoke(WebConfig.kt) ~[xodus-entity-browser.jar:na]
at spark.kotlin.Http$get$1.handle(Http.kt:560) ~[xodus-entity-browser.jar:na]
at spark.RouteImpl$1.handle(RouteImpl.java:72) ~[xodus-entity-browser.jar:na]
at spark.http.matching.Routes.execute(Routes.java:61) ~[xodus-entity-browser.jar:na]
at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:130) ~[xodus-entity-browser.jar:na]
at spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1568) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.server.Server.handle(Server.java:564) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:317) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:128) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.util.thread.Invocable$InvocableExecutor.invoke(Invocable.java:222) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:294) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:199) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:673) [xodus-entity-browser.jar:na]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:591) [xodus-entity-browser.jar:na]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_171]
Caused by: jetbrains.exodus.entitystore.EntityRemovedInDatabaseException: Sprint was removed.
at jetbrains.exodus.entitystore.PersistentStoreTransaction.getEntity(PersistentStoreTransaction.java:276) ~[xodus-entity-browser.jar:na]
at jetbrains.xodus.browser.web.db.StoreService.getEntity(StoreService.kt:201) ~[xodus-entity-browser.jar:na]
... 33 common frames omitted
Is there a way to solve this corrupted state?
Start YouTrack with the java parameter -Dexodus.entityStore.refactoring.heavyLinks=true. You don't need to force this refactoring on each start.
Related
This seems like a very easy problem, but I really can't figure out what's going on. I have some problems understanding the saving process on the Django admin site. This is the situation, simplified as much as possible:
models.py
import uuid
from django.conf import settings
from django.db import models
class BaseModel(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=settings.IS_DEV)
created = models.DateTimeField(auto_now_add=True)
modified = models.DateTimeField(auto_now=True)
class Order(BaseModel):
[various properties and functions]
class Article(BaseModel):
order = models.ForeignKey(Order, null=True, on_delete=models.CASCADE, related_name='articles')
[various properties and functions]
class PaymentOperation(BaseModel):
order = models.ForeignKey(Order, null=True, on_delete=models.CASCADE)
[various properties and functions]
admin.py
from django.conf import settings
from django.contrib import admin
from models import Order, Article, PaymentOperation
class BaseModelAdmin(admin.ModelAdmin):
readonly_fields = ['created', 'modified']
if not settings.IS_DEV:
readonly_fields.append('id')
class ArticleInline(admin.TabularInline):
fields = ['id', ...]
readonly_fields = ['id', ...]
can_delete = False
extra = 0
max_num = 0
[more code]
class PaymentOperationInline(admin.TabularInline):
fields = ['id', ...]
readonly_fields = ['id', ...]
can_delete = False
extra = 0
max_num = 0
[more code]
class OrderAdmin(BaseModelAdmin):
readonly_fields = BaseModelAdmin.readonly_fields + [...]
fieldsets = [...]
inlines = [ArticleInline, PaymentOperationInline]
[more code]
class ArticleAdmin(BaseModelAdmin):
readonly_fields = BaseModelAdmin.readonly_fields + [...]
fieldsets = [...]
[more code]
This is the main structure, but I'm not really sure if it's enough to generate the problem. I didn't want to clog the question with hundreds of lines of code. I'll try to be more specific if necessary.
Some fields in the Order and Article models are editable, while all fields in the PaymentOperation model are read-only.
If I edit an Article from its admin page, it works perfectly. If, on the other hand, I try to edit an Order, and then save it, the page behaves strangely. The order is not saved, and an error message appears on top of the page, saying "Please correct the errors below." All the fields, both editable and read-only, remain unchanged. The two inlines at the bottom of the page are in a worse state. All read-only fields are reset to the default value, if available, or nulled, and all IDs are different. Editable fields of the article inline remain the same. It looks to me like the page is trying to create new entries, instead of editing the old ones.
I tried commenting out the inlines in the OrderAdmin declaration one at a time, but with no effect. Commenting out both lets me save the order correctly.
I also tried adding a save_model and save_formset to OrderAdmin, but whatever the error is, it's produced before these functions are called. The shell where I run python manage.py runserver doesn't even show any error message.
There are many other models in models.py and in admin.py, and none of them has the same problem. Some of these models even have their own inlines.
I'm really puzzled. I'm trying to understand the difference between the part of the code shown above and the rest, but I can't find it. I know the saving process worked before I added the payment operation a few days ago, and I'm almost certain that I didn't change anything in the order and article models (I will check though, just to be sure). At this point I'm not sure I understood the saving process, or what's wrong with the code.
Edit: I can't find significant changes to the order and article models, as well as their admin counterparts.
Apparently, the whole problem is located in the editable=settings.IS_DEV setting for the ID of every model. I don't know exactly why, but setting editable=False solves the problem.
I noticed I never had this problem on the production server, only on the ones flagged as development. Fortunately being able to set a specific ID was only useful in a very limited set of cases, so I won't miss it, but I feel like I just traded a problem with a less annoying one. If someone has a better solution, I'll be happy to change my mind and recognize that as the answer to this question.
I'm running DSE 5.0.5 on 2 identical clusters, all nodes being Spark+SOLR. On the first everything is ok, however on the second I got this message in /var/lib/cassandra/system.log:
INFO [PO-thread-0] 2017-04-02 19:26:43,176 DbInfoRollupPlugin.java:196 - Error retrieving node level db summary
It is reported as "INFO" however something is wrong and I can't figure it out. Partial stack trace follows:
INFO [PO-thread-0] 2017-04-02 19:26:43,176 DbInfoRollupPlugin.java:196 - Error retrieving node level db summary
java.util.concurrent.TimeoutException: null
at java.util.concurrent.FutureTask.get(FutureTask.java:205) [na:1.8.0_112]
at com.datastax.bdp.plugin.DeferringScheduler$DeferringTask.get(DeferringScheduler.java:115) ~[dse-core-5.0.5.jar:5.0.5]
at com.datastax.bdp.reporting.snapshots.db.DbInfoRollupPlugin$DbInfoRollupTask.doRollup(DbInfoRollupPlugin.java:192) [dse-core-5.0.5.jar:5.0.5]
at com.datastax.bdp.reporting.snapshots.db.DbInfoRollupPlugin$DbInfoRollupTask.run(DbInfoRollupPlugin.java:173) [dse-core-5.0.5.jar:5.0.5]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_112]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_112]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_112]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_112]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_112]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_112]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_112]
Could you please indicate what to check to correct this issue.
Many Thanks
I figured out that is this property:
dse.db_info_rollup_node_query_timeout that has a default of 3000 ms.
However I don't know where to set it...
Pls advice,
Thx.,
Cristian
Please set performance_core_threads: 2 in dse.yaml. Note that this setting is probably missing in default dse.yaml so you will have to add it. Don't confuse it with
Although you receive that timeout exception, it should work.
I've been facing a problem related to multiline events lately, and I am needing a little bit of your help for this. My syslog server is sending multi-line events. One single event gathers several lines, and the indicator that proves a particular event line is part of a multi-line event is a random number that defines a user connection session. Here is a custom generated log file:
Feb 16 17:29:04 slot1/APM-LTM notice apd[5515]: 01490010:5: 1ec2b273:Username 'cjones'
Feb 16 17:29:04 slot1/APM-LTM warning apd[5515]: 01490106:4: 1ec2b273: AD module: authentication with 'cjones' failed: Preauthentication failed, principal name: cjones#GEEKO.COM. Invalid user credentials. (-1765328360)
Feb 16 17:10:04 slot1/APM-LTM notice apd[5515]: 01490010:5: d8b5a591: Username 'gbridget'
Feb 16 17:10:04 slot1/APM-LTM err apd[5515]: 01490107:3: d8b5a591: AD module: authentication with 'gbridget' failed: Clients credentials have been revoked, principal name: gbridget#GEEKO.COM. User account is locked (-1765328366)
Feb 16 17:29:04 slot1/APM-LTM notice apd[5515]: 01490005:5: 1ec2b273: Following rule 'fallback' from item 'AD Auth' to ending 'Deny'
Feb 16 17:29:04 slot1/APM-LTM notice apd[5515]: 01490102:5: 1ec2b273: Access policy result: Logon_Deny
Above are the lines related to two different connections defined by the following user sessions: d8b5a591(user gbridget) and 1ec2b273(user cjones). user sessions are the only indicators that connect those lines to two different events. not to mention that the line events are interwined.
The problem is that I am at loss as to how to explain the above to grok filter with a multiline plugin, knowing that the latter offers too few options. In fact , the notion of "previous" and "next" line cannot be applied here for instance, so the grok options "pattern" and "what" cannot be used, since the events are not necessarily consecutive.
I would really appreciate it if someone could shed some light on this and tell me if at least it is feasable or not.
I don't see those as multi-line events, but as related events. I would load them into elasticsearch as 6 different documents and then query as needed. If you have specific queries that you're trying to perform against this data, you might ask questions about how to perform them against multiple documents.
One alternative would be to use the session_id as the document ids and then you could update the initial documents when new information came in. They don't recommend using your own document ids (for performance reasons, IIRC), and updating a document involves deleting the old one and inserting a new one, which is also not good for performance.
I have some fairly simple code written to experiment with astyanax. It works fine when talking to a single node Cassandra db on localhost, but when I write the same schema to a two node cluster (which is definitely accessible from my host), I get a TokenRangeOfflineException.
What am I missing?
AstyanaxContext.Builder builder = new AstyanaxContext.Builder()
.forKeyspace("myKeyspace")
.withAstyanaxConfiguration(new AstyanaxConfigurationImpl()
.setDiscoveryType(NodeDiscoveryType.NONE)
)
.withConnectionPoolConfiguration(new ConnectionPoolConfigurationImpl("MyConnectionPool")
.setPort(9160)
.setMaxConnsPerHost(5)
.setSeeds("host1.domain.com,host2.domain.com")
)
.withConnectionPoolMonitor(new CountingConnectionPoolMonitor());
produces this error:
Exception in thread "main" com.netflix.astyanax.connectionpool.exceptions.TokenRangeOfflineException: TokenRangeOfflineException: [host=host1.domain.com, latency=59(94), attempts=1]UnavailableException()
at com.netflix.astyanax.thrift.ThriftConverter.ToConnectionPoolException(ThriftConverter.java:165)
com.netflix.astyanax.connectionpool.exceptions.TokenRangeOfflineException: TokenRangeOfflineException: [host=host1.domain.com, latency=59(94), attempts=1]UnavailableException()
at com.netflix.astyanax.thrift.ThriftConverter.ToConnectionPoolException(ThriftConverter.java:165)
at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:60)
at com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$1$2.execute(ThriftColumnFamilyQueryImpl.java:200)
at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:60)
Try w/ NodeDiscoveryType.RING_DESCRIBE
Answering my own question, partly. I got it to work by making several changes. I'm not sure why the simple case doesn't work, but the following did.
First, I replaced my keyspace, which was created with defaults (create keyspace foo), like this:
create keyspace foo with placement_strategy = 'NetworkTopologyStrategy'
AND strategy_options={DC1:1};
That changes the output of "nodetool describering foo" such that endpoint_details has something in it. I had previously stepped through the debugger and noticed that endpoint_details being empty was a cause of some failures once I switched my astyanax config to look like this:
AstyanaxContext.Builder builder = new AstyanaxContext.Builder()
.forCluster("myCluster")
.forKeyspace("foo")
.withAstyanaxConfiguration(new AstyanaxConfigurationImpl()
.setDiscoveryType(NodeDiscoveryType.RING_DESCRIBE)
.setConnectionPoolType(ConnectionPoolType.TOKEN_AWARE)
)
.withConnectionPoolConfiguration(new ConnectionPoolConfigurationImpl("MyConnectionPool")
.setPort(9160)
.setMaxConnsPerHost(5)
.setInitConnsPerHost(1)
.setSeeds("host1,host2")
)
.withConnectionPoolMonitor(new Slf4jConnectionPoolMonitorImpl());
I would love to see some documentation that describes configuration options recommended for common cluster/keyspace settings. I'm sure it's obvious to the cognoscenti, but for noobs, it's a little opaque.
I am working on Solr in my application. I am using apache-solr-solrj-1.4.0.jar.
When I try to call add(SolrInputDocument doc) from CommonsHttpSolrServer, I am getting the following exception:
org.apache.solr.common.SolrException: Internal Server Error
Internal Server Error
at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:424)
at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:243)
at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:105)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:64)
Can anyone please help me to resolve this problem?
The following are the attributes in solrconfig.xml:
<lockType>native</lockType>
<unlockOnStartup>false</unlockOnStartup>
<reopenReaders>true</reopenReaders>
I am getting the following exception in the solr server logs:
24 May, 2010 2:51:22 AM org.apache.solr.common.SolrException log
SEVERE: java.lang.NullPointerException
at org.apache.solr.handler.ReplicationHandler$4.postCommit(ReplicationHandler.java:922)
at org.apache.solr.update.UpdateHandler.callPostCommitCallbacks(UpdateHandler.java:78)
at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:411)
at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:85)
at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:107)
at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:48)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:210)
at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:347)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
INFO: {} 0 1039
24 May, 2010 2:52:29 AM org.apache.solr.common.SolrException log
SEVERE: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock#./solr/data/index/lucene-be18de26b941317e71dc59f9e5ba63c4-write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:85)
at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1545)
at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1402)
at org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:190)
at org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:98)
at org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:173)
at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:220)
at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:139)
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:54)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:210)
at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:347)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
I have set following in my solrconfig.xml and it works.
<lockType>simple</lockType>
<unlockOnStartup>true</unlockOnStartup>
Also, set following to avoid write lock exceptions on index directory:
<maxFieldLength>10000</maxFieldLength>
<writeLockTimeout>60000</writeLockTimeout>
<commitLockTimeout>60000</commitLockTimeout>
I am very unsure, but in this thread
http://www.mail-archive.com/solr-user#lucene.apache.org/msg08048.html
they recommend to use
<unlockOnStartup>true</unlockOnStartup>
and
<lockType>simple</lockType>
I think this should be safe as long as you access the index through solr or solrj (not though lucene!).
Any other ideas?
SolrJ client does not give you the actual error. Try looking at the solr server logs which should be located under tomcat or jetty (or whatever runs solr).
Sounds like a corrupt index or busy lock file.. I had something similar and restarting worked, oddly enough.
It comes from failing to remove write.lock file after some update actions. Removing the write.lock in the core's data/index folder will solve this problem temporarily and regain updating action. I know using post.jar to update has more bad luck to cause this problem, whereas url with stream.body rarely cause this problem. Karussel's answer did improves the situation but seems not solve it at all. I doubt it comes from some design issue of Solr. Hope Solr 4 has solved this problem. Also one can refer to the answer in this question: how-to-solve-the-lock-obtain-timed-out-when-using-solr-plainly