GlassFish 4.1慢速本地主机Servlet响应（NetBeans）

Question

I have Netbeans 8.0.2 installed on Ubuntu 15.04 which includes the GlassFish 4.1 EE Container.

For some reason, after ensuring my resolv.conf and hosts files were set-up properly, accessing dynamic content, such as a servlet that pulls data from a SQL database, is terribly slow.

However, accessing static JSP pages returns in less than 1ms as it should.

Pinging the server on 127.0.0.1 or localhost returns in 0.038ms or less, which is to be expected, so I don't think the DNS resolving issues common with Linux and localhost are to blame here.

For kicks, I downloaded the GlassFish 4.1 server off their website and set-up NetBeans to deploy there, and I got the same results. In addition I also tried manually deploying my WAR files, and that also resulted in terribly slow response times from dynamic content / servlets.

What gets me is that with the exact same set-up and configurations, I do not have this issues on Windows.

So in summary:

• Static content resolves and responds in less than 1ms.
• Dynamic content through servlets is terribly slow, up to 5 minutes.

I did look and see if it was my code. And no, it is not. It runs perfectly fine on Windows and Windows Server. It even runs fine when the server is on CentOS and pointing outwards, ie you would browse to a URL and not through the localhost.

---

To clarify, this problem occurs even on servlets that do not access any external resources, such as a servlet that only adds a few lines of HTML, or forwards the request to a static JSP page.

Answer 1

Well,

After some extensive digging and profiling, I found the solution:

I had a filter that would authenticate users, and set a cookie that changes for every request (prevents CSRF) but used a Java Utils SecureRandom to inject a secure random bit of info into a MD5 hashing algorithm along with some other goodies to spit out a decently secure, one-time use cookie.

Apparently, the version of CentOS my production server is using already includes the haveged daemon which keeps the /dev/random entropy topped up.

The issue is that SecureRandom on Linux requests the /dev/random and is blocking. When there isn't enough entropy, it can wait up to 25 seconds before returning.

Solution was to of course: install the haveged daemon. Problem solved.