[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 #6 from jacorb at goots.org  2012-07-30 15:05 -------

> 
>> 
>> 
>> > 
>> >> 
>> >> 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. 

Could you clarify your timing - have you measured a client calling onto your
server using standard sockets (i.e. no CORBA, but still uses TCP) in order to
eliminate JacORB from the equation? Or are you when you compare against JacORB
just using a single VM ? Hence my point below. 

> 
> 
>> 
>> 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?

I recommend JProfiler - commercial software available here:
http://www.ej-technologies.com/products/jprofiler/overview.html There are other
profilers available - pick whichever you prefer.

Please profile the code to see where the delay is happening. Feel free to debug
into it and analyse the code :-)

>> > 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"?

This is not 'internals of JacORB' but standard Java/CORBA. You might want to
read
http://www.amazon.co.uk/Java-Programming-CORBA-Distributed-Applications/dp/0471376817
and the CORBA specifications in order to understand this. 
Summarising - a single VM can hold 1 or more ORBs. You are using VM1+ORB1 to
talk to VM1+ORB1. I am proposing you change your code to use VM1+ORB1 and run
both the server and client on a single VM / 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.