TCP Binding high CPU utilisation

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Place TCP binding jar in addons with any tcp item configured
2. start openhab and watch the CPU utilisation be exessively high - on my i5 
Windows 7 desktop with 4G RAM at 50% CPU utilisation. On my RPI at 100% 
utilisation even if no item is configured, 

What is the expected output? What do you see instead?
CPU utilisation is high. On Raspberry PI this is at 100% and interfacing to 
openhab from web client is painfully slow.
Expect relatively low CPU utlisation since the TCP binding is sending very 
little data to OH - something like a single message every 30 seconds. TCP 
overhead is small on i5, i7 as well as rPI. 

What version of the product are you using? On what operating system?
OpenHab 1.2 and 1.3 with the corresponding TCP bindings. Also used the most 
recent from the forum thread here: 
https://groups.google.com/forum/#!topic/openhab/qJo_48FDMGA but with the same 
results. Tried this on i5 desktop, i7 laptop, and raspberry PI TypeB.  

Please provide any additional information below.
Here is my comment from the thread: 

I have been using the old TCP binding from 1.2  in client mode but suffered 
with high CPU utilisation - something like 50% on i5 desktop. When I try this 
on my raspberry PI its at 100% CPU utilisation and so sluggish thats its 
useless on the rpi. Then I updated to Openhab 1.3 and this most recent TCP 
binding in this thread hoping to resolve this high CPU issue but with no luck. 
In this thread 
[https://groups.google.com/forum/#!searchin/openhab/tcp/openhab/hbIPcaW5gwE/Ps_p
x4_htNEJ] there is talk of a high CPU loop with selectNow and hasNext() 
methods. 
Is there any chance that this will be resolved in this updated TCP binding 
please?

Original issue reported on code.google.com by jasonhec...@gmail.com on 29 Sep 2013 at 7:35

[GoogleCodeExporter]

Fixed by https://github.com/openhab/openhab/pull/18

Original comment by kai.openhab on 1 Oct 2013 at 2:36

• Changed state: Fixed
• Added labels: Version-1.4.0

[GoogleCodeExporter]

Issue 482 has been merged into this issue.

Original comment by kai.openhab on 5 Oct 2013 at 3:29

[GoogleCodeExporter]

Plesse reopen, See Issue 482

Original comment by daniel.g...@gmail.com on 8 Oct 2013 at 7:52

[GoogleCodeExporter]

Could you please have a look, Karel?

Original comment by kai.openhab on 8 Oct 2013 at 8:46

• Changed state: Started

[GoogleCodeExporter]

Issue 482 has been merged into this issue.

Original comment by kai.openhab on 8 Oct 2013 at 8:46

[GoogleCodeExporter]

Jason,
Can you confirm that you tried this with the lateste TCP jar available from 
github?

In openhab.cfg you can add tcp:selecttimeout=xyx with xyz an internval in 
milliseconds. The default value is the latest version of the binding is 1000, 
and means that the binding will do a blocking Select() until a time-out after 
1000ms has passed. By tweaking this parameter you can change the 
CPU-load/behaviour of the binding, e.g. the frequency by which the binding 
polls for socket channels that are ready for communication.

Karel

Original comment by karel.go...@gmail.com on 8 Oct 2013 at 9:32

[GoogleCodeExporter]

May you please give me an hour before I setup,test and confirm this for you...

Original comment by jasonhec...@gmail.com on 8 Oct 2013 at 9:38

[GoogleCodeExporter]

I've tried values for tcp:selecttimeout=xyx of 10, 1000 and 10000. The 
javaw.exe process fully utilizes one of my cores.

Original comment by daniel.g...@gmail.com on 8 Oct 2013 at 10:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am unable to test right now at work but will later tonight.
My setup is to have OH as TCP Client to Twisted Matrix running TCP Server. On 
connection from the OH client Twisted then serves data to the client. In this 
case the data is the Rpi CPU Temperature. 
My item config is:  { tcp="<[192.168.0.201:2100]"} but this doesnt work as it 
did with 1.2. As suggested in 
https://groups.google.com/forum/#!topic/openhab/qJo_48FDMGA by Karel I then 
added the " after the port like this: { tcp="<[192.168.0.201:2100:"]"} but this 
doesnt work as well. The binding throws a null pointer exception. Sorry I cant 
get to the debug logs right now. 

