Menu
▾
▴
soaplite-devel — SOAP::Lite developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(7) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
(23) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(2) |
| 2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2006 |
Jan
(1) |
Feb
(6) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(4) |
Sep
(4) |
Oct
(4) |
Nov
(6) |
Dec
(3) |
| 2007 |
Jan
(1) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(12) |
Oct
(19) |
Nov
(7) |
Dec
(7) |
| 2008 |
Jan
(14) |
Feb
(27) |
Mar
(23) |
Apr
(5) |
May
|
Jun
(1) |
Jul
|
Aug
(9) |
Sep
(22) |
Oct
|
Nov
(5) |
Dec
(7) |
| 2009 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(8) |
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(4) |
Aug
(2) |
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
|
May
(7) |
Jun
(3) |
Jul
(8) |
Aug
(9) |
Sep
(5) |
Oct
(4) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(20) |
Nov
(15) |
Dec
(11) |
| 2013 |
Jan
(1) |
Feb
(40) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thorsten S. <tsc...@am...> - 2011-05-12 07:14:33
|
Guten Tag Alceu R. de Freitas Jr., am Mittwoch, 11. Mai 2011 um 22:23 schrieben Sie: > While the SOAP fault code looks ok, I'm wondering if the HTTP > header is the correct one. Of course this will happen (once I'm > using the Perl die function in the CGI) but it seems to me more > resonable that the HTTP error should be "400 Bad Request" since the > server was able to process the request, but the parameter(s) is(are) invalid. The request itself was OK and that what's the status code 400 focuses on, your error is on application level. > So my first question is: should I worry about that? > Question 2: if I should, how should I change that? In this case you shouldn't worry nor change, every framework and programming language I know of can handle at least 500. If you want to change the status code sent you first should really look at your clients and make sure they can handle anything else. Remember that webservices are made for interoperability and sometimes this just means to not use everything what might be possible. In our software for example we started to use Perl and SOAP::Lite on sevrer and client side and didn't care about datatypes, proper encoding of data etc. It just worked because SOAP::Lite handled it all. Some years late we really have a hard time to support Java, C++, C#, publish a WSDL and so on. No we think twice on any change. :-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tsc...@am... Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow |
|
From: Alceu R. de F. Jr. <gla...@ya...> - 2011-05-11 20:23:35
|
Hello there, My name is Alceu and I'm a newbie with SOAP::Lite. I was adding some parameter validation in server side and follow the explanations on http://cookbook.soaplite.com/#soap%20faults about how to setup error codes to give better explanations about the invalid parameters. Everything looks fine, but I'm alway getting an HTTP 500 error in the HTTP header: SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x136a3fc) SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error Connection: close Date: Wed, 27 Apr 2011 15:48:08 GMT Server: Apache/2.2.17 (Win32) Content-Length: 637 Content-Type: text/xml; charset=utf-8 Client-Date: Wed, 27 Apr 2011 15:48:09 GMT Client-Peer: 127.0.0.1:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.712 <?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:namesp1="http://namespaces.soaplite.com/perl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenc="http://schemas.xmlsoap.org/so ap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault> <faultcode>soap:Server.Custom</faultcode><faultstring>Invalid state string: 'ef'</faultstring><detail><BadState xsi:type="namesp1:BadState"><code xsi:type="xsd:int">1</code></BadState></detail></soap:Fault> </soap:Body></soap:Envelope> While the SOAP fault code looks ok, I'm wondering if the HTTP header is the correct one. Of course this will happen (once I'm using the Perl die function in the CGI) but it seems to me more resonable that the HTTP error should be "400 Bad Request" since the server was able to process the request, but the parameter(s) is(are) invalid. So my first question is: should I worry about that? Question 2: if I should, how should I change that? I'm using SOAP::Transport::HTTP::CGI in the server side to process the requests. Thanks, Alceu |
|
From: Sean C. <sea...@gm...> - 2011-03-22 12:41:03
|
Thanks, Thomas. I finally got it to work. A couple of things I found out: If using an https endpoint, it seems that LWP wants the specified protocol to be https. This is different from what I read everywhere which led me to believe that specifying http would cover both http and https. Also, since I was using a .pm which was built from the wsdl using stubmaker.pl, I needed to go into the pm to add the proxy info, as I was having difficulty accessing the http layer from my script. Not the best approach, but did the trick. I didn't have this issue with another script which is making SOAP calls, but is not dependent on a stubmaker-generated pm. Thanks again! Sean On Mon, Mar 21, 2011 at 8:37 AM, Thomas J. Pinkl <Tho...@sx...>wrote: > On 03/20/2011 08:58 AM, Sean Case wrote: > > We have a firewall and the preferred method is to go through a proxy to > > get out. I have tried this: > > $api->transport->proxy(http => $proxy); which yielded: FATAL ERROR:: > > proxy: transport protocol not specified > > > > I have also tried other variations (as found at > > http://cookbook.soaplite.com/ and also in the SOAP::Lite PODs) which get > > the same result. > > Also, I have tried: $ENV{'HTTP_proxy'} = $proxy; which got: FATAL > > ERROR:: 500 Connect failed: connect: Connection refused; Connection > > refused at... > > so that appears to not even be setting it (our firewall doesn't seem > > to be acknowledging the proxy when I use this). The admins have tested > > out the firewall to check that it will actually pass through to the > > correct endpoints and they can't see the script even hitting the proxy. > > I have been searching around and I haven't found any examples where > > someone has tried this and succeeded, so I'm not sure what the root > > cause is. Any assistance would be greatly appreciated. > > SOAP::Lite uses LWP::UserAgent, so its proxy configuration applies. > > My SOAP::Lite clients do something like: > > | if ($ENV{http_proxy}) { > | $soap->proxy($endpoint, $timeout, env_proxy => 1); > | } else { > | $soap->proxy($endpoint, $timeout); > | } > > Note that the environment variable name is "http_proxy" (all lower-case) > and not "HTTP_proxy". > > -- > Thomas J. Pinkl > Senior Systems Architect > Health Business Systems, Inc. (An SXC Company) > 738 Louis Drive > Warminster, PA 18974 > T: (215) 491-0763 > (800) 444-1427 > F: (267) 280-5101 > http://www.HBSRx.com/ > > > This communication, including any attachments, may contain information that > is confidential and may be privileged and exempt from disclosure under > applicable law. It is intended solely for the use of the individual or > entity to which it is addressed. If you are not the intended recipient, you > are hereby notified that any use, disclosure, dissemination, or copying of > this communication is strictly prohibited. If you have received this > communication in error, please notify the sender. Thank you for your > cooperation. > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Soaplite-devel mailing list > Soa...@li... > https://lists.sourceforge.net/lists/listinfo/soaplite-devel > |
|
From: Thomas J. P. <Tho...@sx...> - 2011-03-21 12:52:51
|
On 03/20/2011 08:58 AM, Sean Case wrote: > We have a firewall and the preferred method is to go through a proxy to > get out. I have tried this: > $api->transport->proxy(http => $proxy); which yielded: FATAL ERROR:: > proxy: transport protocol not specified > > I have also tried other variations (as found at > http://cookbook.soaplite.com/ and also in the SOAP::Lite PODs) which get > the same result. > Also, I have tried: $ENV{'HTTP_proxy'} = $proxy; which got: FATAL > ERROR:: 500 Connect failed: connect: Connection refused; Connection > refused at... > so that appears to not even be setting it (our firewall doesn't seem > to be acknowledging the proxy when I use this). The admins have tested > out the firewall to check that it will actually pass through to the > correct endpoints and they can't see the script even hitting the proxy. > I have been searching around and I haven't found any examples where > someone has tried this and succeeded, so I'm not sure what the root > cause is. Any assistance would be greatly appreciated. SOAP::Lite uses LWP::UserAgent, so its proxy configuration applies. My SOAP::Lite clients do something like: | if ($ENV{http_proxy}) { | $soap->proxy($endpoint, $timeout, env_proxy => 1); | } else { | $soap->proxy($endpoint, $timeout); | } Note that the environment variable name is "http_proxy" (all lower-case) and not "HTTP_proxy". -- Thomas J. Pinkl Senior Systems Architect Health Business Systems, Inc. (An SXC Company) 738 Louis Drive Warminster, PA 18974 T: (215) 491-0763 (800) 444-1427 F: (267) 280-5101 http://www.HBSRx.com/ This communication, including any attachments, may contain information that is confidential and may be privileged and exempt from disclosure under applicable law. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender. Thank you for your cooperation. |
|
From: Sean C. <sea...@gm...> - 2011-03-20 12:58:27
|
<https://sourceforge.net/users/> We have a firewall and the preferred method is to go through a proxy to get out. I have tried this: $api->transport->proxy(http => $proxy); which yielded: FATAL ERROR:: proxy: transport protocol not specified I have also tried other variations (as found at http://cookbook.soaplite.com/ and also in the SOAP::Lite PODs) which get the same result. Also, I have tried: $ENV{'HTTP_proxy'} = $proxy; which got: FATAL ERROR:: 500 Connect failed: connect: Connection refused; Connection refused at... so that appears to not even be setting it (our firewall doesn't seem to be acknowledging the proxy when I use this). The admins have tested out the firewall to check that it will actually pass through to the correct endpoints and they can't see the script even hitting the proxy. I have been searching around and I haven't found any examples where someone has tried this and succeeded, so I'm not sure what the root cause is. Any assistance would be greatly appreciated. Thanks, Sean |
|
From: Dropbox <no-...@dr...> - 2011-02-17 12:07:41
|
Chaitanya Yanamadala wants you to use Dropbox to sync and share files online and across computers. Get started here: http://www.dropbox.com/link/20.PWBitiLwyu/NjY4MzgzNjczNw?src=referrals_bulk9 - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/925ccbefe802/soaplite-devel%40lists.sourceforge.net |
|
From: Martin K. <mar...@fe...> - 2011-01-05 17:48:45
|
Hi Rahed, SOAP::Lite does not publish WSDL documents from a service. The long explanation is that due to perl being a weakly typed language, it's not possible (without additional tricks) to build WSDL documents from a perl web service like in Java or .NET. The short is that this feature does not exist in SOAP::Lite You'll have to add them as standard webserver document. Best regards, Martin Am Mittwoch, den 08.12.2010, 11:58 +0100 schrieb rahed: > Hello, > > I use SOAP::Lite server over http and need to publish the wsdl > document in the server. > The document should be rendered by the browser at a port where the web > service is available. > > The path should by something like > > http://host:7777/wsdldoc?WSDL > > Some other web services frameworks use this but with SOAP::Lite I don't > know how to implement this functionality. > > Any hint? > > Thank you much. > |
|
From: deepak g. <dee...@ya...> - 2010-12-23 15:43:20
|
It is giving the following error: couldn't find diagnostic data in /System/Library/Perl/5.10.0/pods/perldiag.pod /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 . Makefile.PL at /System/Library/Perl/5.10.0/diagnostics.pm line 268, <POD_DIAG> line 647. Please help its urgent. Thanks. |
|
From: rahed <ra...@gm...> - 2010-12-08 10:59:44
|
Hello, I use SOAP::Lite server over http and need to publish the wsdl document in the server. The document should be rendered by the browser at a port where the web service is available. The path should by something like http://host:7777/wsdldoc?WSDL Some other web services frameworks use this but with SOAP::Lite I don't know how to implement this functionality. Any hint? Thank you much. -- Radek |
|
From: Thorsten S. <tsc...@am...> - 2010-11-12 15:43:19
|
Guten Tag Chaitanya Yanamadala, am Freitag, 12. November 2010 um 12:36 schrieben Sie: > Can any one help me on this? Your question is really not related to SOAP::Lite, but much too general. What you really want is to discuss your problem in general, maybe on perlmonks.org, because your architecture seems broken by design to me. If you wnat some clients to do some work, let the clients get the work if they need it. The clients know when they are idle or finished and they can contact the server much easier, think of firewalls and all that stuff. Maybe you should start reading some books on how to efficiently parallelize work before you get to details like how to determine that anyone is idle. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tsc...@am... Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow |
|
From: Chaitanya Y. <dr....@gm...> - 2010-11-12 11:36:42
|
Hai
i am developing an application with some thing like this in mind.
SERVER
|
|
----------------------------
| | |
CLIENT CLIENT CLIENT
a server is connected to three client machines. when the client is ideal i
need to send a file from the server to the client and process a request in
the client machine and resend the files back to the server.
I am thinking of using the soap for this.
So first i need to do is get the cpu load of the client machine from server
itself. how do i do that?
Can any one help me on this?
Regards
Chaitanya
|
|
From: Jonathon P. <jon...@gm...> - 2010-10-07 21:10:59
|
> From: Alex Peeters <alex.peeters@ci...> - 2010-09-02 07:04
> Data structure totally difference between v0.69 and later versions.
>
> SOAP::Lite v0.69
> $VAR1 = {
> 'getByCompanyIdResponse' => {
> 'result' => bless( { snipped }, 'Data30bisPortail' )
> }
> };
>
> SOAP::Lite v0.72
> $VAR1 = \bless( { snipped }, > 'SOAP::Data' ),
I'm having to maintain code which is breaking on upgrading from 0.69
-> 0.71, and seeing the same behaviour, specifically when calling
->value() on SOAP::Data objects. In v0.69, code like this works:
$element = $envelope->dataof('[0]'); ## $envelope is a SOAP::SOM object.
$something = $element->value->{'key'} ## ->value() returns a hashref.
However in 0.712, SOAP::Data->value() is returning a SOAP::Data
object, within which there is are SOAP::Data objects for each
sub-element, where before it used to return a hashref.
Is there any particular way to call value, or set a parameter to have
SOAP::Lite revert to it's previous behaviour?
Regards,
Jonathon Padfield
|
|
From: Thorsten S. <tsc...@am...> - 2010-09-16 14:22:58
|
Guten Tag Martin Kutter,
am Donnerstag, 16. September 2010 um 15:22 schrieben Sie:
> newer versions of SOAP::Lite do an encode('UTF-8', $content) around the
> XML content.
Thanks, but where is the encoding applied? I'm just interested because
I didn't find anything in the serializer, server or transport package
and even searched the whole file for UTF-8.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tsc...@am...
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
|
|
From: Martin K. <mar...@fe...> - 2010-09-16 13:23:16
|
Hi,
newer versions of SOAP::Lite do an encode('UTF-8', $content) around the
XML content.
Newer versions of perl (I think since 5.8.5, but I'm not sure) use UTF-8
as their internal string representation, and accept either UTF-8 or
platform encoding as input. Thus, the combination of both may have lead
to the unexpected fix ;-)
Best regards,
Martin
Am Mittwoch, den 15.09.2010, 15:38 +0200 schrieb Thorsten Schöning:
> Hello,
>
> I have a simple soap server using the pretty old version 0.55 of
> SOAP::Lite. The server should send UTF-8 encoded strings, which
> doesn't work with this old version. The interesting thing is that my
> application logic behind the server does not generate a valid UTF-8
> perl string with UTF-8-flag set, but just windows-1252 and leaves the
> rest to SOAP::Lite. This is an error, but it works in newer versions
> of perl. In the old version even if my application generates a proper
> UTF-8-perl-string with flag set the response is not valid UTF-8.
>
> I thought that the new versions of SOAP::Lite are simply just encoding
> the response before sending it to the client, but I can't find any
> place where this encoding may happen. How does it work that SOAP::Lite
> can send proper UTF-8-Strings even with non-UTF-8 input? Is there any
> encoding I just didn't find?
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
|
|
From: Thorsten S. <tsc...@am...> - 2010-09-15 13:38:22
|
Hello, I have a simple soap server using the pretty old version 0.55 of SOAP::Lite. The server should send UTF-8 encoded strings, which doesn't work with this old version. The interesting thing is that my application logic behind the server does not generate a valid UTF-8 perl string with UTF-8-flag set, but just windows-1252 and leaves the rest to SOAP::Lite. This is an error, but it works in newer versions of perl. In the old version even if my application generates a proper UTF-8-perl-string with flag set the response is not valid UTF-8. I thought that the new versions of SOAP::Lite are simply just encoding the response before sending it to the client, but I can't find any place where this encoding may happen. How does it work that SOAP::Lite can send proper UTF-8-Strings even with non-UTF-8 input? Is there any encoding I just didn't find? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tsc...@am... Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow |
|
From: Thorsten S. <tsc...@am...> - 2010-09-03 08:29:32
|
Guten Tag Alex Peeters, am Donnerstag, 2. September 2010 um 07:54 schrieben Sie: > Data structure totally difference between v0.69 and later versions. Did I oversee it or is there no problem description in your mail? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tsc...@am... Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow |
|
From: Alex P. <ale...@ci...> - 2010-09-02 07:04:56
|
Data structure totally difference between v0.69 and later versions.
SOAP::Lite v0.69
$VAR1 = {
'getByCompanyIdResponse' => {
'result' => bless( {
'inputCompanyIdValid' => 0,
'companyId' => '0',
'companyState' => undef,
'reserveMakingDate' => undef,
'companyPostalcode' => '0',
'companyName' => undef,
'reserveMakingConcept' => 0,
'reserveContractorDate' => undef,
'noss' => '0',
'reserveContractorConcept' => 0,
'errorCode' => '0',
'inputNossValid' => 1,
'analyseDate' => undef
}, 'Data30bisPortail' )
}
};
SOAP::Lite v0.72
$VAR1 = \bless( {
'_signature' => [],
'_value' => [
bless( {
'_name' => 'getByCompanyIdResponse',
'_uri' =>
'http://www.bea.com/webservices/basic/statelesSession',
'_signature' => [],
'_value' => [
\bless( {
'_signature' => [],
'_value' => [
bless( {
'_name' => 'result',
'_signature' => [],
'_value' => [
\bless( {
'_signature' => [],
'_value' => [
bless( {
'_name' => 'analyseDate',
'_signature' => [],
'_value' => [
undef
],
'_prefix' => '',
'_attr' => {
'xsi:nil' => 'true',
'{http://www.w3.org/2001/XMLSchema-instance}nil' => 'true'
}
},
'SOAP::Data' ),
------------------
SOAP::Lite v0.69
bash-3.00$ ./check_WebServiceAttest30bis.pl --environment=P
--webservice=Attest30bis --cluster=https://www.socialsecurity.be
--trendline=6 --onDemand=Y --debug=T --asnmtapEnv='F|F|F'
ASNMTAP::Asnmtap::Plugins::SOAP::get_soap_request: () -->
SOAP::Transport::HTTP::Client::send_receive: POST
https://www.socialsecurity.be/attest30bis-service-ws/Attest30bisws_1_1
HTTP/1.1
Accept: text/xml
Accept: multipart/*
Accept: application/soap
Content-Length: 651
Content-Type: text/xml; charset=utf-8
SOAPAction: "/getByCompanyId"
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:stat="http://www.bea.com/webservices/basic/statelesSession">
<soapenv:Body>
<getByCompanyId
xmlns:stat="http://www.bea.com/webservices/basic/statelesSession">
<longVal xsi:type="xsd:long">100006</longVal>
</getByCompanyId>
</soapenv:Body>
</soapenv:Envelope>
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
Connection: close
Date: Mon, 05 Jul 2010 11:51:39 GMT
Server: Apache
Content-Length: 1309
Content-Type: text/xml; charset=iso-8859-1
Client-Date: Mon, 05 Jul 2010 11:51:39 GMT
Client-Peer: 10.60.200.50:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=BE/O=GlobalSign nv-sa/OU=ServerSign
CA/CN=GlobalSign ServerSign CA
Client-SSL-Cert-Subject:
/C=BE/ST=BE/L=Brussels/O=Onss/OU=Smals/CN=www.socialsecurity.be/emailAddress=pk...@sm...
Client-SSL-Cipher: DHE-RSA-AES256-SHA
Client-SSL-Warning: Peer certificate not verified
Set-Cookie:
JSESSIONID=1LxZMxHLGJdTLqM1Mpyh9bS7GV3VmTnf4yp6MMDmTjk9rxKwhhBZ!-1335879182;
path=/
<?xml version="1.0" encoding="iso-8859-1"
standalone="yes"?><env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><env:Body
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><m:getByCompanyIdResponse xmlns:m="http://www.bea.com/webservices/basic/statelesSession"><result xmlns:n1="java:be.smals.attest30bis.service.domain" xsi:type="n1:Data30bisPortail"><analyseDate xsi:nil="true"></analyseDate><companyId xsi:type="xsd:long">0</companyId><companyName xsi:nil="true"></companyName><companyPostalcode xsi:type="xsd:long">0</companyPostalcode><companyState xsi:nil="true"></companyState><errorCode xsi:type="xsd:int">0</errorCode><inputCompanyIdValid xsi:type="xsd:boolean">false</inputCompanyIdValid><inputNossValid xsi:type="xsd:boolean">true</inputNossValid><noss xsi:type="xsd:long">0</noss><reserveContractorConcept xsi:type="xsd:boolean">false</reserveContractorConcept><reserveContractorDate xsi:nil="true"></reserveContractorDate><reserveMakingConcept xsi:type="xsd:boolean">false</reserveMakingConcept><reserveMakingDate
xsi:nil="true"></reserveMakingDate></result></m:getByCompanyIdResponse></env:Body></env:Envelope>
ASNMTAP::Asnmtap::Plugins::SOAP::get_soap_request: () <->
ASNMTAP::Asnmtap::Plugins::SOAP::_soapCheckTransportStatus: 200 OK
ASNMTAP::Asnmtap::Plugins::SOAP::get_soap_request: SCALAR:
Data30bisPortail=HASH(0xa4e2f0)
$VAR1 = {
'getByCompanyIdResponse' => {
'result' => bless( {
'inputCompanyIdValid' => 0,
'companyId' => '0',
'companyState' => undef,
'reserveMakingDate' => undef,
'companyPostalcode' => '0',
'companyName' => undef,
'reserveMakingConcept' => 0,
'reserveContractorDate' => undef,
'noss' => '0',
'reserveContractorConcept' => 0,
'errorCode' => '0',
'inputNossValid' => 1,
'analyseDate' => undef
}, 'Data30bisPortail' )
}
};
ASNMTAP::Asnmtap::Plugins::SOAP::get_soap_request: () <--
Start time : Mon Jul 5 13:51:38 2010
End time : Mon Jul 5 13:51:39 2010
Trendline : 6
Response time: 0.637
Debug : 1
State : OK
Message : Web Service Attestation 30 bis (Production)
Alert : 200 OK - Attest30bis@https://www.socialsecurity.be: OK
OK - Web Service Attestation 30 bis (Production): 200 OK -
Attest30bis@https://www.socialsecurity.be: OK|'consult'=563ms;;;;
Status=0;1;2;0;3 Compilation=955ms;;;0; Trendline=0.637s;6;;;
Execution=1593ms;;;0;
------------------------------------------------------------------------------------------------
SOAP::Lite v0.72
bash-3.00$ ./check_WebServiceAttest30bis.pl --environment=P
--webservice=Attest30bis --cluster=https://www.socialsecurity.be
--trendline=6 --onDemand=Y --debug=T --asnmtapEnv='F|F|F'
ASNMTAP::Asnmtap::Plugins::SOAP::get_soap_request: () -->
SOAP::Transport::HTTP::Client::send_receive: POST
https://www.socialsecurity.be/attest30bis-service-ws/Attest30bisws_1_1
HTTP/1.1
Accept: text/xml
Accept: multipart/*
Accept: application/soap
Content-Length: 651
Content-Type: text/xml; charset=utf-8
SOAPAction: "/getByCompanyId"
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:stat="http://www.bea.com/webservices/basic/statelesSession">
<soapenv:Body>
<getByCompanyId
xmlns:stat="http://www.bea.com/webservices/basic/statelesSession">
<longVal xsi:type="xsd:long">100006</longVal>
</getByCompanyId>
</soapenv:Body>
</soapenv:Envelope>
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
Connection: close
Date: Mon, 05 Jul 2010 11:51:39 GMT
Server: Apache
Content-Length: 1309
Content-Type: text/xml; charset=iso-8859-1
Client-Date: Mon, 05 Jul 2010 11:51:39 GMT
Client-Peer: 10.60.200.50:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=BE/O=GlobalSign nv-sa/OU=ServerSign
CA/CN=GlobalSign ServerSign CA
Client-SSL-Cert-Subject:
/C=BE/ST=BE/L=Brussels/O=Onss/OU=Smals/CN=www.socialsecurity.be/emailAddress=pk...@sm...
Client-SSL-Cipher: DHE-RSA-AES256-SHA
Client-SSL-Warning: Peer certificate not verified
Set-Cookie:
JSESSIONID=8J0qMxHLBT47KhhZBkqxcCvnPT5fb8vbr5rnjZGqlRFFP1M8jZJV!-1318573972;
path=/
<?xml version="1.0" encoding="iso-8859-1"
standalone="yes"?><env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><env:Body
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><m:getByCompanyIdResponse xmlns:m="http://www.bea.com/webservices/basic/statelesSession"><result xmlns:n1="java:be.smals.attest30bis.service.domain" xsi:type="n1:Data30bisPortail"><analyseDate xsi:nil="true"></analyseDate><companyId xsi:type="xsd:long">0</companyId><companyName xsi:nil="true"></companyName><companyPostalcode xsi:type="xsd:long">0</companyPostalcode><companyState xsi:nil="true"></companyState><errorCode xsi:type="xsd:int">0</errorCode><inputCompanyIdValid xsi:type="xsd:boolean">false</inputCompanyIdValid><inputNossValid xsi:type="xsd:boolean">true</inputNossValid><noss xsi:type="xsd:long">0</noss><reserveContractorConcept xsi:type="xsd:boolean">false</reserveContractorConcept><reserveContractorDate xsi:nil="true"></reserveContractorDate><reserveMakingConcept xsi:type="xsd:boolean">false</reserveMakingConcept><reserveMakingDate
xsi:nil="true"></reserveMakingDate></result></m:getByCompanyIdResponse></env:Body></env:Envelope>
ASNMTAP::Asnmtap::Plugins::SOAP::get_soap_request: () <->
ASNMTAP::Asnmtap::Plugins::SOAP::_soapCheckTransportStatus: 200 OK
ASNMTAP::Asnmtap::Plugins::SOAP::get_soap_request: SCALAR:
Data30bisPortail=HASH(0xaabec0)
$VAR1 = \bless( {
'_signature' => [],
'_value' => [
bless( {
'_name' => 'getByCompanyIdResponse',
'_uri' =>
'http://www.bea.com/webservices/basic/statelesSession',
'_signature' => [],
'_value' => [
\bless( {
'_signature' => [],
'_value' => [
bless( {
'_name' => 'result',
'_signature' => [],
'_value' => [
\bless( {
'_signature' => [],
'_value' => [
bless( {
'_name' => 'analyseDate',
'_signature' => [],
'_value' => [
undef
],
'_prefix' => '',
'_attr' => {
'xsi:nil' => 'true',
'{http://www.w3.org/2001/XMLSchema-instance}nil' => 'true'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'companyId',
'_signature' => [],
'_value' => [
'0'
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:long',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}long'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'companyName',
'_signature' => [],
'_value' => [
undef
],
'_prefix' => '',
'_attr' => {
'xsi:nil' => 'true',
'{http://www.w3.org/2001/XMLSchema-instance}nil' => 'true'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'companyPostalcode',
'_signature' => [],
'_value' => [
'0'
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:long',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}long'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'companyState',
'_signature' => [],
'_value' => [
undef
],
'_prefix' => '',
'_attr' => {
'xsi:nil' => 'true',
'{http://www.w3.org/2001/XMLSchema-instance}nil' => 'true'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'errorCode',
'_signature' => [],
'_value' => [
'0'
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:int',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}int'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'inputCompanyIdValid',
'_signature' => [],
'_value' => [
0
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:boolean',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}boolean'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'inputNossValid',
'_signature' => [],
'_value' => [
1
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:boolean',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}boolean'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'noss',
'_signature' => [],
'_value' => [
'0'
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:long',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}long'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'reserveContractorConcept',
'_signature' => [],
'_value' => [
0
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:boolean',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}boolean'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'reserveContractorDate',
'_signature' => [],
'_value' => [
undef
],
'_prefix' => '',
'_attr' => {
'xsi:nil' => 'true',
'{http://www.w3.org/2001/XMLSchema-instance}nil' => 'true'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'reserveMakingConcept',
'_signature' => [],
'_value' => [
0
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'xsd:boolean',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{http://www.w3.org/2001/XMLSchema}boolean'
}
},
'SOAP::Data' ),
bless( {
'_name' => 'reserveMakingDate',
'_signature' => [],
'_value' => [
undef
],
'_prefix' => '',
'_attr' => {
'xsi:nil' => 'true',
'{http://www.w3.org/2001/XMLSchema-instance}nil' => 'true'
}
},
'SOAP::Data' )
],
'_attr' => {}
}, 'SOAP::Data' )
],
'_prefix' => '',
'_attr' => {
'xsi:type' => 'n1:Data30bisPortail',
'{http://www.w3.org/2001/XMLSchema-instance}type' =>
'{java:be.smals.attest30bis.service.domain}Data30bisPortail'
}
}, 'SOAP::Data' )
],
'_attr' => {}
},
'SOAP::Data' )
],
'_prefix' => 'm',
'_attr' => {}
}, 'SOAP::Data' )
],
'_attr' => {}
}, 'SOAP::Data' );
Not a HASH reference at ./check_WebServiceAttest30bis.pl line 143.
Start time : Mon Jul 5 13:51:33 2010
End time : Mon Jul 5 13:51:40 2010
Trendline : 6
Response time: 6.698
Debug : 1
State : UNKNOWN
Message : Web Service Attestation 30 bis (Production)
Alert : 200 OK
Error : HELP, THERE IS A PROBLEM WITH THE PLUGIN
UNKNOWN - Web Service Attestation 30 bis (Production): 200 OK ERROR:
HELP, THERE IS A PROBLEM WITH THE PLUGIN|'consult'=6253ms;;;;
Trendline=6.698s;
|
|
From: Alceu R. de F. Jr. <gla...@ya...> - 2010-08-31 13:50:56
|
----- Mensagem original ---- > De: Lyle <web...@co...> > Para: soa...@li... > Enviadas: Segunda-feira, 30 de Agosto de 2010 1:05:59 > Assunto: [Soaplite-devel] Pure Perl dependency chain? > > Which leaves Net::SSLeay, again I'm going to assume it's only loaded > if the SSL features in SOAP::Lite are used... Is there a PurePerl > alternative here? I understand that it would be painfully slow, but I > really need to keep a Pure Perl dependency chain for this project. This depends how the module was designed... maybe it's not possible to load Net::SSLeay during program execution. Why do you need to use "pure" Perl modules? It's possible to create a different repository of modules or, if you don't have a C compiler, compile the modules and generate a PAR for them. In Windows environment, I've being using Cava Packer (http://www.cava.co.uk/) successfully. Regards, Alceu |
|
From: Lyle <web...@co...> - 2010-08-30 04:23:18
|
Hi All, I see from:- http://deps.cpantesters.org/?module=SOAP%3A%3ALite&perl=5.8.8&os=any+OS&pureperl=on that SOAP::Lite depends on several XS modules. Compress::RAW::Zlib, Compress::RAW::Bzip2 are also required by LWP, so the chance of them not being in a minimal Perl install is... minimal. ExtUtils::ParseXS is only used by Test::POD so I'm assuming those tests would be skipped if not available. XML::Parser is the base of most XML modules, so likely to be installed, especially as it's included with ActiveState by default. Which leaves Net::SSLeay, again I'm going to assume it's only loaded if the SSL features in SOAP::Lite are used... Is there a PurePerl alternative here? I understand that it would be painfully slow, but I really need to keep a Pure Perl dependency chain for this project. Lyle |
|
From: Thorsten S. <tsc...@am...> - 2010-07-18 18:42:59
|
Guten Tag Martin Kutter, am Samstag, 17. Juli 2010 um 20:41 schrieben Sie: > Eliminating all (really) unnecessary copies would probably reduce memory > usage by a factor of between 2 and 10. Unfortunately, even this is > unlikely to happen: SOAP::Lite's test suite is far from being perfect, > and memory optimizations (and testing they don't break anything) would > require quite some effort - and it's not even sure memory usage would > drop below a level acceptable for you. Hi Martin, thanks for your answer. With some optimizations we at least can gain enough time until everyone runs 64 Bit systems. ;-) Today I reimplemented SOAP::Serializer::tag and ::xmlize in my own serializer and could drop memory usage about some hundred MBs with using array refs and string refs als elements instead of strings which are often copied twice or more. One approach I thought of was using our own data types which hold references to their data and recognizing them everywhere where SOAP::Lite needs to handle this data. Especially tag and xmlize are places where thos data type maybe recognized and changed to the standard ones, but that's now problem because SOAP::Lite gives one the possibility to override them very easy. If I find some of those places in the deserializer and maybe the transport layer, too, I'm optimistic to decrease memory usage to an acceptable level without breaking to much. > Unfortunately, SOAP::Lite doesn't have any means for streaming requests. > To my knowledge, there's also no other SOAP library in perl which has > direct support for streaming request, so you may need to roll your own. I don't think this will happen, it's more likely to just use 64 Bit systems and optimize serializer and deserializer to fit our needs. It's not even clear if we stick with perl on the server side. We did a project with Java and Axis2, this could be an option for new things, too. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tsc...@am... Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow |
|
From: Martin K. <mar...@fe...> - 2010-07-17 18:42:16
|
Hi Thorsten,
SOAP::Lite indeed copies the request data several times - in the
envelope creation (the one you suspected), the serializer (it keeps both
the original data and the XML form in memory), the deserializer, and, as
far as I know, twice in the transport layer (one for converting the XML
string to bytes, and one for passing the data to LWP::UserAgent by
value). This makes up for at least 4 copies for sending a request.
Using base64 also increases memory usage by 1.5, so the factor of > 20
you're reporting seems quite likely.
This behavior, however, is unlikely to change in the future: Passing
values by reference (instead of a pass-by-value, which means copying)
would require API changes and possibly break existing applications.
Eliminating all (really) unnecessary copies would probably reduce memory
usage by a factor of between 2 and 10. Unfortunately, even this is
unlikely to happen: SOAP::Lite's test suite is far from being perfect,
and memory optimizations (and testing they don't break anything) would
require quite some effort - and it's not even sure memory usage would
drop below a level acceptable for you.
The best approach would be to avoid the memory usage problem altogether
and stream the request to the server.
Unfortunately, SOAP::Lite doesn't have any means for streaming requests.
To my knowledge, there's also no other SOAP library in perl which has
direct support for streaming request, so you may need to roll your own.
Martin
Am Donnerstag, den 15.07.2010, 13:06 +0200 schrieb Thorsten Schöning:
> Hello,
>
> we use SOAP::Lite to transfer binary files as Base64 encoded strings
> as a parameter like others within a normal Soap message. We are not
> using Soap with attachments or else and yet don't plan to use it for
> compatibility concerns. The Base64-encoding is handled in front of
> SOAP::Lite for historical reasons, too, therefore SOAP::Lite really
> does only see a very large, multi lined string.
>
> The problem is that this approach scales pretty bad. Transferring a 40
> MB binary file exceeds the amount of addressable RAM of the perl
> process on 32 Bit systems. The HTTP-communication itself is not a
> problem, but serialization and deserialization by SOAP::Lite seems to
> be. I don't think that using more than 2 GB of memory for handling
> maybe 100 MB of data is really necessary and tried to find my way
> through the serializer and deserializer to look if I can find which
> obviously blow up memory consumption. "envelope" in the serializer is
> one method after which the used memory increased to several hundreds
> of MB, the real big thing happens afterwards, though.
>
> The main thing envelope seems to do is creating SOAP::Data-instances
> for existing data. Looking at SOAP::Data::set_value it seems to me
> it's copying data, but I'm not sure if it's always copying the data it
> gets how it gets it or always dereferencing it and really producing
> maybe unneeded copies.
>
> My soap call to SOAP::lite looks the following:
>
> eval{$t = $soap->elrev_EndUpload( SOAP::Data->new('name' => 'sessionid',
> 'type' => 'string',
> 'value' => $sessionid),
> SOAP::Data->new('name' => 'mandant',
> 'type' => 'string',
> 'value' => $mandant),
> SOAP::Data->new('name' => 'satzid',
> 'type' => 'string',
> 'value' => $dsnummer),
> SOAP::Data->new('name' => 'dateiinhalt',
> 'type' => 'string',
> 'value' => $$datei_ref),
> SOAP::Data->new('name' => 'einreichart',
> 'type' => 'string',
> 'value' => $art),
> SOAP::Data->new('name' => 'mailadresse',
> 'type' => 'string',
> 'value' => $email));};
>
> $$datei_ref holds the Base64 encoded file data.
>
> Calling the method this way I thought that only references to objects
> are handled in envelope and copying them doesn't really matter. But
> if SOAP::Data::set_value would copy the contents of the references the
> huge memory consumption could easily be explained because it seems
> SOAP::Data-objects are created very often.
>
> Am I right and set_value copies the content in the existing
> SOAP::Data-objects? Do you see any other apparently reasons why the
> memory consumption could be this high?
>
> Thanks to all.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
|
|
From: Thorsten S. <tsc...@am...> - 2010-07-15 11:06:18
|
Hello,
we use SOAP::Lite to transfer binary files as Base64 encoded strings
as a parameter like others within a normal Soap message. We are not
using Soap with attachments or else and yet don't plan to use it for
compatibility concerns. The Base64-encoding is handled in front of
SOAP::Lite for historical reasons, too, therefore SOAP::Lite really
does only see a very large, multi lined string.
The problem is that this approach scales pretty bad. Transferring a 40
MB binary file exceeds the amount of addressable RAM of the perl
process on 32 Bit systems. The HTTP-communication itself is not a
problem, but serialization and deserialization by SOAP::Lite seems to
be. I don't think that using more than 2 GB of memory for handling
maybe 100 MB of data is really necessary and tried to find my way
through the serializer and deserializer to look if I can find which
obviously blow up memory consumption. "envelope" in the serializer is
one method after which the used memory increased to several hundreds
of MB, the real big thing happens afterwards, though.
The main thing envelope seems to do is creating SOAP::Data-instances
for existing data. Looking at SOAP::Data::set_value it seems to me
it's copying data, but I'm not sure if it's always copying the data it
gets how it gets it or always dereferencing it and really producing
maybe unneeded copies.
My soap call to SOAP::lite looks the following:
eval{$t = $soap->elrev_EndUpload( SOAP::Data->new('name' => 'sessionid',
'type' => 'string',
'value' => $sessionid),
SOAP::Data->new('name' => 'mandant',
'type' => 'string',
'value' => $mandant),
SOAP::Data->new('name' => 'satzid',
'type' => 'string',
'value' => $dsnummer),
SOAP::Data->new('name' => 'dateiinhalt',
'type' => 'string',
'value' => $$datei_ref),
SOAP::Data->new('name' => 'einreichart',
'type' => 'string',
'value' => $art),
SOAP::Data->new('name' => 'mailadresse',
'type' => 'string',
'value' => $email));};
$$datei_ref holds the Base64 encoded file data.
Calling the method this way I thought that only references to objects
are handled in envelope and copying them doesn't really matter. But
if SOAP::Data::set_value would copy the contents of the references the
huge memory consumption could easily be explained because it seems
SOAP::Data-objects are created very often.
Am I right and set_value copies the content in the existing
SOAP::Data-objects? Do you see any other apparently reasons why the
memory consumption could be this high?
Thanks to all.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tsc...@am...
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
|
|
From: Thorsten S. <tsc...@am...> - 2010-07-12 06:36:23
|
Hello, I recently investigated some issues with transferring large files as Base64 directly in a SOAP message and came across the option compress_threshold we use in our SOAP-server and -client. Reading the docs only defalte or * is accepted as proper content encoding or the server will respond with HTTP 415. I found that our SOAP clients use gzip instead of deflate. I there any reason why gzip is not supported? It seemed to work if I change $COMPRESS to recognize gzip as well. Is there any way to set deflate manually? I only found compress_threshold, but not way to specify the encoding. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tsc...@am... Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow |
|
From: Thorsten S. <tsc...@am...> - 2010-06-23 07:43:37
|
Guten Tag Thorsten Schöning,
am Mittwoch, 23. Juni 2010 um 08:33 schrieben Sie:
>> sub DESTROY {
>> local $@;
>> eval {
>>
>> }
>> }
>> This restores $@ after the enclosing block.
> Thanks, I will try that later and would prefer that solution, too.
I tried that and it works, meaning with local $@ I can directly die in
my eval with $@ and get the error message as soap:Fault in the client,
without local the client gets an empty response again.
I will add local $@ just to be sure but stay with my eval because I
need it anyway. The methods I call do throw die with string messages
or Exception-objects, therefore I need something to distinguish what
comes.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tsc...@am...
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
|
|
From: Thorsten S. <tsc...@am...> - 2010-06-23 06:32:13
|
Guten Tag Martin Kutter,
am Dienstag, 22. Juni 2010 um 20:17 schrieben Sie:
> sub DESTROY {
> local $@;
> eval {
>
> }
> }
> This restores $@ after the enclosing block.
Thanks, I will try that later and would prefer that solution, too. I
hope it works even if the eval is down in some called methods
somewhere and not directly in DESTROY itself.
> And I heard yesterday in my local perl mongers group that perl 5.13
> automatically localizes $@ in DESTROY, but I fear upgrading is not an
> option ;-)
I surely can't force to use bleeding edge perl, right.
> What I don't read from your mails is whether your problem is already
> fixed by re-throwing a SOAP::Fault - so please send again if not.
Rethrowing the SOAP::Fault with the saved $@, like in my second
example, seems to work and the client gets the fault instead of an
empty response.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tsc...@am...
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
|
113 messages has been excluded from this view by a project administrator.
