QUSIR / staff

Automatically exported from code.google.com/p/staff
Apache License 2.0
0 stars 0 forks source link

Thread-safe OM building on client and service #139

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Enhance core and codegen templates to build Object Model using environment of 
the client or the service.

Original issue reported on code.google.com by loentar on 22 Sep 2011 at 6:54

GoogleCodeExporter commented 9 years ago

Original comment by loentar on 26 Sep 2011 at 12:40

GoogleCodeExporter commented 9 years ago
Looks like this problem occurs only when Axis2/C is linked against libxml.
When using guththila no segfaults detected.

Original comment by loentar on 5 Oct 2011 at 6:17

GoogleCodeExporter commented 9 years ago
I followed the installation steps as described in the (Linux) installation 
manual (i.e. using guththila) and the thread-safety problems exists in that 
case too.

Original comment by matiassanm on 5 Oct 2011 at 12:04

GoogleCodeExporter commented 9 years ago
Can you attach example of service and client that reproduce the problem?

Original comment by loentar on 5 Oct 2011 at 12:28

GoogleCodeExporter commented 9 years ago
I will try to create an example. It will be hard because I'm not sure under 
which conditions the problem happen (other than heavy stress). As soon as I get 
a reduced example that reproduces the problem I will attach it. 

A piece of information that may (or may not) be helpful is that I'm using 
SoapUI to simulate the web servers that responds to the calls (i.e. no logic 
associated to the processing of the requests and so a faster response). Maybe 
that way you can stress enough your client to make it fail. 

Original comment by matiassanm on 5 Oct 2011 at 12:37

GoogleCodeExporter commented 9 years ago
I successfully create an example that regularly fails (attached). I'm using 
boost::threads in my example (main) but any threading library should work. Also 
I run the tests using soapUI to simulate the web-server.

Note that I had to change some names from my working example (to avoid 
disclosing information), I hope didn't broke anything but anyway this should 
give you an idea on how/why this is failing.

Original comment by matiassanm on 6 Oct 2011 at 12:15

Attachments:

GoogleCodeExporter commented 9 years ago
Thank you, I will examine it soon.

Original comment by loentar on 6 Oct 2011 at 1:07

GoogleCodeExporter commented 9 years ago
Firstly, I have modified your main.cpp: Renamed Services and Operation names - 
don't match wsdls. (test_139.tar.bz2)

Looks like this is an Axis2/C problem.

1. when using libxml test_139 client falls instantly in libxml (see 
client_backtraces).

I have made clean test: created C client based on echo (see client_c1.tar.gz2). 
It crashes also inside libxml while destructing client.

2. when using guththila both clients works. But now Axis2/C server falls down 
after some time. It crashes after approx 3000-7000 requests of test_client 
(client_c1).

Same error with current axis2/c-1.7.0 trunk version.
Backtrace of Axis2/C attached.

This occurs also when staff is not installed.
To remove staff completely you can use:
sudo rm -Rf $STAFF_HOME $AXIS2C_HOME/services/staff $AXIS2C_HOME/modules/staff* 
&& sudo ldconfig

P.S.: to produce core file under ubuntu you can use:
sudo sh -c 'ulimit -c unlimited; ./axis2_http_server'

you can examine the core using gdb:
sudo gdb -core core ./axis2_http_server

P.P.S.: I have attached test version of staff, where all requests and responses 
processed within different environments.
staff-libxml-threadsafe.tar.bz2
But since it is an Axis2/C error I do not plan to commit it yet.

Original comment by loentar on 12 Oct 2011 at 11:56

Attachments:

GoogleCodeExporter commented 9 years ago
From the explanation I understand that what is failing in your tests (with 
guththila) is the Axis2/c server, but in my case I'm not using it. In my tests 
I'm using SoapUI as server. Is Axis2/c server also used when executing a Staff 
client?

Do you have a clue on where the bug may be to post an issue on Axis2/c bug 
tracker?

Original comment by matiassanm on 12 Oct 2011 at 12:11

GoogleCodeExporter commented 9 years ago
After a lot of debugging I created a patch for axis2c, I tested the patch in 
axis2c and it works, also it fixes some major memory leaks when using callbacks 
in the trunk version.
The patch is attached to https://issues.apache.org/jira/browse/AXIS2C-1584, 
feel free to review it, any feedback, correction, etc will be more than welcome.
Still there are some crashes when instantiating multiple svc_clients, due the 
fact that some file openings aren't being validated, and when the fd limit is 
achieved it crashes (that issue hasn't been solved)

Original comment by alexmantaut on 4 Apr 2012 at 7:20

GoogleCodeExporter commented 9 years ago
This issue is now marked as closed, because it related to Axis2/C only.

Original comment by loentar on 14 Aug 2012 at 7:18