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

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--

1 answer

0 vote

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.

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)

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?

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

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...

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.

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.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Jira

Mission-critical battery manufacturer fulfills FAA software requirements with Commit Policy Plugin

EaglePicher Technologies is a leading manufacturer of battery systems for diverse industries like defense, aviation, space or medical. As they operate in highly regulated industries, keeping a clear ...

172 views 0 2
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you