Karel/ OH team: have you considered using an asynchronous networking library? I 
use twisted matrix [python lib]which uses callback and takes care of the 
blocking code. Someone else asked for a Java equivalent at StackOverflow: 
http://stackoverflow.com/questions/675093/twisted-in-java
and leads here:  http://www.zynaptic.com/reaction/ with the following:
Reaction is a flexible asynchronous programming framework which may be used to 
implement complex event-driven applications. It is heavily influenced by the 
Twisted programming framework developed by TwistedMatrix Labs for the Python 
programming language.
The focus of the Reaction library is on the concurrency and callback model and 
as such it is application neutral. Use it to manage lots of concurrent I/O or 
to farm out compute intensive tasks to multicore processors - it's your call. 
As well as being usable as a basic Java library, Reaction can also run as an 
independent OSGi service and integrate into any GUI framework you choose. Start 
digging into the user guide to find out more.

Original comment by jasonhec...@gmail.com on 8 Oct 2013 at 1:34

[GoogleCodeExporter]

Jason, will investigate Twisted asap. Opted for Java NIO as to be as std java 
as possible, and at the time I was experimenting with Quartz, so I went for 
that combination. 

As for your first question, the enable inbound communication, you need to add 
tcp:port=xyz to openhab.cfg (that is for the actual 1.4 jar). and you need to 
add ' ', not " , for example 'REGEX(.*)' or alike

K

Original comment by karel.go...@gmail.com on 8 Oct 2013 at 1:47

[GoogleCodeExporter]

Hi Karel, 
Note that Twisted is a python async networking framework. I understand trying 
to be as std as possible but then you have to deal with IO blocking code that 
others have already developed solutions/frameworks for. 
Is there a way to configure OH to have it be the TCP client but for incoming 
data [ie. OH inits the socket connection but the data flow is primary from the 
server to the OH client]
Or is the methodology that OH Tcp clients send data and OH TCP Server receive 
data? In my view the data direction [send or receive] should be decoupled from 
the socket initiating end [client or server].
Thanks and thanks for the help on the two single quotes rather than one double 
quote. ;)
J

Original comment by jasonhec...@gmail.com on 8 Oct 2013 at 2:51

[GoogleCodeExporter]

Hi Jason,
the wiki is not in sync anymore with the code in the repo. Pls see 
https://groups.google.com/forum/#!searchin/openhab/karel$20goderis$20tcp/openhab
/nvpJ5JXjUag/TVIiG1p49rwJ for a bit of an explanation - it does answer your 
question on directions, clients and servers ;-)

the high cpu stuff I need to test myself

K

Original comment by karel.go...@gmail.com on 8 Oct 2013 at 3:44

[GoogleCodeExporter]

Ok - First of all I slap myself on the head for  a very stupid bug that causes 
the selecttimeout parameter to be parsed incorrectly. That being said, after  
correction I can confirm that i has little impact. Putting it to 10000 (10 
seconds) did not change a lot because I think at each select Keys get selected 
for write operations. I tried tweaking the Quartz set up (thread pool size and 
priority) but that did not change anything at all. 

I then added a simple Thread.sleep(250) to slow down the Quartz thread and that 
did the trick. I will provide an official patch soon (hopefully tonight), I 
will first check the timeout that is used in AbstractActiveBinding, or 
alternatively, change the core of the TCP binding to be an extension of 
AbstractActiveBinding instead of AbstractBinding....

K

Original comment by karel.go...@gmail.com on 8 Oct 2013 at 4:23

[GoogleCodeExporter]

Fixed. (Commit awaiting approval/integration on github)

Original comment by karel.go...@gmail.com on 8 Oct 2013 at 8:01

[GoogleCodeExporter]

Great, thank you!
Am 08.10.2013 22:02 schrieb <openhab@googlecode.com>:

Original comment by daniel.g...@gmail.com on 8 Oct 2013 at 8:23

[GoogleCodeExporter]

Original comment by kai.openhab on 9 Oct 2013 at 7:33

• Changed state: Fixed

[GoogleCodeExporter]

1.4.0 Tcp binding works great. Thanks for the quick turn around. 
Much appreciated. Now I need to get it going on the Rpi.

Original comment by jasonhec...@gmail.com on 11 Oct 2013 at 10:38