You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by "Nick Gallardo (JIRA)" <ji...@apache.org> on 2009/07/20 16:15:14 UTC
[jira] Created: (WINK-114) Cache parsed Accept header content where
possible
Cache parsed Accept header content where possible
-------------------------------------------------
Key: WINK-114
URL: https://issues.apache.org/jira/browse/WINK-114
Project: Wink
Issue Type: Improvement
Components: Common
Affects Versions: 0.1
Reporter: Nick Gallardo
Fix For: 0.1
AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749215#action_12749215 ]
Bryant Luk commented on WINK-114:
---------------------------------
Let's go ahead and apply the patch. Thanks Michael.
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic-sync.patch, WINK-114-generic-sync2.patch, WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733947#action_12733947 ]
Bryant Luk commented on WINK-114:
---------------------------------
I think the generic header caches are pretty neat with the WINK-114-generic.patch. However, I was curious about the thread safety of this approach or any static WeakHashMap cache. This has been bugging me for a few hours since I was thinking that WeakHashMap (or any other non-synchronized/non-thread safe collection) had to be made thread safe for the caching.
I see issues like:
https://issues.apache.org/jira/browse/BEANUTILS-318
with static WeakHashMaps. I would think we would run into similar issues but maybe someone will be kind enough to correct me?
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733533#action_12733533 ]
Michael Elman commented on WINK-114:
------------------------------------
I see that both of you put the result of the StringUtils.fastSplit(value, ",") method to cache. Does it really take a lot of time?
To tell the truth, it's the first time I pay attention to this code, I think we should try first use precompiled pattern for the split. May be this with improve performance well enough to avoid the cache?
I'll attach a patch.
Regarding the cache limit: using WeakHashMap with Weak/SoftReferences should be preferred, so the objects will be available for garbage collection.
Regarding putting cache on TLS: I think it misses the point, since it will be available only on the same thread. Usually cache is designed to be resused by multiple threads.
One last thing: I think that this issue should be moved to 0.2
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.1
>
> Attachments: WINK-114-ThreadLocal.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-114) Cache parsed Accept header content where
possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Elman updated WINK-114:
-------------------------------
Attachment: WINK-114-use-pattern.patch
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.1
>
> Attachments: WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746680#action_12746680 ]
Bryant Luk commented on WINK-114:
---------------------------------
I'll need to get someone from performance team to take a look at this change but should hopefully have an answer soon.
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic-sync.patch, WINK-114-generic-sync2.patch, WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Elman reassigned WINK-114:
----------------------------------
Assignee: Michael Elman
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Assignee: Michael Elman
> Fix For: 0.2
>
> Attachments: WINK-114-generic-sync.patch, WINK-114-generic-sync2.patch, WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733972#action_12733972 ]
Bryant Luk commented on WINK-114:
---------------------------------
btw, I think AbstractJAXBProvider is thread safe and we should definitely use Weak/SoftReferences. just that this patch and then the comment in WINK-115 made me honestly wonder if there's a property of WeakHashMap in certain conditions that we could use where we didn't have to synchronize.
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734179#action_12734179 ]
Bryant Luk commented on WINK-114:
---------------------------------
I think some data corruption occurs when you have enough threads resizing the table.
Did a Google search and the clearest explanation I could find (admittedly for HashMap but again I don't know of any special WeakHashMap property):
http://mailinator.blogspot.com/2009/06/beautiful-race-condition.html
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-114) Cache parsed Accept header content where
possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Elman updated WINK-114:
-------------------------------
Attachment: WINK-114-generic-sync2.patch
One more proposal. A little bit generalized.
I've also applied the change to the cache in the ProvidersRegistry.
What do you think?
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic-sync.patch, WINK-114-generic-sync2.patch, WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733988#action_12733988 ]
Michael Elman commented on WINK-114:
------------------------------------
Hi Bryant,
synchronizing WeakHashMapis easy, you just need to wrap it with Collections.synchronizedMap():
Map map = Collections.synchronizedMap(new WeakHashMap());
Regarding https://issues.apache.org/jira/browse/BEANUTILS-318 - I don't see how can infinite loop occur in WINK-114-generic.patch implementation. Especially unless we don't override equals of header classes. (If we do override equals, it must not make any cache calls within the method, but actually this is not a synchronization issue)
The cache of course can be synchronized, but synchronizing it, meaning slowing it down.
Not synchronizing cache may result some header be created several times, but it won't effect correctness of the code, since the headers returned by the header delegates must be equivalent (not necessary equal, if equals() is not overridden).
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-114) Cache parsed Accept header content where
possible
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryant Luk updated WINK-114:
----------------------------
Attachment: WINK-114-ThreadLocal.patch
I think we should have a definite hard cache limit in cases where malicious clients, or just variety in the Accept headers, causes the cache to grow. Here's a stab at using a ThreadLocal LinkedHashMap LRU cache.
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.1
>
> Attachments: WINK-114-ThreadLocal.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-114) Cache parsed Accept header content where
possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Elman updated WINK-114:
-------------------------------
Attachment: WINK-114-generic.patch
Here comes another patch with a proposed generic solution for all header delegates.
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.1
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734011#action_12734011 ]
Michael Elman commented on WINK-114:
------------------------------------
I did some performance and synchronization tests on my machine:
In general it seems that there is almost no difference between using StringUtils.fastSplit and precompiled Pattern.
SpringUtils is a bit faster.
Cache for a single thread improves performance about 100 times (0.15 milliseconds for 10000 invocations instead of 12-13 milliseconds)
I also tried to run it multithreaded (up to 400 concurrent threads) and could not see any infinite loop problems.
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-114) Cache parsed Accept header content where
possible
Posted by "Nick Gallardo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Gallardo updated WINK-114:
-------------------------------
Fix Version/s: (was: 0.1)
0.2
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749245#action_12749245 ]
Hudson commented on WINK-114:
-----------------------------
Integrated in Wink-Trunk-JDK1.5 #123 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5/123/])
Cache parsed Accept header content where possible
See []
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Assignee: Michael Elman
> Fix For: 0.2
>
> Attachments: WINK-114-generic-sync.patch, WINK-114-generic-sync2.patch, WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-114) Cache parsed Accept header content where
possible
Posted by "Nick Gallardo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Gallardo updated WINK-114:
-------------------------------
Attachment: WINK-114.patch
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.1
>
> Attachments: WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-114) Cache parsed Accept header content where
possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Elman updated WINK-114:
-------------------------------
Attachment: WINK-114-generic-sync.patch
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic-sync.patch, WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737999#action_12737999 ]
Michael Elman commented on WINK-114:
------------------------------------
VERY interesting indeed. Thanks Bryant!
Well, it means that the HashMap must be always synchronized for multi-threaded. Collections.synchronizedMap() will solve this, but will reduce the efficiency of the cache.
Synchronizing the HeaderDelegatesCache using read/write locks may be a better solution.
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Fix For: 0.2
>
> Attachments: WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WINK-114) Cache parsed Accept header content
where possible
Posted by "Michael Elman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Elman resolved WINK-114.
--------------------------------
Resolution: Fixed
> Cache parsed Accept header content where possible
> -------------------------------------------------
>
> Key: WINK-114
> URL: https://issues.apache.org/jira/browse/WINK-114
> Project: Wink
> Issue Type: Improvement
> Components: Common
> Affects Versions: 0.1
> Reporter: Nick Gallardo
> Assignee: Michael Elman
> Fix For: 0.2
>
> Attachments: WINK-114-generic-sync.patch, WINK-114-generic-sync2.patch, WINK-114-generic.patch, WINK-114-ThreadLocal.patch, WINK-114-use-pattern.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation. This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time. Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution. Really I think there's a better way to do this. Presumably, there are other headers where the same thing applies. We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.