Petals BC SOAP

Can't create get an Axis service client from the pool

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 4.0.3
  • Fix Version/s: 4.0.3
  • Component/s: None
  • Description:
    Hide

    When we call a WebService long time after its last call, the component returns the following error : "Can't create get an Axis service client from the pool".

    • We call the service a few time ==> OK
    • We the go to bed
    • When we try to call this service again ==> KO

    == Reproduction Note ==

    Launch the mock of the AD003-RecupIDsMissionsSigma-soapui-project.xml SOAPUI project
    Deploy the two service units
    Launch the load test of the AD003-Caller-soapui-project.xml project
    Stop the test after one minute or two
    Wait a few hours
    Try to call the service again

    Show
    When we call a WebService long time after its last call, the component returns the following error : "Can't create get an Axis service client from the pool".
    • We call the service a few time ==> OK
    • We the go to bed
    • When we try to call this service again ==> KO
    == Reproduction Note == Launch the mock of the AD003-RecupIDsMissionsSigma-soapui-project.xml SOAPUI project Deploy the two service units Launch the load test of the AD003-Caller-soapui-project.xml project Stop the test after one minute or two Wait a few hours Try to call the service again
  • Environment:
    Petals ESB 3.1
    Petals-BC-SOAP 4.0.3 SNAPSHOT (petals-bc-soap-4.0.3-20100704.073518-7)

Attachments

  1. XML File
    AD003-Caller-soapui-project.xml
    (19 kB)
    Charles Casadei
    Mon, 2 Aug 2010 - 16:57:53 +0200
  2. XML File
    AD003-RecupIDsMissionsSigma-soapui-project.xml
    (67 kB)
    Charles Casadei
    Mon, 2 Aug 2010 - 16:57:53 +0200
  3. Zip Archive
    petals-bc-soap-4.0.3-SNAPSHOT.zip
    (16.84 MB)
    noddoux
    Tue, 21 Sep 2010 - 09:11:45 +0200
  4. Zip Archive
    sa-SOAP-AD003-RecupIDsMissionsSigma_EIP-consume.zip
    (1 kB)
    Charles Casadei
    Mon, 2 Aug 2010 - 16:57:53 +0200
  5. Zip Archive
    sa-SOAP-AD003-RecupIDsMissionsSigma_EIP-provide.zip
    (4 kB)
    Charles Casadei
    Mon, 2 Aug 2010 - 16:57:59 +0200

Activity

Descending order - Click to sort in ascending order
Hide
Permalink
noddoux added a comment - Tue, 21 Sep 2010 - 09:11:45 +0200

The problem should be corrected with this snapshot of the SOAP component.

Show
noddoux added a comment - Tue, 21 Sep 2010 - 09:11:45 +0200 The problem should be corrected with this snapshot of the SOAP component.
Hide
Permalink
noddoux added a comment - Mon, 20 Sep 2010 - 10:52:39 +0200

Reproduction steps:
1/ Install the BC SOAP and a SU provide
2/ Launch a request (it should work)
3/ Uninstall the SU provide
4/ Launch the same request (it should still work)
5/ Wait at least 30 minutes
6/ Launch the request (it should not work)

Analysis:
The service client pool is not deleted when removing a SU provide (its factory keeps a reference on the provide instance of the SU which is deleted). The service client pool is stored in a hash table, the key of the hash table of the address of the partner service, the operation and the MEP. Consequently when the same SU is reinstalled, the same pool is reused.
After reinstalling, if there is still a service client in the pool, it is used and it works. But this service client is removed from the pool by the garbage collector after 30 minutes so a new service client is created with the pool factory with the reference on the old provide instance in case of a new request. It crashes because the provide instance is used as a key of a hash table and it returns null (this hash table had been cleaned when removing the SU).

Show
noddoux added a comment - Mon, 20 Sep 2010 - 10:52:39 +0200 Reproduction steps: 1/ Install the BC SOAP and a SU provide 2/ Launch a request (it should work) 3/ Uninstall the SU provide 4/ Launch the same request (it should still work) 5/ Wait at least 30 minutes 6/ Launch the request (it should not work) Analysis: The service client pool is not deleted when removing a SU provide (its factory keeps a reference on the provide instance of the SU which is deleted). The service client pool is stored in a hash table, the key of the hash table of the address of the partner service, the operation and the MEP. Consequently when the same SU is reinstalled, the same pool is reused. After reinstalling, if there is still a service client in the pool, it is used and it works. But this service client is removed from the pool by the garbage collector after 30 minutes so a new service client is created with the pool factory with the reference on the old provide instance in case of a new request. It crashes because the provide instance is used as a key of a hash table and it returns null (this hash table had been cleaned when removing the SU).
Hide
Permalink
Emmanuel Manceau added a comment - Mon, 30 Aug 2010 - 11:37:00 +0200

Hello Nicolas,

This bus is not reproducible with SOAP UI mocks. It occurs only with real web services.

Regards,

Show
Emmanuel Manceau added a comment - Mon, 30 Aug 2010 - 11:37:00 +0200 Hello Nicolas, This bus is not reproducible with SOAP UI mocks. It occurs only with real web services. Regards,
Hide
Permalink
noddoux added a comment - Thu, 5 Aug 2010 - 10:41:51 +0200

The bug was not reproduced on our platform (with SoapUI as client)

Show
noddoux added a comment - Thu, 5 Aug 2010 - 10:41:51 +0200 The bug was not reproduced on our platform (with SoapUI as client)
Hide
Permalink
Charles Casadei added a comment - Wed, 4 Aug 2010 - 15:11:36 +0200

You may find many "provides" service assemblies in the smb://192.168.1.4/pv00.vg00.projets/INGRID/Tests%20registry/su directory.

Show
Charles Casadei added a comment - Wed, 4 Aug 2010 - 15:11:36 +0200 You may find many "provides" service assemblies in the smb://192.168.1.4/pv00.vg00.projets/INGRID/Tests%20registry/su directory.
Hide
Permalink
Charles Casadei added a comment - Tue, 3 Aug 2010 - 08:40:30 +0200 - edited

We have encountered this problem with other customers. After a long period without any call, the first call on a "provide" endpoint fails.

Show
Charles Casadei added a comment - Tue, 3 Aug 2010 - 08:40:30 +0200 - edited We have encountered this problem with other customers. After a long period without any call, the first call on a "provide" endpoint fails.

People

Dates

  • Created:
    Mon, 2 Aug 2010 - 14:24:58 +0200
    Updated:
    Tue, 21 Sep 2010 - 09:11:45 +0200
    Resolved:
    Mon, 20 Sep 2010 - 14:32:08 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.