Web front-end crash

Issue Type:

• defect report
• enhancement request

Current Behavior:

On more than one occasion, Dependency-Track has had a crashed web server (the UI), even whilst there is nothing odd in the logs and normal tasks are seeming to continue to run as normal.

I have previously reported CPU problems via #264, and attached a screenshot of a “UI-gone-wrong” to the initial report. ie, web server running and just shows directory WEB-INF. What I am reporting here is something different, as my DT server currently runs with npm analyser disabled and the CPU utilisation is bubbling along for day after day at a steady 3% with spikes to 10% (that indicate DT tasks running).

After noticing that the UI was giving an error, a service restart instantly got everything back to normal with the UI.

I did not test dependency-track jenkins plugin whilst the DT web UI was down… but I am sure it would not have been possible to publish a BOM from Jenkins.

Steps to Reproduce (if defect):

Hard to reproduce as DT can be up and running fine for a period and suddenly cannot be accessed via the UI.

Expected Behavior:

Stable webserver.

Environment:

• Dependency-Track Version: v3.4.0
• Distribution: [Executable WAR]
• Database Server: [PostgreSQL]
• Browser: Firefox v64

Other Details:

(e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

When the webserver is accessed, it displays:

Problem accessing /WEB-INF/fragments/error.jsp. Reason:
--
 
/WEB-INF/fragments/error.jsp
 
Caused by:
 
org.apache.jasper.JasperException: org.apache.jasper.JasperException: java.io.FileNotFoundException: /tmp/jetty-0.0.0.0-8080-dependency-track-embedded.war-_-any-1020949971490178642.dir/webapp/WEB-INF/lib/encoder-jsp-1.2.2.jar (No such file or directory)
at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:579)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
...

Let me know if you need the full exception (I am logging this issue from home and do not currently just have the above snippet to hand).

Although I report that the logs contained nothing odd, there was a single error event relating to the above exception that was recorded each time the UI URL was visited.

[msymons]

@stevespringett, my DT server required a restart today (3.5.1 upgrade).

Until this restart, it had been running without problem for 27 days without a UI crash… using the alternate temp directory really seems to have helped.

It surprises me that no one else seems to have had similar issues… our DT is running on a standard Azure VM and I am pretty certain that no adjustments were made to standard tempdir management.

[stevespringett]

Yes, you can keep the ticket open.

One thing that would REALLY help out a lot are folks willing to beta test 3.5 snapshots and do so without affecting production data. Basically having a standalone 3.5 installation with a dedicated database just for 3.5 to test the progress that’s being made.

Docker snapshots are always available. Traditional and executable wars currently need to be compiled from source, but I’ll likely create a snapshot repo for those as well.

A lot of work has gone into refactoring use of HttpClient usage - so all outbound connections such as NPM Audit, OSSIndex, Slack, MSTeams, etc should see noticable improvements. There’s also 4 new configuration properties for configuring database connection pool settings and the timeout for the maxLifetime has changed from 30 minutes to 10 minutes. It’s important to keep this number slightly shorter than the value imposed by the database server or any network device capable of terminating persistent connections.

These changes along with minor bug fixes and the snapshot releases are likely a bit more stable than the 3.4 released version. But confirmation of that would be really helpful.