Loading ...
Sorry, an error occurred while loading the content.

RE: [soaplite] Asynchronous messaging

Expand Messages
  • Keanan Smith
    To wit, there s no way to tell if a perl subroutine intends to return something, because even without an explicit return statement, a perl subroutine still
    Message 1 of 7 , Oct 24, 2002
      To wit, there's no way to tell if a perl subroutine 'intends' to return
      something, because even without an explicit 'return' statement, a perl
      subroutine still returns the value of the last statement executed, in
      effect, a perl subroutine always returns *something* it's just a question if
      the author of the subroutine put something usefull there, and if the user of
      the subroutine wants it. Neither of which can be examined from the method

      WSDL or some kind of method-defining language of some sort would be required
      for that kind of logic to be even possible.

      There are several usefull combinations using fork, in addition to the
      server-side one (Guessing at how to clean up after a spawned process from
      the middle of a soap service is messy at best, admittedly)

      If you as the client-writer, know you don't need whatever value the server
      returns you could simply do:
      if (fork)

      in your client, resulting in a notification call to your server, and your
      main program not even having to acknowledge that it sent it, this is
      probably the fastest fork-based implementation of what you particularly want
      to do.

      I've also written a couple of fork-based catch-throw implementations,
      similar to what the fellow from Grand Central was talking about, where your
      'client' forks a 'listening' agent (Actually a soap server in it's own
      right) and calls a service via soap, and ignores the return value as per
      above, and the 'server' forks off a new soap object which calls the soap
      service in your 'client' effectively turning both sides into client-servers,
      then your client simply needs a way to collect the messages from the
      'listening' agent to do something with them (IPC pipes work reasonably well,
      although I haven't found anything that works truely satisfactorly on Win32)
      both sides can implement a 'message session' to assossiate a given call with
      a given return, in the event the calls need to be associated (The particular
      implementation I wrote was a chat-client, so the client didn't need to know
      where the message from the server came from, but with soap, it's just as
      easy to send a lively little hash with message-id, authentication(which you
      need in your client too, if your client is a client-server), and anything
      else you want to stick in it :)

      All that being said, yes fork has some overhead issues (particularly if you
      try to do a bunch, a single fork that simply listens and passes message back
      to your main program isn't too bad, overhead-wise. Still, it's a good Idea
      to fork early to have less process state to duplicate) A more efficient
      implementation would use Perl's multi-threaded model, however it only exists
      in perl 5.8 and isn't entirely stable from what I've seen, and I have no
      Idea if SOAP is thread-safe :)

      Perhaps an alternative to forking on every SOAP call you want to disregard
      the return value of, would be to fork once at the beginning and use some
      kind of IPC messaging system between your main client process and your child
      and have the child simply perform the soap call, and be blocked until it
      returns but not have to worry about being blocked in the main program.

      -----Original Message-----
      From: Ryan Gammon [mailto:rggammon@...]
      Sent: Wednesday, October 23, 2002 11:39 PM
      To: soaplite@yahoogroups.com
      Subject: Re: [soaplite] Asynchronous messaging

      Paul Kulchenko wrote:

      >Hi Ryan,
      >--- Ryan Gammon <rggammon@...> wrote:
      >>But wouldn't it be nice if soap::lite servers could see that the
      >>being dispatched to isn't going to return anything, and allow the
      >>client to return immediately?
      >How would you know it? There is no such information in method

      The best answer I can think of here is to allow a soap::lite server to
      optionally parse the same wsdl file used for the client, and use that to
      determine return types.

      >>Or alternatively, give a dispatched function the
      >>ability to close the transport, and continue processing? Would the
      >>soap::lite powers that be like to see such a beast?
      >Don't see an easy way to do it without forking a process.

      The transports could be modified with a function that causes them to
      close on demand. I could call this function inside the method that has
      been dispatched to. On returning from the dispatched method, the handler
      of the transport in question would have to check to see if the transport
      had already been closed for it.

      >does some optimization on server side (if dispatched call is done in
      >void context response message will not be generated/serialized; used
      >for POP3 server). Which means that you can overload HTTP transport
      >and make a call in empty context, but still it will block before
      >processing is complete.

      Pretty slick. That's the first time I've seen wantarray.

      >>This is one of the big questions I have -- is it proper SOAP
      >>behavior to
      >>not return a xml response? (as opposed to a response by the
      >>mechanism, like a 2xx message in http -- that is definitely
      >I would say yes. In fact, it was discussed several times and it seems
      >like spec doesn't require response message to be present and it's ok
      >to send empty response (for example only 200OK). SOAP::Lite supports
      >this mode: you'll get undef instead of SOAP::SOM object in this case
      >(unless fault was returned, but SOAP response is also optional in
      >this case).

      That is indeed what I found with my TCP server with the redefined handler.

      >Hope it helps. I would like to discuss proper API for async calls,
      >because I want it to be implemented consistently for different
      >Best wishes, Paul.
      >Do you Yahoo!?
      >Y! Web Hosting - Let the expert host your web site

      To unsubscribe from this group, send an email to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.