Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASH frame handler - receive queue is full #1362

Open
mikomarrache opened this issue Dec 7, 2022 · 2 comments
Open

ASH frame handler - receive queue is full #1362

mikomarrache opened this issue Dec 7, 2022 · 2 comments

Comments

@mikomarrache
Copy link
Contributor

We encountered cases where the receiving queue of the ASH frame handler is full. Therefore, received frames are rejected (IllegalStateException : Queue full).

Here, we can see the queue capacity is set to 10. Also, the library doesn't expose methods to set the capacity during initialization.

private final BlockingQueue<EzspFrameResponse> recvQueue = new ArrayBlockingQueue<>(RX_QUEUE_LEN);

Is there a reason the capacity is set to 10? Do you think increasing the capacity could cause other issues?

Thanks

@sorinpenteleiciuc
Copy link

I also subscribe to your ideea to increase this size to at least 100.

@cdjackson
Copy link
Member

I think it's useful to understand why the queue fills up before making any change. @sorinpenteleiciuc I believe when we saw this problem with your system some time back it was caused by other activities taking a lot of time on your low powered processor.

IMHO it's always a difficult issue, and increasing the queue size may cause other problems. The queue is meant to manage a real-time incoming data stream - queuing a lot of frames will mean that frames may now be in the queue for many seconds, and this may mean that we are replying to data that has already been retried by the sending device if it doesn't get a timely response. This just causes more problems, and IMHO we're better off not to increase the queue size to tater for such instances, but it's better to drop the frames.

As an example, if we were to increase the queue size to 100 as suggested here, that means that we now have up to 100 frames in the queue to process, and this will likely be impossible. The system can only send (from memory) 10 to 20 frames per second, so we have 5 to 10 seconds worth of data in the queue, but the timeout will be in the order of 5 to 7 seconds, so we have a problem.

Thats my view - maybe I've missed something? And maybe 10 isn't the perfect number and I could be convinced to change it if there was a good rational - supported by logs and an understanding of why it's a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants