On 19 August 2010 17:50, Chris Hegarty <chris.hega...@oracle.com> wrote:
> gustav trede wrote: > >> >> On 18 August 2010 13:22, Michael McMahon >> <michael.x.mcma...@oracle.com<mailto: >> michael.x.mcma...@oracle.com>> wrote: >> >> gustav trede wrote: >> >> >> On 18 August 2010 12:10, Chris Hegarty <chris.hega...@oracle.com >> <mailto:chris.hega...@oracle.com> >> <mailto:chris.hega...@oracle.com >> <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/<http://cr.openjdk.java.net/%7Echegar/6965924/webrev.00/webrev/> >> <http://cr.openjdk.java.net/%7Echegar/6965924/webrev.00/webrev/> >> <http://cr.openjdk.java.net/%7Echegar/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 /. >> > > We use ThreadLocal to store the formatter for the HttpServer > implementation, com.sun.net.httpserver, see 6967684 "httpserver using a non > thread-safe SimpleDateFormat" [1]. The threads creating the HTTP timestamps > are part of an execurtorService and will need a timestamp per response. > These threads will not be used for anything else, and are most probably > going to handle many requests. I think adding a threadLocal makes sense for > these. > > For HttpCookie, it is client side and a thread may only ever handle a few > cookies for its lifetime. I think adding the overhead of three formatters > may just be wasteful since the thread may never do any more than a few HTTP > requests. > > Are you ok with this change? > > Sounds ok to me, considering how the current overall design and public API is, the hands are a bit tied for radical changes. regards gustav trede
