[jacorb-bugs] [Bug 925] Delay in serial (rxtx) communication

[bugzilla-daemon at jacorb.org]

http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=925





------- Comment #5 from kujtimhyseni at hotmail.com  2012-07-30 14:33 -------
Comments inline ...

(In reply to comment #4)
> Thanks for the reply.
> 
> Can you include documentation on what your various classes are supposed to do?

There are some other classes, but, I will describe only those employed in our
concern.

MISPSerial - serves for binding to actual port, sending requests and receiving
responses

BindServerImpl - this is where MISPSerial is instantiated and used. Further,
this class (BindServerImpl) makes our "to serial" class a true CORBA (JacORB)
class. In other words, our clients has to see our server as a true CORBA
server, this class makes it possible. Then, at this class the CORBA requests
are "translated" to COM "simplified requests and vice versa. Again, to
send/receive with COM it uses MISPSerial class.

BindServerServer - is where the BindServerImpl is instantiated and IOR file
produced. This is a common CORBA class.

BindServerClient - simple client application.  This is a common CORBA class.



> 
> 
> 
> > 
> >> 
> >> Can you include documentation on what your various classes are supposed to do?
> >> 
> >> It seems your code is still dependent on specialised hardware and you have not
> >> included an alternate implementation as I suggested - as the port communication
> >> should just be a byte stream that should be easy to simulate e.g. read a file
> >> to dummy it up. This would eliminate the gnu.io import dependency and make it
> >> simpler to test/reproduce.
> > 
> > I think that it is not good idea to "replace" serial i.e. gnu.io with simple
> > byte stream since the delay is faced in it i.e. gnu.io more precisely upon
> > receiving the reponse more precisely in method "public void serialEvent" which
> > when implemented in Java simple application (with main method) and recently
> > implemented within web service shows no delay.
> > The only replacement is the communication other PC instead with microcontroller
> > but still using gnu.io - for this I can provide the code for the "other PC".
> 
> I thought you said the delay was within JacORB communication and not within the
> serial communication via rxtx? If you are facing delays in rxtx you should
> contact them. Why can you not simulate the byte stream returned by by rxtx to
> demonstrate where you think the performance issue is in JacORB?

The delay is introduced when JacORB is employed. When I communicate with
external device from standard Java application or web service there is no
delay.
I've introduced comment logs during application execution and came in
conclusion that the delay is upon stream receiving, more precisely upon in
method "public void serialEvent". But, again, there is no delay when called
outside JacORB. 



> 
> Can you profile your client and server applications to demonstrate the problem?

Can you help with profiling? I saw that profiler is not a part of Java, it
should be downloaded from internet - isn't so?



> 
> 
> > 
> >> 
> >> If you wish to test to eliminate the overhead of the TCP/IIOP/etc you could run
> >> the client/server in the same ORB so that direct calls would be made instead.
> >> 
> > 
> > Currenlty I am doing test in the same ORB i.e. in same machine.
> 
> No you are doing it in different ORBs (in fact in separate virtual machines).
> My suggestion is to eliminate the TCP/IIOP marshalling to narrow down your
> issue and run the client and server in the same ORB. 

I don't know the internals of JacORB. I thought I am running them in the same
ORB since they are at the same machine (localhost). Can you help me with
"eliminating the TCP/IIOP marshalling to narrow down the issue and run the
client and server in the same ORB"?


-- 
Configure bugmail: http://www.jacorb.org/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.