Starting a Thread from a groovy script causes a high number of connections to the DB

[Jo-André Lia]

I've got a groovy script that I'm running from an event listener.

The script starts a new thread like this:

Thread thread = Thread.start {
    try {
        def workAttributeValue = null
        while (workAttributeValue == null) {
            ServiceOutcomeImpl serviceOutcome = workAttributeValueService.getWorkAttributeValueByWorklogAndWorkAttribute(issueEvent.worklog.id, workAttribute.getId())
            workAttributeValue = serviceOutcome.getReturnedValue()
        }
        
        //does something more with the returned workAttributeValue
    } catch (Exception e) {
        Thread.currentThread().interrupt()
        log.warn("\nLogFlexTime has had an exception " + e.message + "\n" + e)
        return
    }
    return
} 

The script starts and finishes before the thread finishes. This is just as espected.

The issue is that the call to workAttributeValueService creates a connection to the DB and in some cases never releases it. Or at least holds on to it for a very long time. The result is that the connection pool goes through the roof and starts to throw exceptions.

So my question is what am I doing wrong here? Am I not closing the Thread or something?

[adammarkham]

Is there a particular reason you're starting a thread for this? What are you trying to achieve with your event listener?

Does the script fail with an exception and you get the warning message in the logs?

[Jo-André Lia]

Thanks for your reply.

The reason for starting a thread is that I'm using Tempo for time registration and I've added a work attribute called Overtime. The user selects this if the time they log is overtime. I have a listener that gets called when work is logged, updated or deleted. I then call this script that checks if the attribute value is overtime or not. The overtime value which is Tempo plugin specific is not part of the standard JIRA event that is thrown so I have to try to get it from the stored worklog in the DB. The issue I have is that since the event system in JIRA is synchronous I cannot check the value in the DB before the event has been completed. It simply doesn’t exist in the DB yet. So I’m starting a thread in the event script that is waiting for the value to appear in the DB and fetches it so that I can use the value in the script.

This is the only way I have found to get the value and use it when the event happens. If there are any other way I’m more than happy to change it.

The thing is that it doesn't seem to fail as the Exception handling that I have doesn't print out anything in the log file.

[adammarkham]

Thanks for explaining that. It may take a while for it to appear so in your code you may have to poll for the value with some timeouts.

But I can't figure out why it's not releasing the connection after it finishes.

Does the read from the database ever complete? You could add a log statement afterwards to check this.

What happens if you just get that attribute in a script in the script console multiple times (for an attribute already in the DB)? Do the connections build up then?

Is they do you may want to raise this with Tempo as their source code is not public for us to check this.

[Jo-André Lia]

Yes, I have a while loop that calls the service as you can see untill the values in written to the DB. It usually takes a couple of runs before the value is in place.

I'm currently not using timeouts to make sure it goes as quickly as possible.

I've done some more logging now and what I see is that in some cases the loop becomes infinite. That explains the connection to the pool. The query to the DB always returns null in some cases. I don't know why that happens so I will have to dig more into that.