Network error when other site is down

General Questions
1

Is it possible to extent the timeout?

We sync between 2 Jira dc

One DC is fully restarted on a daily base for reasons

The startup time is longer than the network timeout.

Is there a way to extend this timeout

2

It sounds like your Jira Data Center sync is running into network timeouts because one of your Jira DC nodes is offline for a while during its daily restart. You’re wondering if there’s a way to extend the network timeout in Exalate so it waits longer before giving up.

Based on the available documentation, there isn’t a direct setting in the Exalate UI to configure or extend the network timeout for Jira DC-to-DC connections. Exalate relies on the underlying network and application server settings for timeouts. If the destination Jira instance is unavailable for longer than the default timeout, sync attempts will fail and be retried later.

What you can do:

  • Check if your application server (e.g., Tomcat) or reverse proxy (e.g., NGINX, Apache) in front of Jira allows you to increase HTTP timeouts. Adjusting these may help Exalate wait longer for a response.
  • Exalate will automatically retry failed syncs once the remote instance is back online, so no data should be lost—just delayed.
  • If you’re seeing frequent errors, you might want to review your Exalate logs for more details or consider scheduling syncs to avoid the downtime window.

For more on connection setup and troubleshooting, see the Jira on-premise connection documentation.

If you need more granular control over retry intervals or error handling, you may want to reach out to Exalate support for advanced configuration options.

3

Hi @francis ,

May I please have your confirmation on whether Aida’s response addresses your question, or if you still require further assistance?

If additional help is needed, could you please share more details about the type of timeout you’re referring to? This will allow me to provide a more accurate response.

Thank you,
Ashar

5

Hi @francis ,

I’m afraid the variable to extend the time-out isn’t available. However, there is a workaround using the ScriptRunner tool, which can help automate the resolve operation for specific errors that you define in the script below.

// SCRIPT FOR SOLVING EXALATE ERRORS USING SCRIPTRUNNER .
// COMPATIBLE WITH SCRIPTRUNNER FOR JIRA DC.

import com.atlassian.jira.component.ComponentAccessor
import java.sql.Timestamp

def timestamp = {
(new Timestamp(System.currentTimeMillis())).toString()
}

log.error(“#ResolveErrorJob started at ${timestamp()}”)

def exaCl = ComponentAccessor.pluginAccessor
.getEnabledPlugin(“com.exalate.jiranode”)
.getClassLoader()

def errorServiceClass = exaCl.loadClass(“com.exalate.api.error.IErrorService”)
def errorService = ComponentAccessor.getOSGiComponentInstanceOfType(errorServiceClass)

def allErrors = errorService.findErrors()

allErrors.findAll { e → 
log.error(“#ResolveErrorJob found error ${e.rootCauseDetails}”)
def details = e.rootCauseDetails.trim()
[
“Unexpected error occurred.”,
“Another error condition”
// Add new rootCauseDetail here.
].any { searchedError → 
details.contains(searchedError)
}
}.each { e → 
log.error(“#ResolveErrorJob resolving error for local issue ${e.issueKey} and remote issue ${e.remoteIssueKey} of level ${e.errorEntityType}.”)
errorService.resolveError(e)
}

log.error(“#ResolveErrorJob finished at ${timestamp()}”)

The following part of the code is where you need to specify the error that you want to catch and resolve with the automation:

allErrors.findAll { e → 
log.error(“#ResolveErrorJob found error ${e.rootCauseDetails}”)
def details = e.rootCauseDetails.trim()
[
“Unexpected error occurred.”,
“Another error condition”
// Add new rootCauseDetail here.
].any { searchedError → 
details.contains(searchedError)

Inside the list [ ] add the root cause detail of the error(s) you want to resolve automatically.

As for the iteration, it is always recommended to be > 1’

You might see some warnings in the script, but this is just because of ScriptRunner missing some context, therefore, you don’t need to worry about those warnings. When the script is actually executed, that context is no longer missing and the script works fine.

Kind regards,

Ashar