[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186758#comment-15186758 ] Alessio Soldano commented on CXF-6825: -- Of course you're getting better performances without the synchronized blocks there, but I'd say those are needed because of the clearDefaultBusForAnyThread method. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[
https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186771#comment-15186771
]
Yotam Madem commented on CXF-6825:
--
Did you take a look at my fix proposal?
I do the locking only when I need to change something, then I check the value
again inside the synchronized block
I don't see any point in doing
synchronized(this){
h = THREAD_BUSSES.get(cur);
}
alone.
> Performance bottle neck due to synchronize block on each read
> -
>
> Key: CXF-6825
> URL: https://issues.apache.org/jira/browse/CXF-6825
> Project: CXF
> Issue Type: Bug
> Components: Bus, JAX-RS
>Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6
> Environment: All environments
>Reporter: Yotam Madem
> Fix For: 3.2.0, 3.1.6
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In our (IBM MobileFirst foundation) performance tests it is possible to see
> that many threads are stuck at:
> "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800
> nid=0x31fc waiting for monitor entry [0x7f12bfffd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120)
> - waiting to lock <0xc6b99020> (a java.util.WeakHashMap)
> at
> org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202)
>
> (We use version 3.1.0)
> I did a test fix locally and it seems to resolve our problem so I submitted 2
> pull requests:
> for 3.1.6: https://github.com/apache/cxf/pull/119
> for 3.2.0: https://github.com/apache/cxf/pull/120
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6825) Performance bottle neck due to synchronize block on each read
[
https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186771#comment-15186771
]
Yotam Madem edited comment on CXF-6825 at 3/9/16 8:53 AM:
--
Did you take a look at my fix proposal?
I do the locking only when I need to change something, then I check the value
again inside the synchronized block
I don't see any point in doing
```
synchronized(this){
h = THREAD_BUSSES.get(cur);
}
```
alone.
Please look at the pull request
was (Author: yotammadem):
Did you take a look at my fix proposal?
I do the locking only when I need to change something, then I check the value
again inside the synchronized block
I don't see any point in doing
synchronized(this){
h = THREAD_BUSSES.get(cur);
}
alone.
> Performance bottle neck due to synchronize block on each read
> -
>
> Key: CXF-6825
> URL: https://issues.apache.org/jira/browse/CXF-6825
> Project: CXF
> Issue Type: Bug
> Components: Bus, JAX-RS
>Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6
> Environment: All environments
>Reporter: Yotam Madem
> Fix For: 3.2.0, 3.1.6
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In our (IBM MobileFirst foundation) performance tests it is possible to see
> that many threads are stuck at:
> "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800
> nid=0x31fc waiting for monitor entry [0x7f12bfffd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120)
> - waiting to lock <0xc6b99020> (a java.util.WeakHashMap)
> at
> org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202)
>
> (We use version 3.1.0)
> I did a test fix locally and it seems to resolve our problem so I submitted 2
> pull requests:
> for 3.1.6: https://github.com/apache/cxf/pull/119
> for 3.2.0: https://github.com/apache/cxf/pull/120
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186794#comment-15186794 ] Yotam Madem commented on CXF-6825: -- Ok, I see what you mean, If I call to h = THREAD_BUSSES.get(cur); during the operation of clearDefaultBusForAnyThread I can get something that it is about to be removed. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186797#comment-15186797 ] Alessio Soldano commented on CXF-6825: -- Right, that's what I meant, however the check you have on the volatile stale flag might help. Let's wait for Dan opinion here. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FEDIZ-157) SAMLResponse Handler uses URL instead of Realm name for issuer validation
[
https://issues.apache.org/jira/browse/FEDIZ-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Bernhardt resolved FEDIZ-157.
-
Resolution: Fixed
> SAMLResponse Handler uses URL instead of Realm name for issuer validation
> -
>
> Key: FEDIZ-157
> URL: https://issues.apache.org/jira/browse/FEDIZ-157
> Project: CXF-Fediz
> Issue Type: Bug
> Components: IDP
>Affects Versions: 1.2.2
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
> Fix For: 1.3.0
>
>
> The {{TrustedIdpSAMLProtocolHandler}} uses the {{SAMLSSOResponseValidator}}
> to validate the issuer name within the {{SAMLResponse}}.
> For this validation the configured 3rd party URL is used. This is an error,
> because the redirect URL for the {{SAMLRequest}} does not need to be equal or
> even similar to the issuer name within the {{SAMLResponse}}.
> The 3rd party realm name should be applicable instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FEDIZ-157) SAMLResponse Handler uses URL instead of Realm name for issuer validation
[
https://issues.apache.org/jira/browse/FEDIZ-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186807#comment-15186807
]
Jan Bernhardt commented on FEDIZ-157:
-
A new property is now available for a trusted IDP configuration {{issuer}}. If
set this property will be used for issuer name validation. If it is not set,
the {{url}} parameter will be used as before to ensure backward compatibility.
> SAMLResponse Handler uses URL instead of Realm name for issuer validation
> -
>
> Key: FEDIZ-157
> URL: https://issues.apache.org/jira/browse/FEDIZ-157
> Project: CXF-Fediz
> Issue Type: Bug
> Components: IDP
>Affects Versions: 1.2.2
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
> Fix For: 1.3.0
>
>
> The {{TrustedIdpSAMLProtocolHandler}} uses the {{SAMLSSOResponseValidator}}
> to validate the issuer name within the {{SAMLResponse}}.
> For this validation the configured 3rd party URL is used. This is an error,
> because the redirect URL for the {{SAMLRequest}} does not need to be equal or
> even similar to the issuer name within the {{SAMLResponse}}.
> The 3rd party realm name should be applicable instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FEDIZ-159) whr propagation can be disabled
Jan Bernhardt created FEDIZ-159: --- Summary: whr propagation can be disabled Key: FEDIZ-159 URL: https://issues.apache.org/jira/browse/FEDIZ-159 Project: CXF-Fediz Issue Type: Improvement Components: IDP Affects Versions: 1.2.2 Reporter: Jan Bernhardt The whr parameter is used by the IDP to detect which IDP should be used by the user for authentication (home realm / requestor IDP). Usually this whr parameter is useful for the redirected IDP to ensure that this IDP feels responsible for the user or in cases that the redirected IDP is also just a link in a bigger chain of IDPs. However some IDPs might not be able to handle the whr parameter correctly and therefore are causing problems. If adding the whr parameter in the redirect URL can be disabled (should be enabled by default), this would provide a better flexibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186834#comment-15186834 ] Yotam Madem edited comment on CXF-6825 at 3/9/16 9:31 AM: -- Just another question, The tests failures in my pull request build: https://builds.apache.org/job/CXF-Trunk-PR/43/ Doesn't really seem to be related to my changes... Do you happen to know if those tests are unstable in general? was (Author: yotammadem): Just another question, The tests failures in my pull request build: https://builds.apache.org/job/CXF-Trunk-PR/lastBuild/ Doesn't really seem to be related to my changes... Do you happen to know if those tests are unstable in general? > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186834#comment-15186834 ] Yotam Madem commented on CXF-6825: -- Just another question, The tests failures in my pull request build: https://builds.apache.org/job/CXF-Trunk-PR/lastBuild/ Doesn't really seem to be related to my changes... Do you happen to know if those tests are unstable in general? > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186877#comment-15186877 ] Alessio Soldano commented on CXF-6825: -- Generally speaking, unfortunately there are quite often environmental/transient failures on Jenkins run. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[
https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186902#comment-15186902
]
Yotam Madem commented on CXF-6825:
--
I was thinking about it again
Let's look at the code we had before my change:
synchronized (THREAD_BUSSES) {
h = THREAD_BUSSES.get(cur);
}
<>
if (h == null || h.stale) {
In case that context switch happens at this point and
clearDefaultBusForAnyThread is working, it will lead to the exact same results
as if we didn't use the synchronized block.
Still, the "if (h == null || h.stale)" can happen during the operation of
clearDefaultBusForAnyThread because it is out of any synchronized block.
> Performance bottle neck due to synchronize block on each read
> -
>
> Key: CXF-6825
> URL: https://issues.apache.org/jira/browse/CXF-6825
> Project: CXF
> Issue Type: Bug
> Components: Bus, JAX-RS
>Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6
> Environment: All environments
>Reporter: Yotam Madem
> Fix For: 3.2.0, 3.1.6
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In our (IBM MobileFirst foundation) performance tests it is possible to see
> that many threads are stuck at:
> "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800
> nid=0x31fc waiting for monitor entry [0x7f12bfffd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120)
> - waiting to lock <0xc6b99020> (a java.util.WeakHashMap)
> at
> org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202)
>
> (We use version 3.1.0)
> I did a test fix locally and it seems to resolve our problem so I submitted 2
> pull requests:
> for 3.1.6: https://github.com/apache/cxf/pull/119
> for 3.2.0: https://github.com/apache/cxf/pull/120
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6826) Cache MediaTypeHeaderProvider.valueOf(String mType) results
Alessio Soldano created CXF-6826: Summary: Cache MediaTypeHeaderProvider.valueOf(String mType) results Key: CXF-6826 URL: https://issues.apache.org/jira/browse/CXF-6826 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Alessio Soldano MediaTypeHeaderProvider.valueOf(String mType) ends up being called a lot with the same parameter values, as those are basically the contents of the @Produce annotations on resources. Each request ends up into the same invocation, which is cpu and memory intensive. It might make sense to add a map in the MediaTypeHeaderProvider to store the result of the static valueOf method invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6826) Cache MediaTypeHeaderProvider.valueOf(String mType) results
[ https://issues.apache.org/jira/browse/CXF-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186956#comment-15186956 ] ASF GitHub Bot commented on CXF-6826: - GitHub user asoldano opened a pull request: https://github.com/apache/cxf/pull/121 [CXF-6826] Cache MediaTypeHeaderProvider.valueOf results You can merge this pull request into a Git repository by running: $ git pull https://github.com/asoldano/cxf CXF-6826 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/121.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #121 commit b5c5c07f363498c0d84c57cbc3f05135bb04104c Author: Alessio Soldano Date: 2016-03-09T11:09:11Z [CXF-6826] Cache MediaTypeHeaderProvider.valueOf results > Cache MediaTypeHeaderProvider.valueOf(String mType) results > --- > > Key: CXF-6826 > URL: https://issues.apache.org/jira/browse/CXF-6826 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Alessio Soldano > > MediaTypeHeaderProvider.valueOf(String mType) ends up being called a lot with > the same parameter values, as those are basically the contents of the > @Produce annotations on resources. Each request ends up into the same > invocation, which is cpu and memory intensive. > It might make sense to add a map in the MediaTypeHeaderProvider to store the > result of the static valueOf method invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6826) Cache MediaTypeHeaderProvider.valueOf(String mType) results
[ https://issues.apache.org/jira/browse/CXF-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186957#comment-15186957 ] Alessio Soldano commented on CXF-6826: -- Pull request: https://github.com/apache/cxf/pull/121 > Cache MediaTypeHeaderProvider.valueOf(String mType) results > --- > > Key: CXF-6826 > URL: https://issues.apache.org/jira/browse/CXF-6826 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Alessio Soldano > > MediaTypeHeaderProvider.valueOf(String mType) ends up being called a lot with > the same parameter values, as those are basically the contents of the > @Produce annotations on resources. Each request ends up into the same > invocation, which is cpu and memory intensive. > It might make sense to add a map in the MediaTypeHeaderProvider to store the > result of the static valueOf method invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187040#comment-15187040 ] ASF GitHub Bot commented on CXF-6825: - Github user dkulp commented on the pull request: https://github.com/apache/cxf/pull/119#issuecomment-194280245 You HAVE to have the lock on the get as well as the put. During the put, the entire map is allowed to be restructured internally (buckets recalculated, etc... if the map grows) which would make anything going on in the get invalid. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187060#comment-15187060 ] ASF GitHub Bot commented on CXF-6825: - Github user yotammadem commented on the pull request: https://github.com/apache/cxf/pull/119#issuecomment-194287251 So what do you suggest to do? Maybe we should use some other data structure (one of the concurrent ones)? > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187075#comment-15187075 ] ASF GitHub Bot commented on CXF-6825: - Github user yotammadem commented on the pull request: https://github.com/apache/cxf/pull/119#issuecomment-194292794 What do you mean by invalid? I understand that it can return null because it didn't find the thread in the map but do you think it is really possible for it to return something else? (in the case of null my code is treating it well) > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187145#comment-15187145 ] Daniel Kulp commented on CXF-6825: -- Just thinking. Possibly grab: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/experimental/jsr166/src/jsr166y/ConcurrentReferenceHashMap.java and stick that in core/src/main/java/org/apache/cxf/common/util/ and use that. That would avoid all the locking entirely (put and get). > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187206#comment-15187206 ] Alessio Soldano commented on CXF-6825: -- I can do some tries with it in the next days, was thinking about the same in the past but never actually tried. Yotam, perhaps you can verify if this helps in your scenario too. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187262#comment-15187262 ] Yotam Madem commented on CXF-6825: -- Sure, I will be happy to verify Actually I don't mind to do it myself and let you review > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187275#comment-15187275 ] Alessio Soldano commented on CXF-6825: -- Ok, thanks, I'll review your proposal then. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
[ https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187303#comment-15187303 ] Yotam Madem commented on CXF-6825: -- Just checked this ConcurrentReferenceHashMap.java. It has some important tuning parameters in the constructor such as: * @param initialCapacity the initial capacity. The implementation * performs internal sizing to accommodate this many elements. * @param loadFactor the load factor threshold, used to control resizing. * Resizing may be performed when the average number of elements per * bin exceeds this threshold. * @param concurrencyLevel the estimated number of concurrently * updating threads. The implementation performs internal sizing * to try to accommodate this many threads. Do you think we should externalize those so that the CXF user will be able to change their values? Looks like this is may be a good thing to do. In most cases, customers know the number of threads which are going to access their system (this can be a good value for initialSize) and the concurrencyLevel is also measurable. > Performance bottle neck due to synchronize block on each read > - > > Key: CXF-6825 > URL: https://issues.apache.org/jira/browse/CXF-6825 > Project: CXF > Issue Type: Bug > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6 > Environment: All environments >Reporter: Yotam Madem > Fix For: 3.2.0, 3.1.6 > > Original Estimate: 24h > Remaining Estimate: 24h > > In our (IBM MobileFirst foundation) performance tests it is possible to see > that many threads are stuck at: > "LargeThreadPool-thread-1505" daemon prio=10 tid=0x7f10f020b800 > nid=0x31fc waiting for monitor entry [0x7f12bfffd000] >java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120) > - waiting to lock <0xc6b99020> (a java.util.WeakHashMap) > at > org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202) > > (We use version 3.1.0) > I did a test fix locally and it seems to resolve our problem so I submitted 2 > pull requests: > for 3.1.6: https://github.com/apache/cxf/pull/119 > for 3.2.0: https://github.com/apache/cxf/pull/120 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6826) Cache MediaTypeHeaderProvider.valueOf(String mType) results
[ https://issues.apache.org/jira/browse/CXF-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187887#comment-15187887 ] Sergey Beryozkin commented on CXF-6826: --- Hi Alessio, thanks, it is tempting to optimize it this way :-) but I have my doubts right now. We can have a leak here if we have users doing media type versioning, ex, "a/b+v1", "a/b+v2" or composite subtypes in general or using media type parameters, in addition to the type/subtype. Can we have: a non-static map as as we have a single RuntimeDelegateImpl caching a media type header provider and some standard collection with FIFO, say as soon as the size reaches say 20 MT variations (as might be the case with parameters or composite subtypes) they start getting evicted ? Thanks, Sergey > Cache MediaTypeHeaderProvider.valueOf(String mType) results > --- > > Key: CXF-6826 > URL: https://issues.apache.org/jira/browse/CXF-6826 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Alessio Soldano > > MediaTypeHeaderProvider.valueOf(String mType) ends up being called a lot with > the same parameter values, as those are basically the contents of the > @Produce annotations on resources. Each request ends up into the same > invocation, which is cpu and memory intensive. > It might make sense to add a map in the MediaTypeHeaderProvider to store the > result of the static valueOf method invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6826) Cache MediaTypeHeaderProvider.valueOf(String mType) results
[ https://issues.apache.org/jira/browse/CXF-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188041#comment-15188041 ] Sergey Beryozkin commented on CXF-6826: --- or may be simply check the concurrent map size and if it reaches some default value (50 max would probably cover a lot of cases) then clear the map, not sure though adding these checks will cheap enough, I guess it should be. > Cache MediaTypeHeaderProvider.valueOf(String mType) results > --- > > Key: CXF-6826 > URL: https://issues.apache.org/jira/browse/CXF-6826 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Alessio Soldano > > MediaTypeHeaderProvider.valueOf(String mType) ends up being called a lot with > the same parameter values, as those are basically the contents of the > @Produce annotations on resources. Each request ends up into the same > invocation, which is cpu and memory intensive. > It might make sense to add a map in the MediaTypeHeaderProvider to store the > result of the static valueOf method invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
