There is a comment in CookieManager.java which says:
// FIXME: SimpleDateFormat isn't thread-safe, so we need to synchronize
// access to it.
private static SimpleDateFormat dateFormat =
new SimpleDateFormat("EEEE, dd-MMM-yy HH:mm:ss zzz")
And from the Javadoc 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.>>
The bug details show that there has been some work done towards removing this
restriction, but this has not been completed, as far
as I can tell.
The dateFormat instances could be cached using ThreadLocal(), or maybe it would be
simpler to synchronize the accesses to
dateFormat?
That should make the errors go away, or have I misunderstood something?
S.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 14, 2003 5:24 PM
Subject: cvs commit: jakarta-jmeter/src/core/org/apache/jmeter/gui/util JDateField.java
> jsalvata 2003/12/14 09:24:11
>
> Modified: src/protocol/http/org/apache/jmeter/protocol/http/control
> CookieManager.java
> src/core/org/apache/jmeter/gui/util JDateField.java
> Log:
> Workaround JDK bug
> http://developer.java.sun.com/developer/bugParade/bugs/4699765.html
>
> PR: 22985
>
> Revision Changes Path
> 1.20 +20 -24
> jakarta-jmeter/src/protocol/http/org/apache/jmeter/protocol/http/control/CookieManager.java
>
> Index: CookieManager.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-jmeter/src/protocol/http/org/apache/jmeter/protocol/http/control/CookieManager.java,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -u -r1.19 -r1.20
> --- CookieManager.java 11 Dec 2003 13:07:15 -0000 1.19
> +++ CookieManager.java 14 Dec 2003 17:24:11 -0000 1.20
> @@ -300,29 +300,6 @@
> return dateFormat.format(new Date(dateLong));
> }
>
> - public long convertDateFormatStrToLong(String dateStr)
> - {
> - long time = 0;
> -
> - try
> - {
> - Date date = dateFormat.parse(dateStr);
> - time = date.getTime();
> - }
> - catch (ParseException e)
> - {
> - // ERROR!!!
> - // Later, display error dialog? For now, we have
> - // to specify a number that can be converted to
> - // a Date. So, I chose 0. The Date will appear as
> - // the beginning of the Epoch (Jan 1, 1970 00:00:00 GMT)
> - time = 0;
> - log.error("DateFormat.ParseException: ", e);
> - }
> -
> - return time;
> - }
> -
> /**
> * Find cookies applicable to the given URL and build the Cookie header from
> * them.
> @@ -415,12 +392,31 @@
> String expires = nvp.substring(index + 1);
> Date date = dateFormat.parse(expires);
> if (date.getTime() > System.currentTimeMillis())
> + //TODO: why this conditional? If it's expired, it's
> + // expired!
> {
> newCookie.setExpires(date.getTime());
> }
> }
> catch (ParseException pe)
> {
> + // This means the cookie did not come in the proper format.
> + // Log an error and don't set an expiration time:
> + log.error("Couldn't parse Cookie expiration time.", pe);
> + }
> + catch (Exception e)
> + {
> + // DateFormat.parse() has been known to throw various
> + // unchecked exceptions in the past, and does still do that
> + // occasionally at the time of this writing (1.4.2 JDKs).
> + // E.g. see
> http://developer.java.sun.com/developer/bugParade/bugs/4699765.html
> + //
> + // As a workaround for such issues we will catch all
> + // exceptions and react just as we did for ParseException
> + // above:
> + log.error(
> + "Couln't parse Cookie expiration time: likely JDK bug.",
> + e);
> }
> }
> else if (key.equalsIgnoreCase("domain"))
>
>
>
> 1.5 +13 -3
> jakarta-jmeter/src/core/org/apache/jmeter/gui/util/JDateField.java
>
> Index: JDateField.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-jmeter/src/core/org/apache/jmeter/gui/util/JDateField.java,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -r1.4 -r1.5
> --- JDateField.java 30 Oct 2003 21:47:23 -0000 1.4
> +++ JDateField.java 14 Dec 2003 17:24:11 -0000 1.5
> @@ -151,6 +151,16 @@
> {
> return new Date();
> }
> + catch (Exception e)
> + {
> + // DateFormat.parse has some bugs (up to JDK 1.4.2) by which it
> + // throws unchecked exceptions. E.g. see:
> + // http://developer.java.sun.com/developer/bugParade/bugs/4699765.html
> + //
> + // To avoid problems with such situations, we'll catch all
> + // exceptions here and act just as for ParseException above:
> + return new Date();
> + }
> }
>
> /*
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
