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

Added a conccurrent version of the sortable lazy list. #284

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Added a conccurrent version of the sortable lazy list. #284

wants to merge 2 commits into from

Conversation

ripdajacker
Copy link

We ran into some issues with very fast updates to a MGrid using a ListContainer with a SortableLazyList.

The issue occurred during a call to getItemIds in the list container.
This calls lazyList.subList() which, in our application, threw ArrayIndexOutOfBoundsException.
This was caused by the list being updated from our datasource (rest service) during an iteration.

@Override
public int size() {
try {
tryLock();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn’t it be better to move tryLock() out of this try-block? Otherwise the finally might try to unlock a non-existing lock and throw (another) exception.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that would be a better solution.

@ripdajacker
Copy link
Author

I added the proposed change to the latest commit.

@mstahv
Copy link
Member

mstahv commented Feb 24, 2017

Hi,

Sorry it took bit long to answer, I have been too busy with V8 release lately.

Are you using the same container for multiple components/users?

Is this slightly related to #280 ?

Do you think we could also have a test for this?

cheers,
matti

@ripdajacker
Copy link
Author

Hey,

The container in question is used by one user, but the view listens for changes in the underlying datastructure.
So you can request a page count and expect n elements, but between your count() call and your findEntitites() call something was deleted.

#280 has a somewhat related symptom, but is still subject to race conditions when the underlying data changes. My pull request will probably resolve said issue.

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

Successfully merging this pull request may close these issues.

3 participants