Change is required. Atlassian engineer's blog

  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...

  Hi, awesome community!   In this article, you can read info about the tool which helps me with search index investigation.  At the moment, I do an investigation with the Russian language stemming and reuse the morphology analysis by reusing existing libraries.  So, as I understand, today we will speak about Apache Lucene index and small awesome utility Apache Luke. Because this search engine library is used for full-text search in the Apache Lucene, Solr, Elasticsearch as well.  It means Jira, Confluence, Bamboo on-premises solution used Lucene, Bitbucket used the Elasticsearch. About Cloud, I imagine the Atlassian team used Elasticsearch as it scales easier even Apache Lucene local index. e.g. for Lucene, you need to use for the replication (lucene-replicator -  https://lucene.apache.org/core/7_4_0/replicator/org/apache/lucene/replicator/Replicator.html ) or just use Elasticsearch.   Let’s use Apache Luke for the Confluence search indexes: I just co...

  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...

  Hi,   Sometimes, I need to reduce latency of Java app, especially, of Atlassian Suite.  As we know Jira, use UUID generation for many approaches, like integration with other Atlassian products. as example, I made grepping for the 7.13.x release sources for the UUID references So we can optimize a small option in the java.security,  which is located in Java 8. $JAVA_HOME/lib/security/java.security for Java 11:  $JAVA_HOME/conf/security/java.security   We can change  to  securerandom.source=file:/dev/urandom instead of  securerandom.source=file:/dev/random I do recommend you to read pages linked in References.   Benchmarks Before making change, let’s do a few  benchmarks.  I used that one ( https://github.com/ajbrown/uuid-generator-benchmark ) on the  Linux version 3.10.0-1127.el7.x86_64 (mockbuild@x86-034.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Tue Feb 18 16:39:12 EST 2020 ...