You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David kerber <dc...@verizon.net> on 2009/05/11 15:27:04 UTC
Trouble parsing datetime strings
This is related to the performance issues discussed in the thread
"Performance with many small requests".
When I reworked my servlet to synchronize only on pieces that needed to
be synchronized, rather than on the entire request processing routine, I
am now throwing an exception when parsing a string into a java.util.Date
variable. It only happens occasionally, maybe once every few dozen to a
hundred or so requests, and I can't figure out why it doesn't work all
the time.
Declared at the class level, I have:
private static final SimpleDateFormat sdfFullDateTime = new
SimpleDateFormat( "yyyy-MM-dd HH:mm:ss" );
Then in the request processing method, I have
dateTimeStr = dateStr + " " + timeStr;
try {
dataDate = sdfFullDateTime.parse( dateTimeStr );
} catch ( Exception e ) {
writeLog( "Unable to parse dataTime string: '", dateTimeStr +
"': " + e );
}
(the try/catch is there only for debugging this issue), and in the log
I'm seeing:
2009-05-11 09:19:54: Unable to parse dateTime string: ': '2009-05-11
09:19:37': java.lang.NumberFormatException: For input string: ""'
Which I don't understand at all; dateDate (java.util.Date), dateStr
(String), timeStr (String) and dateTimeStr (String) are all declared in
the processing method, NOT at the class level.
Maybe I should move the declaration of the SimpleDateFormat into the
processing method? Or synchronize the date parse?
I'm kind of lost here; any help appreciated!!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble parsing datetime strings
Posted by Xie Xiaodong <xx...@gmail.com>.
Hello,
"Date formats are not synchronized. It is recommended to create separate
format instances for each thread. If multiple threads access a format
concurrently, it must be synchronized externally."
This is from the reference of JDK API.
2009/5/11 David kerber <dc...@verizon.net>
> This is related to the performance issues discussed in the thread
> "Performance with many small requests".
>
> When I reworked my servlet to synchronize only on pieces that needed to be
> synchronized, rather than on the entire request processing routine, I am now
> throwing an exception when parsing a string into a java.util.Date variable.
> It only happens occasionally, maybe once every few dozen to a hundred or so
> requests, and I can't figure out why it doesn't work all the time.
>
> Declared at the class level, I have:
>
> private static final SimpleDateFormat sdfFullDateTime = new
> SimpleDateFormat( "yyyy-MM-dd HH:mm:ss" );
>
>
> Then in the request processing method, I have
>
> dateTimeStr = dateStr + " " + timeStr;
> try {
> dataDate = sdfFullDateTime.parse( dateTimeStr );
> } catch ( Exception e ) {
> writeLog( "Unable to parse dataTime string: '", dateTimeStr + "': " +
> e );
> }
>
>
> (the try/catch is there only for debugging this issue), and in the log I'm
> seeing:
>
> 2009-05-11 09:19:54: Unable to parse dateTime string: ': '2009-05-11
> 09:19:37': java.lang.NumberFormatException: For input string: ""'
>
>
> Which I don't understand at all; dateDate (java.util.Date), dateStr
> (String), timeStr (String) and dateTimeStr (String) are all declared in the
> processing method, NOT at the class level.
>
> Maybe I should move the declaration of the SimpleDateFormat into the
> processing method? Or synchronize the date parse?
>
>
> I'm kind of lost here; any help appreciated!!
>
> Dave
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
Re: Trouble parsing datetime strings
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
On 5/11/2009 10:22 AM, David kerber wrote:
> From the quick
> reading I did, I imagine that will give me a bit of a performance hit
> compared to using ThreadLocal, but since I've never used the ThreadLocal
> pattern before, I didn't want to try implementing it on the fly, just to
> fix this issue. As for whether synchronization would be faster than
> local declaration, I'll try doing some benchmarking at some point.
I don't think that flyweighting SimpleDateFormat objects is worth it.
Most of the time spent in SDF object code will be in the parse() method,
not in the constructor.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoIiw4ACgkQ9CaO5/Lv0PBsQQCfRi9WI2eqPQ9j0k72FxadZueD
HnMAmwV/9rA9hOZVkUT01coUu4SX1czm
=Qqx7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble parsing datetime strings
Posted by David kerber <dc...@verizon.net>.
Konstantin Kolinko wrote:
...
> As the JavaDoc says
> http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html
>
> "Date formats are not synchronized. It is recommended to create
> separate format instances for each thread"
>
> You may either create a new instance of SimpleDateFormat each time, or
> add a synchronization around that part of code, or use a ThreadLocal
> (though ThreadLocal has its own caveats as the threads belong to
> Tomcat and are shared among applications).
>
> Without profiling you would not know which one of the ways I am
> mentioning is faster.
>
> Maybe I would start with creating a new instance each time, as GC for
> short-living objects seems to be cheap in recent JREs. Though without
> profiling you will not get the numbers.
>
Thanks, guys! Obviously I missed that part when I was looking for a fix
for this issue. For now, I took the simplest (from a coding standpoint)
way out, and moved the declaration of the SimpleDateFormat into each
method where it's used, and that has fixed the issue. From the quick
reading I did, I imagine that will give me a bit of a performance hit
compared to using ThreadLocal, but since I've never used the ThreadLocal
pattern before, I didn't want to try implementing it on the fly, just to
fix this issue. As for whether synchronization would be faster than
local declaration, I'll try doing some benchmarking at some point.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble parsing datetime strings
Posted by Konstantin Kolinko <kn...@gmail.com>.
2009/5/11 David kerber <dc...@verizon.net>:
> This is related to the performance issues discussed in the thread
> "Performance with many small requests".
>
> When I reworked my servlet to synchronize only on pieces that needed to be
> synchronized, rather than on the entire request processing routine, I am now
> throwing an exception when parsing a string into a java.util.Date variable.
> It only happens occasionally, maybe once every few dozen to a hundred or so
> requests, and I can't figure out why it doesn't work all the time.
>
> Declared at the class level, I have:
>
> private static final SimpleDateFormat sdfFullDateTime = new
> SimpleDateFormat( "yyyy-MM-dd HH:mm:ss" );
>
>
> Then in the request processing method, I have
>
> dateTimeStr = dateStr + " " + timeStr;
> try {
> dataDate = sdfFullDateTime.parse( dateTimeStr );
> } catch ( Exception e ) {
> writeLog( "Unable to parse dataTime string: '", dateTimeStr + "': " +
> e );
> }
>
>
> (the try/catch is there only for debugging this issue), and in the log I'm
> seeing:
>
> 2009-05-11 09:19:54: Unable to parse dateTime string: ': '2009-05-11
> 09:19:37': java.lang.NumberFormatException: For input string: ""'
>
>
> Which I don't understand at all; dateDate (java.util.Date), dateStr
> (String), timeStr (String) and dateTimeStr (String) are all declared in the
> processing method, NOT at the class level.
>
> Maybe I should move the declaration of the SimpleDateFormat into the
> processing method? Or synchronize the date parse?
>
>
> I'm kind of lost here; any help appreciated!!
>
> Dave
>
As the JavaDoc says
http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html
"Date formats are not synchronized. It is recommended to create
separate format instances for each thread"
You may either create a new instance of SimpleDateFormat each time, or
add a synchronization around that part of code, or use a ThreadLocal
(though ThreadLocal has its own caveats as the threads belong to
Tomcat and are shared among applications).
Without profiling you would not know which one of the ways I am
mentioning is faster.
Maybe I would start with creating a new instance each time, as GC for
short-living objects seems to be cheap in recent JREs. Though without
profiling you will not get the numbers.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Trouble parsing datetime strings
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David kerber [mailto:dckerber@verizon.net]
> Subject: Trouble parsing datetime strings
>
> Declared at the class level, I have:
>
> private static final SimpleDateFormat sdfFullDateTime = new
> SimpleDateFormat( "yyyy-MM-dd HH:mm:ss" );
Oops. Read the fine print for SimpleDateFormat:
"Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally."
Rather than introducing another bottleneck by synchronizing, you may be better off keeping separate SDF objects for each request. If this is your only webapp, you could get away with storing one per thread as a ThreadLocal.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org