[omniORB] [Q] AMI (messaging) for OmniOrb

[V S P]

Thank you so much for your explanations.
I started using the strategy you recommended (and the other poster)
and now have a 'working' prototype

where I use OmniOrb as communication mechanism that receives
simple synchronious requests -- and every Servant starts a pool
of worker threads using (Pion web server (that's based on boost's
asio)).

So I now have each corba servant that can receive corba requests,
process
them in worker threads -- and on top of it (as a bonus) each Omni
servant has a http interface (sort of a RESTful corba servants)
that can also invoke the processor plugins using a different entry
point.

So far everything is working fine, I made sure I see different thread
IDs
when processing.

I will later on add 'python' servants that also will use a pool of
worker
threads -- may be based on Twisted... (that also offers
HTTP and other interfaces) but right now I am doing the C++ 
servants.

thank you again
Vlad


On Tue, 10 Feb 2009 17:34:09 +0000, "Duncan Grisby" <duncan at grisby.org>
said:
> On Thursday 5 February, "V S P" wrote:
> 
> > I saw in '06 archives that Async Message Interface for OmniOrb has been
> > in consideration.
> > Has this been implemented (or may be in latests source archives)?
> 
> No, it hasn't been implemented. It's still something I'm considering if
> there's enough demand for it.
> 
> > Also if it is not available
> > is DII's send_deferred the only available way to achive this?
> 
> Yes, it's the only way to do a deferred synchronous call.
> 
> However, if you're still talking about the report server requirement
> you've been describing, neither AMI nor DII's send_deferred are
> appropriate. In both cases, the network connection between client and
> server has to remain in place for the entire duration of the call. It is
> dangerous to assume that that will always be the case if your report
> generation takes hours. It is far far safer to use a callback.
> 
> > Will I get an exception in the client if the server is down?
> 
> Probably. It depends whether the TCP layer notices that the server is
> down or not.
> 
> > ( I read that using send_oneway is not going to provide that).
> 
> That is correct, since a oneway call specifically does not wait for a
> response.
> 
> > I read in my Avanced Corba C++ book that to use Dynamic Invocation
> > I have to have Interface repository, but I saw in OmniORB example of
> > the echo service that it is not needed, is that are more or less
> > standard way that omniOrb deals with DII?
> 
> There is no need to have an interface repository to use DII. There is
> nothing in the DII interfaces that requires an IfR. If you want to make
> a generic object browser, you do need an IfR, but that's not the only
> use case of DII.
> 
> > I like the ability to have C++ and Python corba servers, however I I
> > need the non-blocking calls that apparently only supported by TAO ORB.
> > 
> > How do people do the non blocking client server and server/server
> > communications with omniOrb
> 
> They use callbacks!
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
-- 
  V S P
  toreason at fastmail.fm

-- 
http://www.fastmail.fm - The way an email service should be