[Xml-compile] Re: Errors returned by XML::Compile::SOAP::HTTPDaemon and a couple of other things

[Anton Berezin]

Hi Mark,

On Wed, Feb 03, 2010 at 02:36:31PM +0100, Mark Overmeer wrote:
> [moved to the XML-Compile mailinglist, because this is a subject of
> common interest]
> 
> * Anton Berezin (tobez at tobez.org) [100203 13:02]:
> > When trying to send stuff to a simple daemon, I kept getting "406 input
> > validation failed" with no explanation in the logs.  I had to doctor
> > SOAP/Server.pm to print $@ into a file right after
> > 
> >   $data = try { $decode->($xmlin) };
> > 
> > in compileHandler{}, and after that I had to doctor Schema/BuiltInFacets.pm
> > to print the error produced by _pattern{} into a file.
> > So my question is, do you have any idea why error() in _pattern{} did not
> > end up in the logs?
> 
> On the moment, the error message is only sent back to the client.  Didn't
> you see it as answer?  Should I log the client-produced error as "info"
> or "notice" in the server log-file? Probably smart.

Rats!  I did not see it in the response the client gets (I just used LWP
and POSTed test SOAP XML), but now that I look deeper into what is returned,
I can see the error message.  Thanks.

> Validation errors are sometimes quite hard to find. In many cases, where
> minOccurs=0, choice, substitionGroups or unions are at stake, we have to
> continue in alternatives which may succeed. On the moment none matched,
> then the logic does not know which failure was the cause of the problem.
> Add anywhere to your code:
> 
>    use Log::Report mode => 'DEBUG';
> 
> to get a lot of info about the matching attempts.  Also possible:
> 
>    try { .... } mode => 'DEBUG';    # or mode => 3

Well, I have 

  use Log::Report 'xi2mras', syntax => 'SHORT', mode => 3;

in the very beginning of the script, won't this do the same?  And I did not
see any logging corresponding to the matching attempts, maybe because of the
combination of "dispatcher PERL => 'default';" and the backgrounding of the
daemon.

> > Another question is that I don't seem to be able to tell the daemon NOT to
> > background itself
> 
> When I see the code in Net::Server (line 291), we have a problem:
> 
>   if (! $ENV{BOUND_SOCKETS}) {
>     ### background the process - unless we are hup'ing
>     if( $prop->{setsid} || defined($prop->{background}) ){
>       my $pid = eval{ safe_fork() };
>       if( not defined $pid ){ $self->fatal( $@ ); }
>       exit(0) if $pid;
>       $self->log(2,"Process Backgrounded");
>     }
> 
> Where I default to "background => 1", you cannot overrule that with
> an "background => 0" because of that uncommon "defined()" check around
> the boolean.

Argh.

> Net::Server option handling is a mess (far
> too many ways and inconsistent in behavior)   The author promissed me
> two years ago to come with a release which would fix it... but...
> 
> Maybe you could add after new()
>    delete $daemon->{server}{background};

> Hope it works.

Nope, does not work, prolly because "background" is passed to run(), not
new().

For now, I resorted to removing the setsid and background settings in
SOAP/Daemon.pm's default_values().

Another things I noticed, which is true with and without backgrounding.  The
daemon process dies after some time on its own:

[2]    11799 alarm      perl xi2mras.pl
note_report: perl xi2mras.pl completed in 40 seconds

Any idea what's this about?

\Anton.
-- 
Matters of elegance ought to be left to the tailor and to the cobbler.
  -- L. Boltzmann