Discussion:
[omniORB] [Q] AMI (messaging) for OmniOrb
V S P
2009-02-06 04:59:51 UTC
Permalink
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)?

Also if it is not available
is DII's send_deferred the only available way to achive this?

Will I get an exception in the client if the server is down?
( I read that using send_oneway is not going to provide that).

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?


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

( I am finally getting my corba vocabulary down, I think :-) )

thanks in advance,
Vlad
--
V S P
***@fastmail.fm
--
http://www.fastmail.fm - I mean, what is it about a decent email service?
Duncan Grisby
2009-02-10 23:34:10 UTC
Permalink
Post by V S P
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.
Post by V S P
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.
Post by V S P
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.
Post by V S P
( 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.
Post by V S P
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.
Post by V S P
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 --
-- ***@grisby.org --
-- http://www.grisby.org --
V S P
2009-02-11 02:35:51 UTC
Permalink
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
Post by Duncan Grisby
Post by V S P
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.
Post by V S P
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.
Post by V S P
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.
Post by V S P
( 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.
Post by V S P
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.
Post by V S P
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 --
-- http://www.grisby.org --
--
V S P
***@fastmail.fm
--
http://www.fastmail.fm - The way an email service should be
Loading...