RxtxChannel blocks forever when reading. #1390

Closed
trustin opened this Issue May 24, 2013 · 6 comments

Comments

Projects
None yet
4 participants
@trustin
Member

trustin commented May 24, 2013

From an e-mail:

Netty + RXTX works well on windows 7, but while we porting it to Linux(tested on both Digi Embedded Linux and Ubuntu 12), an important problem has meet.

Because RxtxChannel is using oiochannel framework, which has only one thread for a channel, and rxtx in linux is doing blocking read(readArray() from RXTX won't return unless there is data input). This will unable RXTXChannel from executing any task else - most significantly, can't write data to channel.

We consider this problem as a bug from RXTX(as its behavior is inconsistent cross platforms), and triggered by netty. We didn't find a proper workaround with current framework. Maybe currently this problem described above can be documented as known limitation to somewhere?

OioByteChannel should call InputStream.read() only when InputStream.available() returns a non-zero value. It's probably that the InputStream implementation of rxtx is not correct.

@normanmaurer

This comment has been minimized.

Show comment Hide comment
@normanmaurer

normanmaurer May 24, 2013

Member

From what I read we should set a receive timeout:

commPort.enableReceiveTimeout(1000):

http://mailman.qbang.org/pipermail/rxtx/2010-February/12654250.html

Member

normanmaurer commented May 24, 2013

From what I read we should set a receive timeout:

commPort.enableReceiveTimeout(1000):

http://mailman.qbang.org/pipermail/rxtx/2010-February/12654250.html

@listplot3d

This comment has been minimized.

Show comment Hide comment
@listplot3d

listplot3d May 29, 2013

commPort.enableReceiveTimeout() can workaround, and I have tested it with program that directly uses rxtx without Netty.
As for the value of timeout, below is what I get from mailing list:
One thing that catches many people is that 100ms is the minimum timeout. Anything under that is rounded to 0.

http://show.docjava.com/book/cgij/code/data/j4pDoc/serialPort/rxtx/RX

For the workaround applied in Netty, I suggest to make the timeout value 1000 a default configuration but also can be changed by user.

commPort.enableReceiveTimeout() can workaround, and I have tested it with program that directly uses rxtx without Netty.
As for the value of timeout, below is what I get from mailing list:
One thing that catches many people is that 100ms is the minimum timeout. Anything under that is rounded to 0.

http://show.docjava.com/book/cgij/code/data/j4pDoc/serialPort/rxtx/RX

For the workaround applied in Netty, I suggest to make the timeout value 1000 a default configuration but also can be changed by user.

@normanmaurer

This comment has been minimized.

Show comment Hide comment
@normanmaurer

normanmaurer Jun 10, 2013

Member

Fixed..

Member

normanmaurer commented Jun 10, 2013

Fixed..

@cmcmaugh

This comment has been minimized.

Show comment Hide comment
@cmcmaugh

cmcmaugh Feb 21, 2014

Contributor

Has this issue regressed?
I can see the READ_TIMEOUT setting in DefaultRxtxChannelConfig but I can't see it applied to commport either in master branch or 4.0 branch. Adding the following line to RxtxChannel.doConnect() stops it blocking for me - running on Ubuntu 13.10 64 bit.

 commPort.enableReceiveTimeout(config().getOption(READ_TIMEOUT));
Contributor

cmcmaugh commented Feb 21, 2014

Has this issue regressed?
I can see the READ_TIMEOUT setting in DefaultRxtxChannelConfig but I can't see it applied to commport either in master branch or 4.0 branch. Adding the following line to RxtxChannel.doConnect() stops it blocking for me - running on Ubuntu 13.10 64 bit.

 commPort.enableReceiveTimeout(config().getOption(READ_TIMEOUT));
@normanmaurer

This comment has been minimized.

Show comment Hide comment
@normanmaurer

normanmaurer Feb 21, 2014

Member

Could you open a PR with a fix?

Am 21.02.2014 um 15:57 schrieb cmcmaugh notifications@github.com:

Has this issue regressed?

I can see the READ_TIMEOUT setting in DefaultRxtxChannelConfig but I can't see it applied to commport either in master branch or 4.0 branch. Adding the following line to RxtxChannel.doConnect() stops it blocking for me - running on Ubuntu 13.10 64 bit.

commPort.enableReceiveTimeout(config().getOption(READ_TIMEOUT));

Reply to this email directly or view it on GitHub.

Member

normanmaurer commented Feb 21, 2014

Could you open a PR with a fix?

Am 21.02.2014 um 15:57 schrieb cmcmaugh notifications@github.com:

Has this issue regressed?

I can see the READ_TIMEOUT setting in DefaultRxtxChannelConfig but I can't see it applied to commport either in master branch or 4.0 branch. Adding the following line to RxtxChannel.doConnect() stops it blocking for me - running on Ubuntu 13.10 64 bit.

commPort.enableReceiveTimeout(config().getOption(READ_TIMEOUT));

Reply to this email directly or view it on GitHub.

@cmcmaugh

This comment has been minimized.

Show comment Hide comment
@cmcmaugh

cmcmaugh Feb 22, 2014

Contributor

Pull request #2259 opened - I've only tested it on ubuntu though.

Contributor

cmcmaugh commented Feb 22, 2014

Pull request #2259 opened - I've only tested it on ubuntu though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment