As per https://confluence.atlassian.com/fishkb/how-to-monitor-fisheye-crucible-using-jmx-in-linux-680395029.html we have enabled JMX. The last screenshot from the article is what we see in our JMC (so JMX setup is correct on our side).
However we are still not satisfied as we expected to see more of consumed/busy AJP threads. This looks like not viable here as JMX does not provide MBean org.eclipse.jetty.servlet.utils (in short we would like to see what Tomcat provides via Catalina:type=ThreadPool,name="ajp-bio-8019" -> currentThreadsBusy)
I saw on web that this Jetty util class will expose used threads and usage of AJP threads similar to Tomcat/Catalina ones. We often have problems with users not being able to connect to the Fisheye server while it looks Fisheye engine itself works fine. If we get such stuck on threads this ends in most cases in Fisheye restart. Application will not recover itself from this issue in most cases :-(
Having more Jetty MBeans exposed will let us to do better monitoring/root cause analysis.
I am not an expert so asking if simple extra options passed to java will enable more MBeans to be exposed or this is strictly Java code modyfication is the only way (so would this be possible?)
4.4.1 version, Java 1.8, beefy server (many cores, 64G of RAM etc). Current threads used config.xml:
<web-server context="/fisheye" site-url="https://odyssey.apps.csintra.net/fisheye" min-threads="250" max-threads="400">
<http bind=":8060" proxy-port="443" proxy-scheme="https" proxy-host="xxxxxxx"/>
Our Apache uses proxy pass to AJP
ProxyPass ajp://%FECRU_HOST%:8061/fisheye timeout=300
It really doesn't seem possible to add/use the MBean org.eclipse.jetty.servlet.utils.
In the other hand, please note that according to Proxying Atlassian server applications with Apache HTTP Server (mod_proxy_ajp), starting from version 4.0, Fisheye has stopped support for the AJP authentication, so this should no longer be used. Maybe this is the root cause of the problem about users being unable to login?
According to Fisheye 4.0 user directories migration (under Custom / AJP authentication section), users with the custom, AJP or host-based authentication type have been migrated to the internal directory, although their passwords are reset.
This means that you can likely remove the <ajp13 bind=":8061"/> setting from config.xml.
Hi All! We’re excited to share the launch of an announcement banner that lets Jira site administrators communicate directly to their users across their Jira Cloud instance. ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events