You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Scott Wells (JIRA)" <ji...@apache.org> on 2019/04/08 14:59:00 UTC

[jira] [Updated] (CXF-8014) Deserializing SOAP response with ~4K small objects is taking 1-2 mins

     [ https://issues.apache.org/jira/browse/CXF-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Wells updated CXF-8014:
-----------------------------
    Description: 
I'm hoping that this is the right place to report this, but apologies if not. For a number of years now I've been using CXF in my product as a WSDL-generated SOAP client. Everything works really, really well. In the past week I've seen a situation with a particular end user where deserialization of a SOAP response that contains a list of ~4K small objects is taking 1-2 minutes. I've updated to 3.3.1 hoping that would resolve the issue, but it still remains. I know (or at least strongly suspect) that it's happening in deserialization because I'm logging immediately before and after the SOAP call from the perspective of the calling client, and I've turned on in/out logging interceptors. Basically I see the following in the log (with sensitive info redacted):

{{2019-04-07 23:18:38,364 [ 20299] DEBUG - ij.builder.ForceComBuilderUtil - Before listMetadata() call.
2019-04-07 23:18:38,366 [ 20301] INFO - ervice.MetadataApi.MetadataApi - Outbound Message
... Details removed
2019-04-07 23:18:51,613 [ 33548] INFO - ervice.MetadataApi.MetadataApi - Inbound Message
... Details removed
... ~1m30s pause before returning to the caller
2019-04-07 23:20:20,095 [ 122030] DEBUG - ij.builder.ForceComBuilderUtil - After listMetadata() call. 
2019-04-07 23:20:20,095 [ 122030] DEBUG - ij.builder.ForceComBuilderUtil - listMetadata() returned 4299 results. }}

I've tried to reproduce this behavior, but so far unsuccessfully. I have an environment that includes about half this number of results, and the same call takes ~2-3 seconds end-to-end.

Any idea what might be going on or how to get to the bottom of the issue?

Again, if this belongs somewhere else please just let me know, and thanks in advance for the assistance.

  was:
I'm hoping that this is the right place to report this, but apologies if not. For a number of years now I've been using CXF in my product as a WSDL-generated SOAP client. Everything works really, really well. In the past week I've seen a situation with a particular end user where deserialization of a SOAP response that contains a list of ~4K small objects is taking 1-2 minutes. I've updated to 3.3.1 hoping that would resolve the issue, but it still remains. I know (or at least strongly suspect) that it's happening in deserialization because I'm logging immediately before and after the SOAP call from the perspective of the calling client, and I've turned on in/out logging interceptors. Basically I see the following in the log (with sensitive info redacted):

{{2019-04-07 23:18:38,364 [ 20299] DEBUG - ij.builder.ForceComBuilderUtil - Before listMetadata() call. }}
{{2019-04-07 23:18:38,366 [ 20301] INFO - ervice.MetadataApi.MetadataApi - Outbound Message}}
{{... Details removed}}
{{2019-04-07 23:18:51,613 [ 33548] INFO - ervice.MetadataApi.MetadataApi - Inbound Message}}
{{... Details removed}}
{{... ~1m30s pause before returning to the caller}}
{{2019-04-07 23:20:20,095 [ 122030] DEBUG - ij.builder.ForceComBuilderUtil - After listMetadata() call. }}
{{2019-04-07 23:20:20,095 [ 122030] DEBUG - ij.builder.ForceComBuilderUtil - listMetadata() returned 4299 results. }}

I've tried to reproduce this behavior, but so far unsuccessfully. I have an environment that includes about half this number of results, and the same call takes ~2-3 seconds end-to-end.

Any idea what might be going on or how to get to the bottom of the issue?

Again, if this belongs somewhere else please just let me know, and thanks in advance for the assistance.


> Deserializing SOAP response with ~4K small objects is taking 1-2 mins
> ---------------------------------------------------------------------
>
>                 Key: CXF-8014
>                 URL: https://issues.apache.org/jira/browse/CXF-8014
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 3.3.1
>            Reporter: Scott Wells
>            Priority: Major
>
> I'm hoping that this is the right place to report this, but apologies if not. For a number of years now I've been using CXF in my product as a WSDL-generated SOAP client. Everything works really, really well. In the past week I've seen a situation with a particular end user where deserialization of a SOAP response that contains a list of ~4K small objects is taking 1-2 minutes. I've updated to 3.3.1 hoping that would resolve the issue, but it still remains. I know (or at least strongly suspect) that it's happening in deserialization because I'm logging immediately before and after the SOAP call from the perspective of the calling client, and I've turned on in/out logging interceptors. Basically I see the following in the log (with sensitive info redacted):
> {{2019-04-07 23:18:38,364 [ 20299] DEBUG - ij.builder.ForceComBuilderUtil - Before listMetadata() call.
> 2019-04-07 23:18:38,366 [ 20301] INFO - ervice.MetadataApi.MetadataApi - Outbound Message
> ... Details removed
> 2019-04-07 23:18:51,613 [ 33548] INFO - ervice.MetadataApi.MetadataApi - Inbound Message
> ... Details removed
> ... ~1m30s pause before returning to the caller
> 2019-04-07 23:20:20,095 [ 122030] DEBUG - ij.builder.ForceComBuilderUtil - After listMetadata() call. 
> 2019-04-07 23:20:20,095 [ 122030] DEBUG - ij.builder.ForceComBuilderUtil - listMetadata() returned 4299 results. }}
> I've tried to reproduce this behavior, but so far unsuccessfully. I have an environment that includes about half this number of results, and the same call takes ~2-3 seconds end-to-end.
> Any idea what might be going on or how to get to the bottom of the issue?
> Again, if this belongs somewhere else please just let me know, and thanks in advance for the assistance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)