[JBoss JIRA] (ISPN-2308) Allow SpringCache to be configured to use asynchronous operations
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-2308?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-2308:
---------------------------------------
Assignee: (was: Gustavo Fernandes)
> Allow SpringCache to be configured to use asynchronous operations
> -----------------------------------------------------------------
>
> Key: ISPN-2308
> URL: https://issues.jboss.org/browse/ISPN-2308
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Reporter: Mircea Markus
>
> 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 was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (ISPN-8505) The package "org.apache" is too broad to mark it as internally marshallable
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8505?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-8505:
-------------------------------------
Assignee: Galder Zamarreño
> The package "org.apache" is too broad to mark it as internally marshallable
> ---------------------------------------------------------------------------
>
> Key: ISPN-8505
> URL: https://issues.jboss.org/browse/ISPN-8505
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Marshalling
> Affects Versions: 9.1.1.Final
> Reporter: Dmitry Katsubo
> Assignee: Galder Zamarreño
> Priority: Minor
>
> Currently the whole package {{org.apache}} is marked as internally marshallable which is too broad and causes the following assertion:
> {code}
> Exception in thread "AsyncStoreProcessor--p6-t2" java.lang.AssertionError: Check support for: class org.apache.commons.collections4.keyvalue.MultiKey
> at org.infinispan.marshall.core.GlobalMarshaller.writeUnknown(GlobalMarshaller.java:596)
> at org.infinispan.marshall.core.GlobalMarshaller.writeNonNullableObject(GlobalMarshaller.java:412)
> at org.infinispan.marshall.core.GlobalMarshaller.writeNullableObject(GlobalMarshaller.java:355)
> at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:188)
> at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:181)
> at org.infinispan.marshall.core.GlobalMarshaller.objectToBuffer(GlobalMarshaller.java:305)
> at org.infinispan.marshall.core.MarshalledEntryImpl.marshall(MarshalledEntryImpl.java:117)
> at org.infinispan.marshall.core.MarshalledEntryImpl.getKeyBytes(MarshalledEntryImpl.java:89)
> at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:314)
> {code}
> Many classes from Apache commons are perfectly OK for serialization:
> * {{org.apache.commons.lang3.tuple.MutablePair}}
> * {{org.apache.commons.lang3.mutable.MutableInt}}
> * {{org.apache.commons.collections4.multimap.ArrayListValuedHashMap}}
> * ... and so on
> I suggest that [the package check in method {{ExternallyMarshallable#isMarshallablePackage(String pkg)}}|https://github.com/infinispan/infinispan/blob/1f6c1abf046b3dd7d616...] is more exact (narrowed).
> The issue is relative to ISPN-7591 and ISPN-6906.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months