[ https://issues.jboss.org/browse/ISPN-2308?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2308: -------------------------------- Description: There is a pull request[1] pending for quite some time(3 months) for this. As there's no activity I'm creating a JIRA and closing the pull request for now. [1] https://github.com/infinispan/infinispan/pull/1097 ----------------- In testing with a cache that was configured to use asynchronous replication, I was seeing some exceptions in my logs about timeout waiting for a lock on a key when doing a put. (It was not frequent - under heavy load testing it was only on a very small percentage of calls to my service) Since I was using the @Cacheable annotation to do the caching around those method calls - there was no way for me to catch the CacheExceptions that were thrown. This means that these exceptions were resulting in my services returning 500 errors to the client. Poking around, it seems that using the putAsync method would make the put methods return immediately and any exception would not be in the same thread so it wouldn't matter. For my use, a put that fails is fine - spring will just put it in the next time if there is no value in the cache. This pull request creates a configuration parameter on the EmbeddedCacheManagerFactory and EmbeddedRemoteCacheManagerFactory for "useAsynchronousCacheOperations" which, when set to true, will use a SpringAsynchrnousCache to wrap the native cache instead of the default SpringCache. I added unit tests around this and updated other tests. In my own load testing environment, I'm no longer seeing the errors related to cache put key lock timeouts and the execution time for my methods has improved in cases when it would have otherwise been blocking waiting for a put. (this is a new pull request against the 5.1.x branch - although the changes also apply cleanly to the 5.2 branch as that's where I first created them) was: There is a pull request[1] pending for quite some time(3 months) for this. As there's no activity I'm creating a JIRA and closing the pull request for now. [1] https://github.com/infinispan/infinispan/pull/1097 In testing with a cache that was configured to use asynchronous replication, I was seeing some exceptions in my logs about timeout waiting for a lock on a key when doing a put. (It was not frequent - under heavy load testing it was only on a very small percentage of calls to my service) Since I was using the @Cacheable annotation to do the caching around those method calls - there was no way for me to catch the CacheExceptions that were thrown. This means that these exceptions were resulting in my services returning 500 errors to the client. Poking around, it seems that using the putAsync method would make the put methods return immediately and any exception would not be in the same thread so it wouldn't matter. For my use, a put that fails is fine - spring will just put it in the next time if there is no value in the cache. This pull request creates a configuration parameter on the EmbeddedCacheManagerFactory and EmbeddedRemoteCacheManagerFactory for "useAsynchronousCacheOperations" which, when set to true, will use a SpringAsynchrnousCache to wrap the native cache instead of the default SpringCache. I added unit tests around this and updated other tests. In my own load testing environment, I'm no longer seeing the errors related to cache put key lock timeouts and the execution time for my methods has improved in cases when it would have otherwise been blocking waiting for a put. (this is a new pull request against the 5.1.x branch - although the changes also apply cleanly to the 5.2 branch as that's where I first created them) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2308?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2308: -------------------------------- Fix Version/s: 5.2.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira