despite setting jira.index.max.reindexes=0, JIRA tries reindex on issues update / create

[Sridhar Nimmagadda]

contents of <jira_install_dir>/atlassian-jira/WEB-INF/classes/jira-application.properties

jira.home = /jira-data

jira.index.max.reindexes=0

when i run my load test i see the excepton below, looks like it still is trying to reindex despite the setting...

2012-06-15 15:38:08,361 http-8081-50 ERROR anonymous 937x32089x25 - 10.240.11.82 /rpc/soap/jirasoapservice-v2 [jira.issue.index.DefaultIndexManager] Wait attem

pt timed out - waited 30000 milliseconds

com.atlassian.jira.issue.index.IndexException: Wait attempt timed out - waited 30000 milliseconds

at com.atlassian.jira.issue.index.DefaultIndexManager.obtain(DefaultIndexManager.java:561)

at com.atlassian.jira.issue.index.DefaultIndexManager.await(DefaultIndexManager.java:510)

at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:346)

at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:299)

at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssueObjects(DefaultIndexManager.java:309)

at sun.reflect.GeneratedMethodAccessor467.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.atlassian.util.profiling.object.ObjectProfiler.profiledInvoke(ObjectProfiler.java:81)

at com.atlassian.jira.config.component.SwitchingInvocationHandler.invoke(SwitchingInvocationHandler.java:28)

at $Proxy114.reIndexIssueObjects(Unknown Source)

at com.atlassian.jira.event.listeners.search.IssueIndexListener.reIndex(IssueIndexListener.java:147)

at com.atlassian.jira.event.listeners.search.IssueIndexListener.issueCommented(IssueIndexListener.java:80)

at com.atlassian.jira.event.issue.AbstractIssueEventListener.workflowEvent(AbstractIssueEventListener.java:106)

at com.atlassian.jira.event.issue.IssueEventListenerHandler$IssueEventInvoker.invoke(IssueEventListenerHandler.java:49)

at com.atlassian.event.internal.AsynchronousAbleEventDispatcher$2.run(AsynchronousAbleEventDispatcher.java:60)

at com.atlassian.event.internal.AsynchronousAbleEventDispatcher$1.execute(AsynchronousAbleEventDispatcher.java:28)

at com.atlassian.event.internal.AsynchronousAbleEventDispatcher.dispatch(AsynchronousAbleEventDispatcher.java:56)

at com.atlassian.event.internal.EventPublisherImpl.invokeListeners(EventPublisherImpl.java:151)

at com.atlassian.event.internal.EventPublisherImpl.publish(EventPublisherImpl.java:70)

at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.atlassian.multitenant.impl.MultiTenantComponentFactoryImpl$AbstractMultiTenantAwareInvocationHandler.invokeInternal(MultiTenantComponentFactoryI

mpl.java:181)

at com.atlassian.multitenant.impl.MultiTenantComponentFactoryImpl$MultiTenantAwareInvocationHandler.invoke(MultiTenantComponentFactoryImpl.java:211)

at $Proxy5.publish(Unknown Source)

--More--

[Nic Brough -Adaptavist-]

I think there's a string of problems here, if I've understood the question properly.

You seem to be assuming indexing is causing a problem. That's partly true, but you're looking at a symptom of a problem rather than a cause. Tinkering with the indexing is not going to help you with this.

Jira needs the index to function. So if you disable it, you're causing problems.

If you're doing load testing, then you're invalidating your test because you're going to break Jira, and there's no point load testing a system you already know is broken.

I think you've misunderstood the flag you've changed as well. It has nothing to do with whether indexing is run or not, it's a counter to say "I should optimise the index if this many individual indexing operations have been performed since I last did it"

Because of that, it's probably having the opposite effect of what you're assuming - it's simply optimising the index constantly.

The error you're getting is usually a symptom of heavy loading on the index. Ok, that's fine as you're load testing, you're finding the break point. But if you're optimising constantly, that will be putting a load on the index and contributing to the problem, and lowering the performance.

My suggestions would be:

1. Put the setting back to what it should be so you're testing is running against a realistic and usable system.
2. Re-run your load tests, gradually ramping up until the indexing fails. Then log that load as the failure point.

[Sridhar Nimmagadda]

Thanks Nic..

I agree with you, it looks as though i am treading a wrong path.

Well I actually want to load test jira, i seem to hitting the above exception within 2 hrs with 25 concurrent users, went through some documents and figured out that there there is a bug in the reindexing part.

So the work around was to set jira.index.max.reindexes=0 (for reindexing not to happen) and do a manual reindex when ever its necessary.

so the idea is to stop automatic reindex see if jira would scale.

The fact is that i am not able make jira.index.max.reindexes=0 and when view the system info page it still mentions jira.index.max.reindexes=4000( the default one)

[Nic Brough -Adaptavist-]

Um. I repeat

1) Turning off indexing is pointless - Jira needs it. Your testing on a Jira without indexing is useless. You will need to "manually reindex" EVERY time you change an issue

2) The flag you are looking at does not affect indexing, it's nothing to do with turning indexing on or off. I'm not even sure you can turn indexing off with a flag (and even if you can, it's a waste of time because Jira will stop working and there's no point testing a broken system)

As for the flag not being picked up - did you restart after you changed it?

[Sridhar Nimmagadda]

yes I did restart, but jira would not pick it up the logs still say jira.index.max.reindexes=0

we have aroung 700,000 issues with 50-60 concurrent users, do you think there is any point in using jira, since it doesn't seem scale, is there any better work around.

thanks

Sridhar

[Nic Brough -Adaptavist-]

That's a completely separate question. I've worked with significantly larger Jira installations and not had problems, but you do need to do some analysis on where any performance issues are happening.

From what you've said here, an obvious one is that you're messing up the indexing by misunderstanding some of the flag settings...

[Royce Wong]

Sridhar, any luck on figuring this Wait attempt timed out? I am using JIRA 4.4.5 and see this error sporadically in our log.

[Nic Brough -Adaptavist-]

I think he gave up when he realised he was barking up the wrong tree.

The timeout is usually due to an overloaded server, I'm afraid you're going to need to get stuck into perfomance and load monitoring and tuning.

[Royce Wong]

OK. Thanks Nic.