[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[ https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15548272#comment-15548272 ] Sergey Beryozkin commented on CXF-7075: --- Hi, thanks for this patch, I've applied most of the changes except the one in JAXRSUtils. The reason for it is that I'm pretty sure the original code was using 'split' but a user reported that it was affecting the performance :-). Perhaps it is not too bad when Accept has only 1 or 2 media types but becomes worse with the longer sequences ? Can you please give me a favour and do some more analysis on that specific code (.length() vs split()), may be we can come up with yet another solution there thanks > Remove unnecessary string.length() and map.containsKey(...) calls to improve > performance > > > Key: CXF-7075 > URL: https://issues.apache.org/jira/browse/CXF-7075 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Andy McCright > Original Estimate: 24h > Remaining Estimate: 24h > > Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around > string.length() and map.containsKey(...) calls that could be optimized. > Initial testing with the proposed changes yielded about a 2-3% improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7071) HttpServletRequest.getParameter only get String from query not both posted form data
[
https://issues.apache.org/jira/browse/CXF-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15548574#comment-15548574
]
Sergey Beryozkin commented on CXF-7071:
---
I'm not sure what you mean that the root cause is in the JAXRSUtils code. The
only reason you see no parameter values returned when you work directly against
HttpServletRequest (unless that property is set) is that CXF
AbstractHttpDestination needs to set HTTP InputStream on the current Message.
JAXRSUtils will not consult the consumed POST form input stream when resolving
@QueryParam - these can only come from HTTP URL query component.
But as I said, given that you do prefer working directly with
HttpServletRequest, but also because users keep asking about it quite
regularly, I will consider overriding CXF HttpServletRequest wrapper to
ovverride parameter related methods (in fact 4 of them). I won't recommend
users doing it - as I said - it won't work for cases where the encoded values
have to be made available - and it is outside of JAX-RS API - but if it can
help some users then I guess it might make sense
> HttpServletRequest.getParameter only get String from query not both posted
> form data
>
>
> Key: CXF-7071
> URL: https://issues.apache.org/jira/browse/CXF-7071
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Neal Hu
> Fix For: 3.1.8
>
>
> The http request:
> POST /dubbott-demo-provider/v1.0/users/beanparam HTTP/1.1
> HOST: localhost:8080
> accept: text/plain
> content-type: application/x-www-form-urlencoded
> content-length: 12
> pageIndex=99
> The resource method returns null:
> {code:java}
> public String beanParam(@Context HttpServletRequest req, String ak) {
> String pageIndex = req.getParameter("pageIndex")
> return pageIndex;
> }
> {code}
> From the servlet 3.1 API doc:
> String javax.servlet.ServletRequest.getParameter(String name)
> Returns the value of a request parameter as a String, or null if the
> parameter does not exist. Request parameters are extra information sent with
> the request. For HTTP servlets, parameters are contained in the query string
> or posted form data.
> if we add below servlet filter:
> {code:java}
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException {
> System.out.println(request.getParameter("pageIndex") );
> chain.doFilter(request, response);
> }
> {code}
> The output is "99" the response is the same "99".
> As a conclusion the CXF HttpServletRequest doesn't comply the Servlet 3.1 API
> Spec.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5754) JMSConduit - temporary queue not beeing closed if relpyMessage is null (timeout)
[
https://issues.apache.org/jira/browse/CXF-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549013#comment-15549013
]
ARSLAN ALI commented on CXF-5754:
-
on the same issue we are using cxf 3.0.5 and once TIBCO return null cxf class
JMSUtil throws Runtime exception and JMSConduit will not clear the
correlationMap. This causes a memory leak.
public static Message receive(Session session,
Destination replyToDestination,
String correlationId,
long receiveTimeout,
boolean pubSubNoLocal) {
ResourceCloser closer = new ResourceCloser();
try {
String messageSelector = correlationId == null ? null :
"JMSCorrelationID = '" + correlationId + "'";
javax.jms.Message replyMessage = consumer.receive(receiveTimeout);
if (replyMessage == null) {
throw new RuntimeException("Timeout receiving message with
correlationId "
+ correlationId);
}
in JMSConduit correlationMap.remove(correlationId); will not get called.
> JMSConduit - temporary queue not beeing closed if relpyMessage is null
> (timeout)
>
>
> Key: CXF-5754
> URL: https://issues.apache.org/jira/browse/CXF-5754
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.11
>Reporter: Philipp Hahn
>
> Our implementation:
> CXF 2.7.11
> JMS Queue on TIBCO
> We have the problem, that if a timeout is raised the temporary queue is not
> been deleted.
> After code review of the JmsConduit class we have seen, that in case of a
> timeout, cxf is only raises only an RuntimeException (JmsConduit line 256)
> {code}
> javax.jms.Message replyMessage =
> jmsTemplate.receiveSelected(replyToDestination, messageSelector);
> if (replyMessage == null) {
> throw new RuntimeException("Timeout receiving message
> with correlationId " + correlationId);
> } else {
> doReplyMessage(exchange, replyMessage);
> }
> {code}
> Is this the problem why the temporary queue is not been closed in case of a
> timeout? Is there an solution for this problem?
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[ https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy McCright updated CXF-7075: --- Attachment: JAXRSUtils-parseMediaType-perfTest.zip Here is the performance test case I used. The test just parses some of the default media types. It tests parsing one media type (no comma separation), two media types (one comma), three media types, and 12 media types. I ran the original code then the proposed code and back and forth a few times to try to filter out anything else that is running on my machine (still not the cleanest for a true performance test, but it's what I have to work with... :) ), and here are my results: Original Code Test Time to parse one type: 138693018 nanoseconds Time to parse two types: 77448126 nanoseconds Time to parse three types: 78393247 nanoseconds Time to parse twelve types: 392029699 nanoseconds Proposed Change Test Time to parse one type: 137286698 nanoseconds Time to parse two types: 69548647 nanoseconds Time to parse three types: 71362712 nanoseconds Time to parse twelve types: 408572018 nanoseconds Original Code Test Time to parse one type: 139692204 nanoseconds Time to parse two types: 72788203 nanoseconds Time to parse three types: 79289730 nanoseconds Time to parse twelve types: 439972027 nanoseconds Proposed Change Test Time to parse one type: 137032626 nanoseconds Time to parse two types: 69043698 nanoseconds Time to parse three types: 77564601 nanoseconds Time to parse twelve types: 385392535 nanoseconds Original Code Test Time to parse one type: 148664661 nanoseconds Time to parse two types: 73345793 nanoseconds Time to parse three types: 79363398 nanoseconds Time to parse twelve types: 412479763 nanoseconds Proposed Change Test Time to parse one type: 139838947 nanoseconds Time to parse two types: 73356785 nanoseconds Time to parse three types: 76625311 nanoseconds Time to parse twelve types: 383566071 nanoseconds > Remove unnecessary string.length() and map.containsKey(...) calls to improve > performance > > > Key: CXF-7075 > URL: https://issues.apache.org/jira/browse/CXF-7075 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Andy McCright > Attachments: JAXRSUtils-parseMediaType-perfTest.zip > > Original Estimate: 24h > Remaining Estimate: 24h > > Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around > string.length() and map.containsKey(...) calls that could be optimized. > Initial testing with the proposed changes yielded about a 2-3% improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[ https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549691#comment-15549691 ] Andy McCright commented on CXF-7075: Hi Sergey, Thanks for the commits. I did some more digging (in a Java SE environment), and it looks like there really isn't a huge gain in using str.split() vs the current approach. I'll attach the test case I used and the results. Using str.split() did seem faster when parsing more media types, but the difference is minor. Thanks, Andy > Remove unnecessary string.length() and map.containsKey(...) calls to improve > performance > > > Key: CXF-7075 > URL: https://issues.apache.org/jira/browse/CXF-7075 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Andy McCright > Original Estimate: 24h > Remaining Estimate: 24h > > Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around > string.length() and map.containsKey(...) calls that could be optimized. > Initial testing with the proposed changes yielded about a 2-3% improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[
https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549928#comment-15549928
]
Andy McCright commented on CXF-7075:
Interestingly, when I bump up the TIMES_TO_RUN from 500k to 1 million, then the
proposed fix looks a bit slower:
Original Code Test
Time to parse one type: 146873609 nanoseconds
Time to parse two types: 119980999 nanoseconds
Time to parse three types: 158751189 nanoseconds
Time to parse twelve types: 792077205 nanoseconds
Proposed Change Test
Time to parse one type: 166478348 nanoseconds
Time to parse two types: 135731365 nanoseconds
Time to parse three types: 163320358 nanoseconds
Time to parse twelve types: 758674187 nanoseconds
Original Code Test
Time to parse one type: 157246321 nanoseconds
Time to parse two types: 129763922 nanoseconds
Time to parse three types: 164354449 nanoseconds
Time to parse twelve types: 840647904 nanoseconds
Proposed Change Test
Time to parse one type: 162607531 nanoseconds
Time to parse two types: 123097493 nanoseconds
Time to parse three types: 165173994 nanoseconds
Time to parse twelve types: 768583383 nanoseconds
Original Code Test
Time to parse one type: 143968053 nanoseconds
Time to parse two types: 133924033 nanoseconds
Time to parse three types: 161509309 nanoseconds
Time to parse twelve types: 809422872 nanoseconds
Proposed Change Test
Time to parse one type: 157101703 nanoseconds
Time to parse two types: 135634786 nanoseconds
Time to parse three types: 158294707 nanoseconds
Time to parse twelve types: 781427304 nanoseconds
I tried re-implementing another way which looks like it might be a little
faster...
public static List parseMediaTypes(String types) {
List acceptValues = new ArrayList();
if (types != null) {
int x = 0;
int y = types.indexOf(',');
while (y > 0) {
acceptValues.add(toMediaType(types.substring(x, y)));
x = y + 2;
y = types.indexOf(',', x);
}
acceptValues.add(toMediaType(types.substring(x)));
} else {
acceptValues.add(ALL_TYPES);
}
return acceptValues;
}
With that code, I get these results (new code is labeled as Proposed):
Original Code Test
Time to parse one type: 162089550 nanoseconds
Time to parse two types: 121634212 nanoseconds
Time to parse three types: 164150901 nanoseconds
Time to parse twelve types: 1027082012 nanoseconds
Proposed Change Test
Time to parse one type: 147992281 nanoseconds
Time to parse two types: 118361681 nanoseconds
Time to parse three types: 154465943 nanoseconds
Time to parse twelve types: 744372633 nanoseconds
Original Code Test
Time to parse one type: 171457432 nanoseconds
Time to parse two types: 123348169 nanoseconds
Time to parse three types: 163685283 nanoseconds
Time to parse twelve types: 759016041 nanoseconds
Proposed Change Test
Time to parse one type: 147617428 nanoseconds
Time to parse two types: 118008933 nanoseconds
Time to parse three types: 153649110 nanoseconds
Time to parse twelve types: 756229153 nanoseconds
Original Code Test
Time to parse one type: 151245814 nanoseconds
Time to parse two types: 122917357 nanoseconds
Time to parse three types: 159188030 nanoseconds
Time to parse twelve types: 843513510 nanoseconds
Proposed Change Test
Time to parse one type: 145248903 nanoseconds
Time to parse two types: 118914505 nanoseconds
Time to parse three types: 155509909 nanoseconds
Time to parse twelve types: 767379270 nanoseconds
I haven't run this change on the simple JAX-RS benchmark, but I can do that --
I'll be on vacation the next couple of days, so I may not have results until
next week.
Thanks, Andy
> Remove unnecessary string.length() and map.containsKey(...) calls to improve
> performance
>
>
> Key: CXF-7075
> URL: https://issues.apache.org/jira/browse/CXF-7075
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Andy McCright
> Attachments: JAXRSUtils-parseMediaType-perfTest.zip
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around
> string.length() and map.containsKey(...) calls that could be optimized.
> Initial testing with the proposed changes yielded about a 2-3% improvement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[ https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15550211#comment-15550211 ] Sergey Beryozkin commented on CXF-7075: --- Hi Andy, thanks for all the analysis, interesting, yes, please do a bit more benchmarking and then we can finalize on either keeping the existing code as is or tweak it a bit Thanks, Sergey > Remove unnecessary string.length() and map.containsKey(...) calls to improve > performance > > > Key: CXF-7075 > URL: https://issues.apache.org/jira/browse/CXF-7075 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Andy McCright > Attachments: JAXRSUtils-parseMediaType-perfTest.zip > > Original Estimate: 24h > Remaining Estimate: 24h > > Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around > string.length() and map.containsKey(...) calls that could be optimized. > Initial testing with the proposed changes yielded about a 2-3% improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7057) CXF JAXRSClientFactoryBean proxy async support
[
https://issues.apache.org/jira/browse/CXF-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15550775#comment-15550775
]
Neal Hu commented on CXF-7057:
--
I patched dubbo javassist proxy to support none service bean
interface(InvocationHandlerAware)
https://github.com/dangdangdotcom/dubbox/pull/199/files
com.alibaba.dubbo.rpc.proxy.javassist.JavassistProxyFactory.getProxy(Invoker,
Class[])
Now the issue can be fixed. Thanks!
> CXF JAXRSClientFactoryBean proxy async support
> --
>
> Key: CXF-7057
> URL: https://issues.apache.org/jira/browse/CXF-7057
> Project: CXF
> Issue Type: Wish
> Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Linux Mac
>Reporter: Neal Hu
> Fix For: 3.1.8
>
>
> Say we have resource interface org.apache.cxf.Resource, and its impl
> org.apache.cxf.ResourceImpl, we can create client proxy via
> JAXRSClientFactoryBean as below;
> {code:java}
> Class type = org.apache.cxf.Resource.class;
> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
> bean.setAddress(baseAddress);
> bean.setServiceClass(type);
> bean.setProviders(providers);
> bean.setFeatures(features);
> bean.setThreadSafe(true);
> T proxy = bean.create(type);
> {code}
> Then invoke the method via proxy.method1.
> As we know the spec client api can invoke via async mode, my question is if
> the dynamic proxy mode support async mode.
> We are developing micro service framework which based on CXF RS, and the
> comsumer's invoker is dynamicly generated by the clientfactory.create. Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
