[omniORB] IIOP Latency with Java

[Tres Seaver]

uche.ogbuji@fourthought.com wrote:
> 
> Running OmniORBpy with omni 2.8.0 on Red Hat 6.1 on the server side.  A
> development partner is connecting to this server using JDK 1.2 ORB on NT.  We
> are suffering an overhead of _exactly_ 20 milliseconds on each call (it almost
> feels like a strobe).  This overhead does not manifest itself on omni/Linux
> talking to omni/Linux remotely.  We tried Visibroker/Java on NT with the same
> result.  Does anyone know what might be causing this?  It feels like a config
> error because all the benchmarks we've seen of Visi/client to omni/server seem
> blazingly fast.  The input parameters as well as the return values are all
> simple strings.
> 
> Any ideas?  Trolling the list archives turned up murmurings of "TCP_NODELAY"
> and similar posible solutions, but it wasn't clear that they were applicable
> to our current situation.
> 
> I know sample code always helps.  Unfortunately, since we're dealing with a
> development partner it is easier to first see if this rings a bell with
> anyone.  If not, I'll try to work out some minimal code that illustrates the
> problems.

TCP_NODELAY would only apply to pretty small requests -- I think the minimum
IIOP header is around 128 bytes or so, and the Nagle algoritm (which TCP_NODELAY
suppresses) could kick in for methods passing no/few parameters, especially if
they are fixed-length and small.

Another possibility is that the JDK ORB is not sitting directly on a select()
call (for writability) or a condition.wait() (for outbound data available), but
instead is timer driven.  That would be pretty brain-dead, but then again,
stranger things have escaped from the labs before this.

-- 
=========================================================
Tres Seaver  tseaver@digicool.com   tseaver@palladion.com