Issue returning old/stale field values

Hello,

I am sometimes getting old values from an Issue. Does anyone know why possibly?

Here are the relevant code snippets of how I get an issue:
CustomFieldManager customFieldManager = (CustomFieldManager)ComponentAccessor.getOSGiComponentInstanceOfType(CustomFieldManager.class);

String customFieldId = “customfield_11311”;
CustomField custField = customFieldManager.getCustomFieldObject(customFieldId);

Object valueObj = issue.getCustomFieldValue(custField);

Thanks,
Al

EDIT: The above is what I’m trying now to see if it fixes the issue. The only change is that before I was calling ComponentAccessor.getComponent(). The documentation of the OSGi version mentioned caching in a way that led me to believe that the getComponent() method might return an instance that might be old itself at some point. I am just grasping at straws at this point, however.

when are you executing this script

This is Java code in an add-on. There is an event listener that kicks off this process.

What event does this fire on? Is it possible that the fields are updated by yet another listener? You can’t guarantee which order Event Listeners will fire in, so if the fields are updated by other listeners you’re not going to find consistency.

It fires on an event update event. We are testing on a Jira instance that no one but our testing team have access to. We see it many times in succession before it finally returns the latest value. We are all coordinated.

I’m sorry but I am not sure what this means. Why are you running it many times in succession? What does ‘coordinated’ mean in this context?

I’m just saying that there is no chance that the value is getting updated by someone else. Our testing team is the only ones using this Jira instance. The event listener prints out the issue’s field values each time someone updates the issue and the old value is returned for a user-picker field after the field value is changed to someone else and behaves this way for many updates for about, say, 10 minutes until it finally returns the new value.

Could threading be a cause? This is a multi-threaded add-on. Are there any Issue caches that are tied to a specific thread? I am getting a new IssueManager and a new Issue for it base on the issue key every time. But, the issue event listener sometimes hands-off processing to another thread.

It’s like I’m getting an old cached value sometimes. Is there a way to force IssueManager to go directly to the DB?

Could it be the cache in the CustomFieldManager? Just noticed the clear() method.

It might be the other way round. If you access the custom field via the issue.get…() method, you get the issue’s cached value, which is usually the way to go (especially within workflow transitions). Someone else might be updating the custom field directly in the database, though, via CustomField.updateValue().

You might want to try CustomField.getValueFromIssue() to get the persisted value.

Thanks Ulrich,

Just double-checking, did you mean CustomFieldType.getValueFromIssue(CustomField field,Issue issue)? I noticed the docs say in bold that it returns the current value.
The similar method of RenderableField I initially stayed away from since I was thinking it was for use by the UI.

Interesting… I just came across JiraThreadLocalUtil . I wonder if my running this code in a regular Java Runnable thread is causing problems.

Does anyone have any suggestions?

JiraThreadLocalUtil is exactly what I’m using and it solved my problem.
Just follow the documentation and see if it fixes your problem:

jiraThreadLocalUtil.preCall();
try {
  // Do your runnable code here
} finally {
  jiraThreadLocalUtil.postCall(log);
}

Note that you must place everything which is running in the new thread into the try block, so the JiraThreadLocalUtil will clean up the old issue’s value before executing a new task in that thread.