Home/ Questions/Q 7441033
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T10:56:46+00:00

I have deployed a ‘Customer’ customfield plugin in JIRA which accesses a SQL Server

  • 0

I have deployed a ‘Customer’ customfield plugin in JIRA which accesses a SQL Server database on a server. What happens is when I go to EDIT an issue, if i have the customfield enabled then the webpage takes an extra 2-3 seconds to load. If i then go and disable the customfield, there is no lag at all, the page loads instantaneously, so it is definitely related to this new customfield. Also it is important to note that in the Development Environment there is no lag at all regardless of whether the customfield is enabled or not.

Its strange because, the SQL driver i am using in BOTH the Production and Development Environment is the ‘net.sourceforge.jtds.jdbc.Driver’. Also the URL i am using to access the database of Customers in BOTH the Production and Development Environment once again is exactly the same: jdbc:jtds:sqlserver://:”. Also the exact same version of the driver is being used: jtds version 1.2.4.

I cant think of anything else that could possibly cause the problem.

Any help would be much appreciated.

Thanks everyone.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well, it’s still all but uncommon to encounter production and development environments, which are considered identical from a distance, but in fact are not 😉

    For example, does the customfield execute ‘heavy’ SQL operations by chance? In this case even minor differences between dev and ops environments could make all the difference in the end:

    • SQL Server version and configuration details
    • JDBC driver version (you verified this one already)
    • JIRA version and configuration details
    • Any relevant hardware difference could have similar effects, e.g. available memory, memory speed, harddisk speed, CPU performance, number of cores etc.

    The best approach in cases like this is almost always trying to identify the bottleneck by actually measurement, be it via code instrumentation or SQL server monitoring or external monitoring solutions – especially the latter two should help you to identify slow SQL queries, if any.

    Good luck!

    • 0