commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (COLLECTIONS-661) Intermittent test failures in Windows for HashSetValuedHashMap
Date Wed, 11 Oct 2017 07:38:00 GMT


ASF GitHub Bot commented on COLLECTIONS-661:

GitHub user kinow opened a pull request:

    COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest

    The `getMap()` method, when testing a `HashSetValuedHashMap`, would return an object of
this type. Which is an instance of `SetValuedMap`.
    Running it in debug mode would - most of the times - run the tests and succeed. Running
normally - especially on Windows - would result in intermittent, but very frequent, failures.
    The `getMap()` method sometimes, depending on the order and execution of tests, will be
null. So the collection added to the map will be either a `Hashset`, or a `Arrays$ArrayList`.
When the types are different, `hashCode()` and `equals()` calls return incorrect values, resulting
in the errors we have seen in COLLECTIONS-661.
    A good solution would be to re-design the tests. The `TestMultiValuedMapAsMap` is testing
`MultiValuedMap`'s, which include `HashSetValuedHashMap`. However, some of its methods contain
extra logic for when the type under test has some characteristics like being an instance of
    It might be possible to come up with a better design, where there are multiple test classes,
for `MultiValuedMap`'s that use `SetValuedMap`'s; `MultieValuedMap`'s that use `List`'s, and
so it goes.
    Or we could add a class to the parent class, with a flag defining the type under test.
For now, I have used the `makeObject()` method, which returns the collection under test. Then
I validate its instance type. There is also a comment above the code to indicate why we are
using `makeObject()` and not `getMap()`.
    It was a fun ticket. Happy to get feedback on better solutions, or feel free to edit this
pull request if you have right to it, or merge if you are happy and it has gathered some consensus.

You can merge this pull request into a Git repository by running:

    $ git pull COLLECTIONS-661

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #28
commit 6e8951ed0325abe3e07e32aded0b27aacdbc1011
Author: Bruno P. Kinoshita <>
Date:   2017-10-11T07:27:25Z

    COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest


> Intermittent test failures in Windows for HashSetValuedHashMap
> --------------------------------------------------------------
>                 Key: COLLECTIONS-661
>                 URL:
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Map
>    Affects Versions: 4.1
>            Reporter: Bruno P. Kinoshita
>            Assignee: Bruno P. Kinoshita
>             Fix For: 4.2
> The collection HashSetValuedHashMap was added in 4.1. On Windows, test failures are not
so common on JVM 8. But on Linux they are harder to happen (but still do [1], [2]).
> When using Windows and JVM 8, running tests on Eclipse, or Maven fail. But debugging
on Windows with Eclipse sometimes work. Indicating it may be due to a concurrency issue, where
debugging adds some extra time hiding the real issue.
> I have a few ideas of where/why it could be happening, but am without a Windows box for
a few days as I'm travelling. I'm reading the codebase in the meantime, but if anybody feels
like working on it, feel free to chime in and suggest a fix/patch.
> [1]
> [2]

This message was sent by Atlassian JIRA

View raw message