SimpleDateFormat can lock a thread when used in combination with c3po
Details
- Type:
Bug - Status:
Closed - Priority:
Minor - Resolution: Fixed
- Affects Version/s:5.1.2, 5.2.3
- Fix Version/s: None
- Component/s: None
- Labels:None
- Branch Version/s:5.1.x, 5.2.x
- Backported to Branch:Committed
- Similar Issues:None
Description
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at java.util.ResourceBundle.beginLoading(ResourceBundle.java:1484)
java.lang.Thread.State: BLOCKED (on object monitor)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:524)
They both seem to be locking the thread. As threads are locked up, Tomcat runs out of them, so the server stops responding.
The fix is to use commons lang's FastDateFormat instead of DateFormat
Previously, we called new java.textSimpleDateFormat directly, or used com.liferay.portal.kernel.util.DateFormats to get date instances.
Now, we have two factory utils:
com.liferay.portal.kernel.util.FastDateFormatFactoryUtil and com.liferay.portal.kernel.util.DateFormatFactoryUtil. The former returns back a "java.text.Format" and the latter returns back a "java.text.DateFormat". That means the former does not have methods like "parse", but is many times faster.
So as a general rule of thumb, use FastDateFormatFactoryUtil, and if it doesn't have all the methods you need, then use DateFormatFactoryUtil.
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at java.util.ResourceBundle.beginLoading(ResourceBundle.java:1484)
- locked <0x00002aaacefb8330> (a java.lang.Thread)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1343)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:832)
at sun.util.resources.LocaleData$1.run(LocaleData.java:127)
at java.security.AccessController.doPrivileged(Native Method)
at sun.util.resources.LocaleData.getBundle(LocaleData.java:125)
at sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:113)
at java.text.DateFormatSymbols.cacheLookup(DateFormatSymbols.java:578)
at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:587)
at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:123)
at java.text.DateFormatSymbols.getInstance(DateFormatSymbols.java:297)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:554)
at java.text.DateFormat.get(DateFormat.java:707)
at java.text.DateFormat.getDateInstance(DateFormat.java:482)
at com.liferay.portal.kernel.util.DateFormats.getDate(DateFormats.java:42)
java.lang.Thread.State: BLOCKED (on object monitor)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:524)
They both seem to be locking the thread. As threads are locked up, Tomcat runs out of them, so the server stops responding.
The fix is to use commons lang's FastDateFormat instead of DateFormat
Previously, we called new java.textSimpleDateFormat directly, or used com.liferay.portal.kernel.util.DateFormats to get date instances.
Now, we have two factory utils:
com.liferay.portal.kernel.util.FastDateFormatFactoryUtil and com.liferay.portal.kernel.util.DateFormatFactoryUtil. The former returns back a "java.text.Format" and the latter returns back a "java.text.DateFormat". That means the former does not have methods like "parse", but is many times faster.
So as a general rule of thumb, use FastDateFormatFactoryUtil, and if it doesn't have all the methods you need, then use DateFormatFactoryUtil.
Nessun commento:
Posta un commento