[MOBY-dev] [moby] Try to create service from serialized WSDL, get strange SOAP::Lite error

Tue Feb 7 21:02:27 UTC 2006

Hi Mark,

At 02:43 PM 2/7/2006, you wrote:
>Hi Frank,
>
>I've read over your bug report below a few times and I can't quite
>extract from it what the bug actually is...  Can you paraphrase?

Yeah, I don't really blame you  - I've had a really hard time figuring out 
where the bug is myself! I've been working on this the past few days, and 
am happy to announce that I now have a deeper understanding of my 
confusion, though still no solution. [This posting turned out to be quite 
long.]

First of all, it turns out that the specific problem I see below occurs 
only when I run my code under the Perl debugger, through emacs. So that may 
be a complete red herring, perhaps symptomatic of something else. I'm using 
Perl 5.8.6 from the SuSE distribution on dual-CPU i686-architecture 
hardware, but compiled for i586 architecture (sysadmin thought that 
shouldn't be a problem), with thread-support enabled (ditto).

However, the problematic behaviour still exists. My code seg-faults 100% of 
the time. I can nail down the specifics a bit more precisely now. My goal 
is simple: cache WSDL locally, to avoid hitting MOBY Central too often, and 
to improve local performance in querying services: "discover once, use 
often" you might say. I can't keep service objects around, since I'm 
interested in using this in a web application, so services have to be 
constructed frequently. But they only need to be discovered sporadically 
(once an hour, once a day?). Simple enough.

I have tried serializing with Storable and Data::Dumper, and find the same 
fundamental problem with both, which leads me to believe that the problem 
doesn't lie with serialization as a concept, or as an implementation. This 
is a relief, since all I want to serialize is the WSDL for each service, 
which is a string. If I can't serialize a string, I'm in deeper trouble 
than I thought! ;-D

Using the serialized WSDL, I can thaw out ('deserialize'), successfully 
construct, and even execute services, so there is no inherent problem with 
the WSDL upon thawing. The MOBY::Client::Service objects returned are 
normal in every way. My problem comes when I try to return from the 
subroutine that does all this serializing, thawing, and reconstruction. The 
program crashes _always _and _only_ upon the return statement, and only 
when a MOBY::Client::Service has been created. If I simply serialize and 
thaw the WSDL, I get no problems upon returning.

Under certain circumstances, the seg fault is accompanied by a message that 
"REFCNT decremented below 0!". Looks like a garbage-collection problem, 
where the GC tries to free something that's already been freed! A further 
clue is provided by Pieter Neerincx (private communication), who mentioned 
that he had a very similar problem which he traced back to 
XML::LibXML.  The page 
http://cpan.uwinnipeg.ca/htdocs/XML-LibXML/Changes.html lists several 
recent bug fixes for threads from version 1.5.1 onwards (I'm using the 
latest, 1.5.8), including the specific one that Pieter encountered (the one 
using documentFragment()), which was supposedly fixed for 1.5.8.

In fairness, I don't think the problem lies with MOBY itself, since it 
mostly just uses XML::LibXML in a fairly generic way (calls parse() a lot, 
but that's about it). However, the bug is serious enough to prevent caching 
of MOBY services, and presumably other potential uses which attempt to hide 
MOBY's interface in modules. So it affects MOBY in that sense, albeit 
indirectly.

Briefly:
         use serialized WSDL, AND create MOBY::Client::Service, AND then 
return from subroutine ==> seg fault (always)
         use "fresh" WSDL, rest unchanged (can't cache services) ==> no seg 
fault
         don't return from subroutine, rest unchanged (can't encapsulate in 
other module) ==> no seg fault
         omit MOBY::Client::Service creation, rest unchanged  (can't do 
anything useful at all) ==> no seg fault
         otherwise ==> no seg fault (ever)

If you'd like to play around with it, go here: 
http://llama.med.harvard.edu/~fgibbons/tmp/api_moby.pl  to get the 
self-contained stub I'm using to investigate this. Use the $config hashref 
to turn on caching (CACHE_SERVICE_INFO => 1), and watch it fault. (You'll 
have to run it twice: once to build the cache, then again to use it). Then 
turn off caching, and watch it return normally.

I have NO IDEA where to go from here. I'd really rather not ask my sysadmin 
to build and reinstall Perl _without_ threads unless I'm positive that will 
cure my problems. If anyone has ANY ideas on where to go from here, I would 
be really, truly grateful.

TIA,

-Frank

>On Fri, 2006-02-03 at 12:41 -0500, Frank Gibbons wrote:
> >    Hi,
> >    It takes MOBY about half a second to retrieve WSDL from Central, to 
> build a
> >    service. In an effort to improve performance in an application that 
> may need
> >    to build many (maybe ten) services at a time, I'm trying to cache WSDL
> >    locally, and build services from that, as needed. I'm using Storable for
> >    serialization  in  Perl,  which has worked well for me in the past. To
> >    paraphrase Yogi Berra: "Half a second here, half a second there, 
> pretty soon
> >    you're talking about real time."
> >    I'm encountering a strange error in this, which appears to be emanating
> >    ultimately from SOAP::Lite (see below) In essence it says:
> >    Service description 'data:,<insert_wsdl_here> can't be loaded: 501 
> Protocol
> >    scheme '' is not supported
> >    The WSDL is URI_encoded by MOBY, not by me - I just supply an XML-text
> >    description to MOBY::Client::Service->new(), pretty much exactly as 
> provided
> >    from MCentral. I DO NOT see this problem when using the WSDL supplied by
> >    MOBY Central directly however, so there's clearly some kind of 
> problem with
> >    serialization. I'm wondering if any of you have seen a similar 
> behaviour in
> >    the past, and how you got around it. The WSDL I retrieve from the cache
> >    looks fine when I print it out, but I'm wondering if there might be some
> >    other funkiness to it that gets messed up with I store it.
> >    Thanks in advance.
> >    -Frank
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://biomoby.org/mailman/listinfo/moby-dev
>--

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 