Change is required. Atlassian engineer's blog

  Today, I would like to collaborate with the community about  the real usage of Insight for Jira in world instances and provide my feedback. As we know on Cloud, Insight for Jira has a limit of  400k objects for Enterprise subscription , 60k for other situations on the Cloud. So for the on-premises releases Insight for Jira has not any limitation, except  heap size requirement.   Objects in Insight JVM memory ~10.000 4Gb ~100.000 8Gb ~500.000 16Gb ~1.000.000 32Gb ~2.000.000 64Gb ~5.000.000 128Gb Note the next info: remember to always test the memory consumption in a test environment for a huge data set, because it's not always the number of objects, but the content of the object attributes as well at play.  i.e. one of my instance has  Jira/JSD/JSM version:  8.13.9 (3 nodes in DC) Insight version:  8.7.9 Java version:  11.0.11+9 GC Strategy:  G1GC   Heap Size:  38 GB Count of Objects:  1.6 mln objects Count of Units ...

  Hi!  Today I would like to share a curious story related to the integration of Jira (adoptJDK 11) and the ERP system which works on old Java 6. You would say to me, welcome to the "blood enterprise systems". So during our security audit, IDS detected the non-secure protocol TLSv1.1 in that inter-connected communication Jira DC and that ERP system, correctly one of the cipher suites  TLS_RSA_WITH_AES_128_CBC_SHA . Yes, it's an old cipher suite, and that tutorial can be used for any other cipher suite as well.  How we can fix it?  Set string TLS protocol for all Jira (don’t forget for all nodes), TLS1.3 , TLS1.2. And please, keep in your mind the  bug  (JDK-8211806 : TLS 1.3 handshake server name indication is missing on a session resume) Adjust java.security configurations   Below table describe the small background and default protocols in your jdk/jre:    JDK 8 (March 2014 to present) JDK 7 (July 2011 to present) JDK 6 (2006 to  ...

  Hi!  Gonchik in touch.  As we know Garbage-First is quite a popular garbage collector nowadays. At least more and more articles, product documentation mention G1GC.  Today, I’d like to share a story about leaked Jira Service Desk DC (3 nodes) with more than 20 apps from the marketplace, quite a lot of groovy scripts (405 files), 6 in-house apps. Also, it's continue of  previous article . One of the instances every night do import files into the  “Insight” app , those asset management includes too many assets around 1 mln, as it’s daily import history of objects can grow as well. Let’s focus only on importing procedure, we had 1 dedicated instance with 32GB heap for jdk8u282-b08 and G1GC. During import find out the next behaviour: # cat atlassian-jira-gc.0.current| grep -i "full" 2021-03-30T21:13:19.462+0300: 934.828: [Full GC (Allocation Failure)  31309M->23165M(32768M), 58.7721842 secs ] 2021-03-30T21:14:31.997+0300: 1007.363: [Full GC (Allocatio...

  Hello,    Today I would like to provide my feedback about using JDK 11 and JDK 8. My reason for  that is motivating the other person to go forward with new releases, instead of waiting for the more stable and more robust release, who will test and provide if everyone will wait?    That story of performance depute of JDK 11 vs JDK 8, as that depute started from that article ( reasons to stick Java 8 ) with one of member of Atlassian community, so fully correct way is measure one your instance.    So what about to make a real performance testing on our copy production Jira? As Atlassian team provided a pretty simple toolkit to make performance tests ( performance-toolkit ), sure we can to it.   My setup based on the next things: Copy of production Jira 8.5.4 on dedicated VM Changing the Java version via JAVA_HOME variables with the same arguments and GC strategy (G1GC): [[gonchik.tsymzhitov@jirasandbox1 java]# /usr/java/latest/jre/bin/java -v...

  Today, I want to share my opinion about some improvements in the plugins directory, it’s continued article of   OWASP dependencies checks   ( link ).  As we know last time Atlassian start by design to request CodeCache 512M in setenv.sh. ( https://jira.atlassian.com/browse/JRASERVER-66796 )  So based on that general picture we can find the code cache one of the main areas of memory. Simply put,  JVM Code Cache is an area where JVM stores its bytecode compiled into native code . We call each block of the executable native code a  nmethod . The  nmethod  might be a complete or inlined Java method. The just-in-time (JIT) compiler is the biggest consumer of the code cache area. That's why some developers call this memory a JIT code cache.    Just to be clear, why do most of apps are a huge memory and time consumers? Most of answer is new functionality, but functionality is not growing exponentially, as a codebase.   Based on that...