Petals BC SOAP

Performance problem on first call

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.3.4
  • Fix Version/s: 4.4.0
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    After the SOAP BC has been started, at the first SOAP call from outside, it will load the WSDL of the consumes, and for this, it will lock on the AxisService (there is one per Consumes).

    So if 100 messages arrives at ounce, they will all wait and it will strongly degrade performances.

    There is no need for doing so: the wsdl (and other things) can simply be loaded when the SU is deployed.

    Show
    After the SOAP BC has been started, at the first SOAP call from outside, it will load the WSDL of the consumes, and for this, it will lock on the AxisService (there is one per Consumes). So if 100 messages arrives at ounce, they will all wait and it will strongly degrade performances. There is no need for doing so: the wsdl (and other things) can simply be loaded when the SU is deployed.
  • Environment:
    -

Activity

Hide
Christophe DENEUX added a comment - Fri, 11 Sep 2015 - 19:28:23 +0200

If the service provider is not available when deploying a SOAP consume, you will not be able to get the service provider WSDL. How do you manage this use case ?

Show
Christophe DENEUX added a comment - Fri, 11 Sep 2015 - 19:28:23 +0200 If the service provider is not available when deploying a SOAP consume, you will not be able to get the service provider WSDL. How do you manage this use case ?
Hide
Victor NOËL added a comment - Mon, 14 Sep 2015 - 09:33:04 +0200

Good point, I didn't think of that, but I'm not sure to understand in which case this could happen: the wsdl is loaded from the JBI descriptor, if there is no WSDL defined in the JBI descriptor, it's not going to be added later… or is there some kind of mechanism that does that in the SOAP BC?

Show
Victor NOËL added a comment - Mon, 14 Sep 2015 - 09:33:04 +0200 Good point, I didn't think of that, but I'm not sure to understand in which case this could happen: the wsdl is loaded from the JBI descriptor, if there is no WSDL defined in the JBI descriptor, it's not going to be added later… or is there some kind of mechanism that does that in the SOAP BC?
Hide
Christophe DENEUX added a comment - Mon, 14 Sep 2015 - 09:48:47 +0200

No, in my mind, for a BC SOAP consumer, the WSDL is loaded from its defined service provider. The WSDL is loaded from the JBI descriptor for a BC SOAP provider.

Show
Christophe DENEUX added a comment - Mon, 14 Sep 2015 - 09:48:47 +0200 No, in my mind, for a BC SOAP consumer, the WSDL is loaded from its defined service provider. The WSDL is loaded from the JBI descriptor for a BC SOAP provider.
Hide
Victor NOËL added a comment - Mon, 14 Sep 2015 - 10:03:35 +0200

When you say BC SOAP Provider, you mean a JBI Consumes, right?

In this commit, it only covers JBI Consumes and the previous (and current code) was only loading the WSDL from the JBI descriptor.

Concerning Provides (not touched by this commit)… well the WSDL is also loaded from the JBI descriptor!

The difference is that it seems that it is an error (SU start fails) if the WSDL is missing for the Consumes, but it does not (warning logged) if the WSDL is missing for the Provides.

Is there something wrong with all of that? Should we add functionality for loading the WSDL from the external SOAP provider (so for the JBI Provides)?

Show
Victor NOËL added a comment - Mon, 14 Sep 2015 - 10:03:35 +0200 When you say BC SOAP Provider, you mean a JBI Consumes, right? In this commit, it only covers JBI Consumes and the previous (and current code) was only loading the WSDL from the JBI descriptor. Concerning Provides (not touched by this commit)… well the WSDL is also loaded from the JBI descriptor! The difference is that it seems that it is an error (SU start fails) if the WSDL is missing for the Consumes, but it does not (warning logged) if the WSDL is missing for the Provides. Is there something wrong with all of that? Should we add functionality for loading the WSDL from the external SOAP provider (so for the JBI Provides)?
Hide
Victor NOËL added a comment - Mon, 14 Sep 2015 - 13:51:07 +0200

So I checked and for a BC SOAP Consumes (as declared in the JBI), the WSDL is JBI Service Provider's, and it is retrieved from the Petals Registry.

It wasn't clear before to me and it does mean there is a problem if there is no provider deployed on the Bus yet...

I will investigate that to fix it properly.

Show
Victor NOËL added a comment - Mon, 14 Sep 2015 - 13:51:07 +0200 So I checked and for a BC SOAP Consumes (as declared in the JBI), the WSDL is JBI Service Provider's, and it is retrieved from the Petals Registry. It wasn't clear before to me and it does mean there is a problem if there is no provider deployed on the Bus yet... I will investigate that to fix it properly.
Hide
Victor NOËL added a comment - Tue, 15 Sep 2015 - 11:40:01 +0200

Ok, I reintroduced the loading of the WSDL on the first call when needed (I call that "on-demand"), I added an integration test (r37687) for it, but the WSDL is loaded earlier if possible.

Also, now it should work better than before for the on-demand behaviour because it's done in a much cleaner way and at the correct time (which wasn't the case before).

Show
Victor NOËL added a comment - Tue, 15 Sep 2015 - 11:40:01 +0200 Ok, I reintroduced the loading of the WSDL on the first call when needed (I call that "on-demand"), I added an integration test (r37687) for it, but the WSDL is loaded earlier if possible. Also, now it should work better than before for the on-demand behaviour because it's done in a much cleaner way and at the correct time (which wasn't the case before).

People

Dates

  • Created:
    Fri, 11 Sep 2015 - 16:59:57 +0200
    Updated:
    Tue, 15 Sep 2015 - 17:38:26 +0200
    Resolved:
    Tue, 15 Sep 2015 - 17:38:26 +0200