Topic
  • 6 replies
  • Latest Post - ‏2010-06-17T14:28:22Z by ricky1
land-land
land-land
12 Posts

Pinned topic I suspect SearchResult object is not thread safe.

‏2010-06-16T21:18:48Z |
An Observation.

I suspect the SearchResult object is not thread safe. I retrieved a searchResult object and put it in a singleton accessed by multiple threads, each picking of a restricted list of results (via setMaxResults()). One by one the threads died with RAMRuntimeExceptions : 'org.apache.lucene.store.AlreadyClosedException: this IndexReader is closed'. The results unfortunately need to be all retrieved in one thread and the threads fed from a List.

Should i have guessed this was the case? - I'm not sure.
Updated on 2010-06-17T14:28:22Z at 2010-06-17T14:28:22Z by ricky1
  • ricky1
    ricky1
    84 Posts

    Re: I suspect SearchResult object is not thread safe.

    ‏2010-06-16T21:56:30Z  
    SearchResult is not API. Unless something is listed as API and is marked thread safe you can make no assumption of thread safety. It is only thread safe if marked API and the Javadoc says it is thread safe.

    Rich
  • land-land
    land-land
    12 Posts

    Re: I suspect SearchResult object is not thread safe.

    ‏2010-06-16T22:08:28Z  
    • ricky1
    • ‏2010-06-16T21:56:30Z
    SearchResult is not API. Unless something is listed as API and is marked thread safe you can make no assumption of thread safety. It is only thread safe if marked API and the Javadoc says it is thread safe.

    Rich
    I sorry I dont understand 'SearchResult' is not API. It's in the RAM API (7.1.1) javadoc listings or am I being stupid - if so bare with me.
  • ricky1
    ricky1
    84 Posts

    Re: I suspect SearchResult object is not thread safe.

    ‏2010-06-16T22:46:42Z  
    • land-land
    • ‏2010-06-16T22:08:28Z
    I sorry I dont understand 'SearchResult' is not API. It's in the RAM API (7.1.1) javadoc listings or am I being stupid - if so bare with me.
    My bad!

    When I saw SearchResult and a lucene query error I thought you were running directly. I didn't notice it was the SearchResult that comes back from RAMSession. That is supported.
  • ricky1
    ricky1
    84 Posts

    Re: I suspect SearchResult object is not thread safe.

    ‏2010-06-16T22:48:43Z  
    • ricky1
    • ‏2010-06-16T22:46:42Z
    My bad!

    When I saw SearchResult and a lucene query error I thought you were running directly. I didn't notice it was the SearchResult that comes back from RAMSession. That is supported.
    But, RAMClient API itself is not thread safe. So the search results of RAMClient aren't thread safe either.
  • land-land
    land-land
    12 Posts

    Re: I suspect SearchResult object is not thread safe.

    ‏2010-06-17T03:28:26Z  
    • ricky1
    • ‏2010-06-16T22:48:43Z
    But, RAMClient API itself is not thread safe. So the search results of RAMClient aren't thread safe either.
    Thanks for fast turn-round. I suppose that means AssetIdentification might also be at risk, if so I would have to stick to GUID & version strings being shared across threads.

    Thanks Land
  • ricky1
    ricky1
    84 Posts

    Re: I suspect SearchResult object is not thread safe.

    ‏2010-06-17T14:28:22Z  
    • land-land
    • ‏2010-06-17T03:28:26Z
    Thanks for fast turn-round. I suppose that means AssetIdentification might also be at risk, if so I would have to stick to GUID & version strings being shared across threads.

    Thanks Land
    Ah, technically according to my statements that is correct. But ( ;-) ) in the case of AssetIdentification that never changes once it is created, if you used RAMAsset.getIdentification() to get it. If an asset's version is changed a new instance of AssetIdentification would be created instead. There may be setters but they are only used to populate the initial values. Setting a version in the identification by a user would be ignored. There is a different explicit way to change the version.

    RAMAsset itself is not thread-safe.

    The basic difference is that the big complicated objects like RAMAsset and SearchResults are only partly populated, or they allow updates to them. As you ask for information it may go back to the server for more. Or it may be changed by a user. In those cases that means things happen that can interfere with other accesses.

    AssetIdentification is a simple POJO that is fully populated on creation and normally wouldn't change. So it is thread safe since it is basically read-only.

    But the API wasn't created with thread safety in mind and so there have been no tests to verify what is thread safe and what isn't.

    Rich