Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

[Chris Hegarty]

Michael,

java.net.HttpCookie uses static SimpleDateFormat which is not thread 
safe. I think the best solution here is to simply create local 
SimpleDateFormat as needed.


Webrev:
  http://cr.openjdk.java.net/~chegar/6965924/webrev.00/webrev/

Thanks,
-Chris.

Re: Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

[gustav trede]

On 18 August 2010 12:10, Chris Hegarty  wrote:

> Michael,
>
> java.net.HttpCookie uses static SimpleDateFormat which is not thread safe.
> I think the best solution here is to simply create local SimpleDateFormat as
> needed.
>
> Webrev:
>  
> http://cr.openjdk.java.net/~chegar/6965924/webrev.00/webrev/
>
>
Why not use a threadlocal dateformater ?.
For certain cases Its also viable to exploit the fact that its enough to
generate a new value once per second for HTTP timestamps.
Even if its not "needed", it would imo be nice if the JDK code itself could
somehow act as reference / good examples of how to THINK(design) and
implement.


regards
   gustav trede

Re: Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

[Chris Hegarty]

On 18/08/2010 11:28, gustav trede wrote:


On 18 August 2010 12:10, Chris Hegarty mailto:chris.hega...@oracle.com>> wrote:

Michael,

java.net.HttpCookie uses static SimpleDateFormat which is not thread
safe. I think the best solution here is to simply create local
SimpleDateFormat as needed.

Webrev:
http://cr.openjdk.java.net/~chegar/6965924/webrev.00/webrev/



Why not use a threadlocal dateformater ?.


I guess it depends on the use of HttpCookie. In the JDK HttpCookie is 
only used to parse cookies sent in a HTTP response. For this type of 
application potentially keeping three formatters per thread seems like a 
waste. This, of course, is only one use.



For certain cases Its also viable to exploit the fact that its enough to
generate a new value once per second for HTTP timestamps.


I don't understand. Are you using HttpCookie in a server type context?

-Chris.


Even if its not "needed", it would imo be nice if the JDK code itself
could somehow act as reference / good examples of how to THINK(design)
and implement.


regards
gustav trede

Re: Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

[gustav trede]

On 18 August 2010 12:47, Chris Hegarty  wrote:

> On 18/08/2010 11:28, gustav trede wrote:
>
>>
>> On 18 August 2010 12:10, Chris Hegarty > > wrote:
>>
>>Michael,
>>
>>java.net.HttpCookie uses static SimpleDateFormat which is not thread
>>safe. I think the best solution here is to simply create local
>>SimpleDateFormat as needed.
>>
>>Webrev:
>>
>> http://cr.openjdk.java.net/~chegar/6965924/webrev.00/webrev/
>>
>>
>>
>>
>> Why not use a threadlocal dateformater ?.
>>
>
> I guess it depends on the use of HttpCookie. In the JDK HttpCookie is only
> used to parse cookies sent in a HTTP response. For this type of application
> potentially keeping three formatters per thread seems like a waste. This, of
> course, is only one use.
>
>
>  For certain cases Its also viable to exploit the fact that its enough to
>> generate a new value once per second for HTTP timestamps.
>>
>
> I don't understand. Are you using HttpCookie in a server type context?
>
> No, i use my custom server code, but i do use the concept of generating
HTTP DATE:  header timestamp values once per second by updating the per
cached file/standard responses directbytebuffers using only volatile
somantics.


-Chris.
>
>
>  Even if its not "needed", it would imo be nice if the JDK code itself
>> could somehow act as reference / good examples of how to THINK(design)
>> and implement.
>>
>>
>> regards
>>gustav trede
>>
>

Re: Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

[Michael McMahon]

gustav trede wrote:


On 18 August 2010 12:10, Chris Hegarty > wrote:


Michael,

java.net.HttpCookie uses static SimpleDateFormat which is not
thread safe. I think the best solution here is to simply create
local SimpleDateFormat as needed.

Webrev:
 http://cr.openjdk.java.net/~chegar/6965924/webrev.00/webrev/



Why not use a threadlocal dateformater ?.

perhaps ...
For certain cases Its also viable to exploit the fact that its enough 
to generate a new value once per second for HTTP timestamps.
Even if its not "needed", it would imo be nice if the JDK code itself 
could somehow act as reference / good examples of how to THINK(design) 
and implement.


I suspect you're looking at this from a server perspective. This code is 
involved with parsing

of incoming cookies. So, the generation of timestamps isn't being done here.

- Michael.


regards
   gustav trede

Re: Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

[gustav trede]

On 18 August 2010 13:22, Michael McMahon wrote:

> gustav trede wrote:
>
>>
>> On 18 August 2010 12:10, Chris Hegarty > chris.hega...@oracle.com>> wrote:
>>
>>Michael,
>>
>>java.net.HttpCookie uses static SimpleDateFormat which is not
>>thread safe. I think the best solution here is to simply create
>>local SimpleDateFormat as needed.
>>
>>Webrev:
>> 
>> http://cr.openjdk.java.net/~chegar/6965924/webrev.00/webrev/
>>
>>
>>
>>
>> Why not use a threadlocal dateformater ?.
>>
> perhaps ...
>
>  For certain cases Its also viable to exploit the fact that its enough to
>> generate a new value once per second for HTTP timestamps.
>> Even if its not "needed", it would imo be nice if the JDK code itself
>> could somehow act as reference / good examples of how to THINK(design) and
>> implement.
>>
>>  I suspect you're looking at this from a server perspective. This code is
> involved with parsing
> of incoming cookies. So, the generation of timestamps isn't being done
> here.
>
> Yes i am quite server focused =), servers can act as http clients too,
different kind of intermediate logic etc.
Anyhow, my apologies for wasting your time with this not so important issue,
my brain just pings on code it finds strange /.


regards
  gustav trede

hg: jdk7/tl/jdk: 2 new changesets

[kelly . ohair]

Changeset: 01dec49e95c4
Author:ohair
Date:  2010-08-18 13:46 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/01dec49e95c4

6974005: Use of cygpath in Makefile logic needs to silence error messages
Reviewed-by: mchung

! make/common/shared/Defs-windows.gmk

Changeset: 42bfa43f2ae1
Author:ohair
Date:  2010-08-18 13:46 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42bfa43f2ae1

6932743: Makefiles not parsing version strings with - from uname -r
Reviewed-by: mchung

! make/common/shared/Defs.gmk

hg: jdk7/tl/jdk: 6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default.

[weijun . wang]

Changeset: 4abd65f04638
Author:weijun
Date:  2010-08-19 11:26 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4abd65f04638

6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default.
Reviewed-by: valeriep

! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
+ test/sun/security/krb5/BadKdcDefaultValue.java

hg: jdk7/tl/jdk: 6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException

[weijun . wang]

Changeset: 95bb147c7c33
Author:weijun
Date:  2010-08-19 12:24 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/95bb147c7c33

6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException
Reviewed-by: vinnie, xuelei

! src/share/classes/com/sun/jndi/ldap/Connection.java