[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2009-02-15 Thread Mark Lassau (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673771#action_12673771
 ] 

Mark Lassau commented on LUCENE-1472:
-

An update for anyone interested:

The test run that showed this contention suffered even worse contention in 
another component of our application.
Since we have fixed that component, we have no longer observed contention in 
DateTools.stringToDate(). 

For that reason, this issue is not now considered a priority for us.

> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
> Fix For: 2.9
>
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to SimpleDateFormat.parse() is *synchronized* because 
> SimpleDateFormat is not thread safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-12-02 Thread Michael McCandless (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652336#action_12652336
 ] 

Michael McCandless commented on LUCENE-1472:


I agree: ThreadLocal, despite its problems, is probably the best solution here. 
 The memory cost ought to be tiny.

We could also use CloseableThreadLocal (which works around the problems of 
ThreadLocal), and then allow DateTools to be instantiated, and add a close() 
method to it (vs the all-static methods we have today).  This way the 
application could close the DateTools instance and reliably free up the tiny 
amount of memory used.

> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to SimpleDateFormat.parse() is *synchronized* because 
> SimpleDateFormat is not thread safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-12-01 Thread robert engels (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652221#action_12652221
 ] 

robert engels commented on LUCENE-1472:
---

The last comment was tested using Java 5.

It is my understanding that in Java 6, synchronization has become even cheaper 
- although object creation is cheaper as well - although 99% of the 
instantiation time of SimpleDateFormat is in the init code, not the object 
creation.

I know there has been a lot of discussion of the "problems" with 
ThreadLocals... I've been a part of most of them :) - but for these very small 
objects, the typical ThreadLocal memory issues don't really apply.



> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to SimpleDateFormat.parse() is *synchronized* because 
> SimpleDateFormat is not thread safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-12-01 Thread robert engels (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652220#action_12652220
 ] 

robert engels commented on LUCENE-1472:
---

If you review the source for SimpleDateFormat you will see that it internally 
performs some synchronization during initialization anyway (uses some 
Hashtables), and  also that the initialization cost is pretty high (lots of 
code), so a static sync'd copy is probably best.

Outside of that, the ThreadLocal is the way to go.

My tests shows that the instantiation time is 2x longer than the typical parse 
time.



> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to SimpleDateFormat.parse() is *synchronized* because 
> SimpleDateFormat is not thread safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-12-01 Thread Mark Lassau (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652206#action_12652206
 ] 

Mark Lassau commented on LUCENE-1472:
-

My original thought was ThreadLocal, but I tend to try and avoid these where 
possible.

I wanted to test the speed on creating a new Calendar (rather than 
SimpleDateFormat) for each request, but was worried about the instantiation 
overhead.
Daniel's comment above reinforces this concern to some extent, so we'll have to 
wait and compare benchmarks.

> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to SimpleDateFormat.parse() is *synchronized* because 
> SimpleDateFormat is not thread safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-12-01 Thread Doug Cutting (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652194#action_12652194
 ] 

Doug Cutting commented on LUCENE-1472:
--

ThreadLocal?

> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to SimpleDateFormat.parse() is *synchronized* because 
> SimpleDateFormat is not thread safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-12-01 Thread Daniel Naber (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652085#action_12652085
 ] 

Daniel Naber commented on LUCENE-1472:
--

Could you try changing the code to create a new object every time and then run 
your load test again? We original did that but it was slower, at least 
according to this commit comment from two years ago:

"Don't re-create SimpleDateFormat objects, use static ones instead. Gives about 
a 2x performance increase in a micro benchmark."


> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to SimpleDateFormat.parse() is *synchronized* because 
> SimpleDateFormat is not thread safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-11-30 Thread Mark Lassau (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651900#action_12651900
 ] 

Mark Lassau commented on LUCENE-1472:
-

[SimpleDateFormat 
javadoc|http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html]:

{quote}
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.
{quote}


> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to parse is *synchronized* because SimpleDateFormat is not thread 
> safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-1472) DateTools.stringToDate() can cause lock contention under load

2008-11-30 Thread Mark Lassau (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651899#action_12651899
 ] 

Mark Lassau commented on LUCENE-1472:
-

The following methods would potentially suffer contention as well depending on 
usage patterns of the particular app:
* stringToTime()
* dateToString()
* timeToString()


> DateTools.stringToDate() can cause lock contention under load
> -
>
> Key: LUCENE-1472
> URL: https://issues.apache.org/jira/browse/LUCENE-1472
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.3.2
>Reporter: Mark Lassau
>Priority: Minor
>
> Load testing our application (the JIRA Issue Tracker) has shown that threads 
> spend a lot of time blocked in DateTools.stringToDate().
> The stringToDate() method uses a singleton SimpleDateFormat object to parse 
> the dates.
> Each call to parse is *synchronized* because SimpleDateFormat is not thread 
> safe.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]