ISPN-8865 Move AdvancedCacheLoader over to using Publisher #5794

wburns · 2018-02-23T22:01:48Z

https://issues.jboss.org/browse/ISPN-8865

Added AdvancedCacheLoader.publishEntries method and deprecated/removed all references to calling old process method that I could.

This JIRA is mostly to let CI run on it and crunch out some stuff to see if there are test failures so far.

wburns · 2018-02-23T22:02:20Z

All current loaders have been converted except the SoftIndexFileStore, which I will tackle next week.

rvansa · 2018-02-26T08:06:10Z

core/src/main/java/org/infinispan/filter/KeyFilter.java

 */
 @ThreadSafe
+@Deprecated


Why don't you let this already extend Predicate? That way you could safely change the method parameters to Predicate because all KeyFilters passed in would be Predicates...

Sure, I am not sure why I didn't do this before 👍

rvansa · 2018-02-26T08:08:17Z

core/src/main/java/org/infinispan/persistence/PersistenceUtil.java

-      final AtomicInteger result = new AtomicInteger(0);
-      acl.process(filter, (marshalledEntry, taskContext) -> result.incrementAndGet(), new WithinThreadExecutor(), false, false);
-      return result.get();
+   public static <K, V> int count(AdvancedCacheLoader<K, V> acl, Predicate<? super K> filter) {


This class is public, you need to make the change backwards-compatible.

above will fix that

rvansa · 2018-02-26T08:12:54Z

core/src/main/java/org/infinispan/persistence/PersistenceUtil.java

-      final Set<K> set = new HashSet<K>();
-      acl.process(filter, (marshalledEntry, taskContext) -> set.add(marshalledEntry.getKey()), new WithinThreadExecutor(), false, false);
-      return set;
+      return Flowable.fromPublisher(acl.publishEntries(filter, false, false))


would a separate publishKeys method make sense?

I was actually thinking about that over the weekend. I was debating about having a new method or possibly adding a "builder" API (but this might be overkill).

Something like

AdvancedCacheLoader { ... StorePublisher publish(Predicate<? super K> filter); ... } interface StorePublisher { Publisher<K> keys(); Publisher<MarshalledEntry<K, V>> entries(boolean fetchValues, boolean fetchKeys); }

What do you think?

I wouldn't scope it under such interface, just

Publisher<K> publishKeys(Predicate<? super K> filter); Publisher<MarshalledEntry<K, V>> publishEntries(Predicate<? super K> filter, boolean fetchValue, boolean fetchMetadata);

I have considered dropping the fetchValue completely but there might be use case for key + metadata (e.g. expiration).

Yeah I am fine with the methods as well - and obviously I can make it a nice default method :)

I am thinking that publishKeys will have to be documented saying it is up to the cache store implementation whether or not expired keys are returned.

In regards to fetchValue I can look over the usages again and see if we can possibly drop it. Although to be honest with you, most implementations if you supply either fetchValue or fetchMetadata it is just as easy to get the other. In that case I wonder if it makes any sense to have these arguments anymore.

I guess scattered cache requires just the metadata :) So I guess I will keep both arguments for now.

Actually looking at this more publishKeys has to guarantee that it returns non expired keys. Or else the usefulness of the method is quite questionable (for example keySet iterator can't use it otherwise). So in that case I will try to limit perf impact as much as possible.

rvansa · 2018-02-26T08:38:39Z

core/src/main/java/org/infinispan/util/Closeables.java

+
+/**
+ * @author wburns
+ * @since 9.0


Bah, another Closeables class... btw. the since tag does not match.

Yeah unfortunately reactive streams isn't in commons yet :(

My eclipse isn't updated - thanks 👍

Would it hurt to rather add the dependency there? We want to eventually keep up parity with remote clients anyway...

Afaik it shouldn't hurt. I agree, I was trying to delay the introduction of it until we absolutely needed it in the client.

wburns · 2018-02-26T22:07:46Z

I have added in SoftIndexFileStore support. This also fixes https://issues.jboss.org/browse/ISPN-8880

I have also updated all the various stores to have the new publishKeys method. Those that don't implement this gain no real benefit so they just fall back to default.

Also I made sure to go through and make sure that all stores don't return expired entries/keys. There were a couple bugs around this as reactive streams spec doesn't allow for null values and thus a couple map methods had to be redone.

wburns · 2018-02-26T22:12:29Z

Also I am fine with reactive streams int commons, but I think we need to discuss further before moving rxjava2. In this case I can't remove the Closeables class yet.

I still need to refactor the RestStore so it does async which will allow for better performance. I am thinking of capping the number of concurrent async gets. This may be configurable or just a sensible # like number of CPUs. https://github.com/infinispan/infinispan/pull/5794/files#diff-bb46c82f9776070f5d1036eb22a12387R396
So the other only change at this time I can think of is possibly adding a parallel observation of JpaStore elements when fetchValues or fetchMetadata is true since this will cause a lot of blocking for the requesting thread. https://github.com/infinispan/infinispan/pull/5794/files#diff-8ec36f45d11a29c923951eb51f28ab24R614

wburns · 2018-03-01T22:17:41Z

Updated and cleaned up. Should be ready for 9.3 after we branch now.

wburns · 2018-03-01T22:19:38Z

I am still not keen on using the persistence executor for the JPAStore or LuceneCacheLoader as this only has 4 threads by default. I could possibly use the Schedulers.io but this would be a different thread pool.

wburns · 2018-03-07T15:02:33Z

There are test failures: https://ci.infinispan.org/job/Infinispan/job/PR-5794/6/#showFailuresLink
Also I need to add reactive streams to the parent dependencies for cache stores it seems, have to look closer.

wburns · 2018-03-09T19:27:58Z

I have rebased on top of #5824 now as well. I still have to clean up test failures.

wburns · 2018-03-09T23:50:05Z

Added modules, however I think there is at least 1 or more failure I still need to fix for Monday.

wburns · 2018-03-13T17:38:08Z

Closing this until #5824 is integrated.

danberindei · 2018-03-14T08:20:28Z

Please reopen Will, I didn't realize most changes were in #5824, so I have lots of pending comments here :)

wburns · 2018-03-14T12:50:59Z

Reopening, this is missing a few updates, but I can do that after opened.

danberindei

Hope this works

danberindei · 2018-03-12T13:11:51Z

core/src/main/java/org/infinispan/cache/impl/EncoderCache.java

+      Collection<K> buildKeyCollection(Collection<?> c) {
+         Collection<K> toRemove = new ArrayList<>(c.size());
+         for (Object obj : c) {
+            K entry = keyToStorage(obj);


I would prefer wrapping the collection of keys, in case it's a "virtual" collection like RangeSet. And shouldn't we implement removeIf as well?

So I was debating about both these points a bit.

I think I need to go back and just implement all the methods and let the underlying sets do their jobs. I should make a JIRA to do this though since it isn't directly related to the future changes here.

I created https://issues.jboss.org/browse/ISPN-8946

danberindei · 2018-03-12T13:23:50Z

core/src/main/java/org/infinispan/interceptors/impl/CacheLoaderInterceptor.java

      @Override
      public CloseableIterator<CacheEntry<K, V>> iterator() {
-         CloseableIterator<CacheEntry<K, V>> iterator = Closeables.iterator(entrySet.stream());
+         // This can be a HashSet since it is only written to from the local iterator which is only invoked
+         // from user thread
         Set<K> seenKeys = new HashSet<>(cache.getAdvancedCache().getDataContainer().sizeIncludingExpired());


I didn't notice this before, but it's quite a big set... I wonder if we could use the live dataContainer.keySet() + listeners to keep track of added/removed keys instead.

Also, an interceptor should inject the needed components directly instead of going through getAdvancedCache().

I don't know if the listener will work very well. I will have to listen to all modifications to the cache as well all activations and passivations. My thought for fixing this was to have it store all if it is OBJECT storage and only a subset if it is OFF-HEAP or BINARY.

True about the injection, I can do that.

Also a side note but after I add in segmented store and data container, this code will only be used for non dist stores. And it is possible with other cache modes to do iteration over each segment individually so that you only have so many resurrected objects.

But I will think more on doing a live view, it gets a bit messy with the listeners.

https://github.com/wburns/infinispan/blob/ISPN-8905_non_shared_store_segments/core/src/main/java/org/infinispan/stream/impl/local/PersistencKeyStreamSupplier.java#L78

danberindei · 2018-03-12T13:32:50Z

core/src/main/java/org/infinispan/persistence/PersistenceUtil.java

+    * @param <K>
+    * @param <V>
+    * @return
+    * @deprecated Please use {@link #toKeySet(AdvancedCacheLoader, Predicate)} instead


I believe the reference should be to toEntrySet(ACL, Predicate, IFE). And I'm wondering if these should really be public API, I can't imagine using them outside our tests.

danberindei · 2018-03-12T15:02:09Z

core/src/main/java/org/infinispan/persistence/async/AdvancedAsyncCacheLoader.java

+   public Publisher<MarshalledEntry<K, V>> publishEntries(Predicate<? super K> filter, boolean fetchValue, boolean fetchMetadata) {
+      State state = this.state.get();
+      ByRef<Boolean> hadClear = new ByRef<>(Boolean.FALSE);
+      Map<Object, Modification> modificationMap = state.flattenModifications(hadClear);


Couldn't we use flatMap below instead and avoid copying the map?

Unfortunately we need to make a copy, otherwise the state can be updated after iterating through it and causing us to exclude an entry from the store that we shouldn't have.

Ok, the modification queue size shouldn't be very big anyway.

Yep my thoughts as well.

danberindei · 2018-03-12T16:04:42Z

core/src/main/java/org/infinispan/persistence/file/SingleFileStore.java

+         synchronized (entries) {
+            for (Map.Entry<K, FileEntry> e : entries.entrySet()) {
+               K key = e.getKey();
+               if ((filter == null || filter.test(key)) && !e.getValue().isExpired(now)) {


I'd put the isExpired(now) check first, even if it doesn't filter out a lot of entries it's very cheap.

danberindei · 2018-03-13T17:18:01Z

core/src/test/java/org/infinispan/persistence/ParallelIterationTest.java

+      int batchsize = 10;
+      // Request over the max amount so we can ensure the subscriber will get notified of completion
+      for (int i = 0; i < NUM_ENTRIES / batchsize - 1; i++) {
+         // Now request all the entries on different threads - just to see if the publisher can handle it


Does this really request all the entries? Does it still work if the number of keys is not a multiple of the batch size?

See other comment it is a bit outdated and purposely isn't requesting all entries.

danberindei · 2018-03-13T17:18:21Z

core/src/test/java/org/infinispan/persistence/ParallelIterationTest.java

+         executor.execute(() -> subscriber.request(batchsize));
+      }
+
+      subscriber.awaitCount(NUM_ENTRIES - 10, () -> {


Is 10 the batch size here, or something else?

yes, it is the batch size. I can update to have the variable.

danberindei · 2018-03-13T17:21:38Z

core/src/test/java/org/infinispan/persistence/ParallelIterationTest.java

+      }, TimeUnit.SECONDS.toMillis(10));
+
+      // Now request on the main thread - which should guarantee requests from different threads
+      subscriber.request(11);


Why does a request from the main thread would guarantee requests from different threads? Is it because request size > batch size?

So I think I just need to cleanup the comments here.

First the size of 11 is here just as a further test (there should only be 10 entries, but I am making sure I only get back 10 despite requesting 11).

And actually the key part is that it is guaranteeing that objects are returned via onNext on different threads. The request is already guaranteed to be on different threads from above, but for performance reasons some publishers might only call onNext on one of those threads (ones that add entries to a queue for example (and it is faster to have one thread drain all elements from the queue before finishing).

For example our ClusterStreamManagerImpl publisher only allows for 1 remote request per node to guarantee and adds additional requests (so future requests can request all of those) until any pending request is complete.

danberindei · 2018-03-13T17:30:01Z

lucene/lucene-directory/src/main/java/org/infinispan/lucene/cacheloader/LuceneCacheLoader.java

+               return Flowable.fromIterable(allInternalEntries);
+            })
+            .filter(me -> filter == null || filter.test(me.getKey()))
+            .sequential();


Couldn't we allow the callers to decide for themselves whether to get a parallel flowable or a sequential one?

The user can still do whatever they want to the resulting publisher here. The problem is with reactive streams is you can't call onNext from different threads concurrently. This code here is ensuring that onNext observes this contract - note it will most likely be called from different threads, just not at the same time.

The user can still observe these entries on any number of threads that they want. Note a publisher is not "used" until someone subscribes to it.

My main problem here was that I was assuming the result of parallel() implements Publisher, and I couldn't imagine why one kind of Publisher would be a better return value than the other.

danberindei · 2018-03-13T17:31:07Z

...nce/jdbc/src/main/java/org/infinispan/persistence/jdbc/stringbased/JdbcStringBasedStore.java

- * <p/>
- * <b>Preload</b>.In order to support preload functionality the store needs to read the string keys from the database and transform them
- * into the corresponding key objects. {@link org.infinispan.persistence.keymappers.Key2StringMapper} only supports
+ * <b>Preload & Iteration</b>.In order to support preload or iteration functionality the store needs to read the string


Github highlights the &, should probably be &

wburns · 2018-05-08T12:40:15Z

There appear to be some related test failures https://ci.infinispan.org/job/Infinispan/job/PR-5794/18/

wburns · 2018-05-08T15:10:39Z

Tests should be fixed now, waiting on latest run.

process * Introduce publishEntries and publishKeys methods * Limit scope of changes to minimum * Add persistence executor to Context for stores/loaders

process * Convert SingleFileStore

process * Convert DummyInMemoryStore

process * Convert AdvancedAsyncCacheLoader * Optimize code to not retrieve keys first

process * Convert JdbcStringBasedStore

process * Convert JpaStore

danberindei

More nitpicking on javadoc comments ;)

danberindei · 2018-05-10T12:54:54Z

core/src/main/java/org/infinispan/filter/KeyFilter.java

@@ -10,9 +12,11 @@
 *
 * @author Manik Surtani
 * @since 6.0
+ * @deprecated This will be replaced by {@link java.util.function.Predicate} in the future


I like having since x.y in the deprecated comment so it's more obvious when it's safe to remove it.

Sure, forgot to put one here.

danberindei · 2018-05-10T13:07:55Z

core/src/main/java/org/infinispan/interceptors/impl/CacheLoaderInterceptor.java

-         }
-         return empty;
-      }
+      // TODO: this can't be added in until stores size method is guaranteed to not count expired entries


IMO counting entries while excluding expired ones is a potentially expensive operation compared to starting publishKeys() and stopping after the first one.

Sure sounds good. I had thought about doing that with iterator, but didn't think of publishKeys. I think it has just been too long since i looked at this.

danberindei · 2018-05-10T13:37:45Z

core/src/main/java/org/infinispan/persistence/async/AdvancedAsyncCacheLoader.java

+   public Publisher<MarshalledEntry<K, V>> publishEntries(Predicate<? super K> filter, boolean fetchValue, boolean fetchMetadata) {
+      State state = this.state.get();
+      ByRef<Boolean> hadClear = new ByRef<>(Boolean.FALSE);
+      Map<Object, Modification> modificationMap = state.flattenModifications(hadClear);


Ok, the modification queue size shouldn't be very big anyway.

danberindei · 2018-05-10T13:55:43Z

core/src/main/java/org/infinispan/persistence/manager/PersistenceManager.java

+   /**
+    * Returns a publisher that will publish all entries stored by the underlying cache store. Only the first
+    * cache store that implements {@link AdvancedCacheLoader} will be used. Predicate is applied by the underlying
+    * loader in a best attempt to improve performance.


I always assumed that each loader has some extra entries compared to the previous one, otherwise it wouldn't make any sense to have both loaders. E.g. maybe the first loader reads from a local SingleFileStore, and the next loader invokes a couple REST API to re-compute the value. Of course, the 2nd loader probably wouldn't implement AdvancedCacheLoader in this scenario, but if it did I wouldn't consider it a bug to publish all the entries from both loaders.

danberindei · 2018-05-10T14:02:13Z

core/src/main/java/org/infinispan/persistence/manager/PersistenceManager.java

+    * loader in a best attempt to improve performance.
+    * <p>
+    * Caller can tell the store to also fetch the value or metadata. In some cases this can improve performance. If
+    * metadata is not fetched it is not guaranteed if the publisher will return expired entries or not.


I think you could simplify this to "If metadata is not fetched the publisher may include expired entries".

danberindei · 2018-05-10T14:20:47Z

core/src/main/java/org/infinispan/scattered/impl/ScatteredVersionManagerImpl.java

-                  }
-               }
+      Publisher<MarshalledEntry<Object, Object>> publisher = persistenceManager.publishEntries(false, true);
+      Flowable.fromPublisher(publisher).map(MarshalledEntry::getMetadata).blockingForEach(metadata -> {


Is there any benefit in extracting the getMetadata() call into a separate step?

You mean just doing it inside the blockingForEach lambda? No it should be the same.

One less lambda though ;)

Yeah I already changed it.

danberindei · 2018-05-10T14:32:53Z

core/src/main/java/org/infinispan/util/Closeables.java

+      return new CloseableIterator<E>() {
+         @Override
+         public void close() {
+            ((Disposable) iterator).dispose();


So we don't need to dispose the iterable or the publisher, only the iterator?

Only the iterator. The publisher and iterable don't really apply as they don't do anything, until the iterator is invoked. It has all the resources.

danberindei · 2018-05-10T14:38:05Z

core/src/test/java/org/infinispan/persistence/ParallelIterationTest.java

-      }, executor, true, true);
+      Flowable.fromPublisher(loader.publishEntries(null, true, true))
+            .observeOn(Schedulers.from(executor))
+            .takeUntil((MarshalledEntry<Object, Object> me) -> stopped.get())


Maybe the entries.size() checks can be stricter now

Hrmm tbh I am not exactly sure. I think it has to invoke doOnNext before it can call takeUntil again. Let me change it and we can find out :)

Yeah so it will always only modify on a single thread at a time. I can change it to assert it equals the size exactly then. This should be better, because I could make it so we are doing this across multiple threads with Flowable.parallel or Flowable.flatMap, but then we are testing rxjava2, which isn't the point of this test.

Although tbh you wouldn't want to do cancellation like this in the first place, you should just invoke Flowable.take(100) instead.

The more I thought about it, this method should just be removed 🗡

danberindei · 2018-05-10T14:56:44Z

lucene/lucene-directory/src/main/java/org/infinispan/lucene/cacheloader/LuceneCacheLoader.java

+               return Flowable.fromIterable(allInternalEntries);
+            })
+            .filter(me -> filter == null || filter.test(me.getKey()))
+            .sequential();


My main problem here was that I was assuming the result of parallel() implements Publisher, and I couldn't imagine why one kind of Publisher would be a better return value than the other.

danberindei · 2018-05-10T15:00:56Z

persistence/jpa/src/main/java/org/infinispan/persistence/jpa/JpaStore.java

 /**
- *
+ * NOTE: This store can return expired entries on any given operation if {@link JpaStoreConfiguration#storeMetadata()}
+ * was not set to true.


Does that include publishKeys? It doesn't really return entries, but I don't see any additional checks.

Yes, want me to say keys or entries instead? The problem is there is no place to store expiration metadata if there is not table for it.

Actually I'd like you to change the javadoc of publishKeys in AdvancedCacheLoader and PersistenceManager, because they say "This publisher will never return a key which belongs to an expired entry"

Also I changed it to 'was set to false' - easier to read imo.

Hrmm well that is the contract, which I would like to keep on AdvancedCacheLoader. JpaStore is special in that it violates this contract, which is why I would rather put it here. I don't want an implementation to return expired keys.

For this reason DummyStore doesn't implement publishKeys, because the metadata is stored with entry so we have to read that as well.

I don't think a javadoc here is enough, because there's nothing anyone can do about JpaStore breaking the contract:

We won't add a special case for JpaStore in core, we're going to call publishKeys based on the AdvancedCacheLoader javadoc.

Users call methods on the cache, they don't necessarily know which cache method calls which store method internally.

IMO we should throw an exception when the user tries to store mortal entries in a JpaStore if we can't read the metadata back. It's a bit complicated by the async writer catching all the exceptions, but at least they'll see some errors in the log. And ideally I'd like to make expiration support optional, both at the store level and at the cache level, so we can throw that exception right from CacheImpl.

Hrmm I think it might be easier to log another JIRA for this.

It would cover

I would like to throw an exception at start up if JPAStore is configured not being able to store metadata. Unfortunately we can't do this, since they could be using the store as a read only.

We probably can only throw exceptions at runtime if an entry is written to the JPAStore with expiration.

Either way neither of these are great options, thus why I would recommend a separate JIRA to talk about this.

I created https://issues.jboss.org/browse/ISPN-9143 to continue this.

danberindei · 2018-05-10T15:13:36Z

persistence/rest/src/main/java/org/infinispan/persistence/rest/RestStore.java

 import net.jcip.annotations.ThreadSafe;

 /**
 * RestStore.
 *
 * @author Tristan Tarrant
 * @since 6.0
+ * @deprecated This cache store will be changed to only implement {@link org.infinispan.persistence.spi.CacheLoader}


Aren't we using it for rolling upgrades?

Nope, Hot Rod only

process * Removed process from PersistenceManager * Remove core usages of process

process * Convert RemoteStore

process * Convert RocksDBStore

process ISPN-8892 RestStore should only implement CacheLoader * Convert RestStore * Deprecate AdvancedCacheLoader portion of RestStore * Deprecate RestTargetMigrator

process * Convert SoftIndexFileStore

process * Convert LuceneCacheLoader

process * Convert remaining server test loaders

process * Added module information for various stores

process * Added some documentation noting new SPI

danberindei · 2018-05-11T13:29:13Z

Integrated, thanks Will!

wburns added Preview On Hold labels Feb 23, 2018

wburns added this to the 9.3.0.Alpha1 milestone Feb 23, 2018

wburns force-pushed the ISPN-8865_publisher_loader branch from 5e18ec5 to 55b433c Compare February 24, 2018 00:02

rvansa reviewed Feb 26, 2018

View reviewed changes

wburns force-pushed the ISPN-8865_publisher_loader branch from 4caafc9 to dba2c13 Compare February 26, 2018 22:05

wburns mentioned this pull request Feb 28, 2018

ISPN-8854 NullPointerException in SingleFileStore #5775

Merged

wburns force-pushed the ISPN-8865_publisher_loader branch from 81e4386 to fe72508 Compare March 1, 2018 22:17

wburns removed On Hold Preview labels Mar 1, 2018

wburns changed the title ~~Ispn 8865 publisher loader~~ Ispn 8865 Move AdvancedCacheLoader over to using Publisher Mar 1, 2018

wburns force-pushed the ISPN-8865_publisher_loader branch from fe72508 to f6a2466 Compare March 6, 2018 16:12

wburns added the Changes Required label Mar 7, 2018

wburns mentioned this pull request Mar 8, 2018

ISPN-8921 KeyStream stream operations use entrySet on remote nodes #5824

Merged

wburns force-pushed the ISPN-8865_publisher_loader branch from f6a2466 to aee7235 Compare March 9, 2018 19:27

wburns force-pushed the ISPN-8865_publisher_loader branch from aee7235 to 464b2c2 Compare March 9, 2018 22:12

wburns closed this Mar 13, 2018

wburns reopened this Mar 14, 2018

danberindei reviewed Mar 14, 2018

View reviewed changes

wburns removed the Preview label May 8, 2018

wburns force-pushed the ISPN-8865_publisher_loader branch 2 times, most recently from 8fceaf2 to 626926c Compare May 8, 2018 14:17

wburns removed the Changes Required label May 8, 2018

wburns added this to the 9.3.0.Beta1 milestone May 10, 2018

wburns added 6 commits May 10, 2018 09:47

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

ea21211

process * Introduce publishEntries and publishKeys methods * Limit scope of changes to minimum * Add persistence executor to Context for stores/loaders

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

9eb3f4e

process * Convert SingleFileStore

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

5e5c8bb

process * Convert DummyInMemoryStore

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

4381463

process * Convert AdvancedAsyncCacheLoader * Optimize code to not retrieve keys first

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

8c986ff

process * Convert JdbcStringBasedStore

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

65665ec

process * Convert JpaStore

wburns force-pushed the ISPN-8865_publisher_loader branch from 626926c to 0702419 Compare May 10, 2018 13:47

danberindei reviewed May 10, 2018

View reviewed changes

wburns force-pushed the ISPN-8865_publisher_loader branch from e89d897 to c1510ea Compare May 10, 2018 17:00

tristantarrant changed the title ~~Ispn 8865 Move AdvancedCacheLoader over to using Publisher~~ ISPN-8865 Move AdvancedCacheLoader over to using Publisher May 11, 2018

wburns added 9 commits May 11, 2018 09:23

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

00495d4

process * Removed process from PersistenceManager * Remove core usages of process

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

9b5c055

process * Convert RemoteStore

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

5cde98f

process * Convert RocksDBStore

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

70cada0

process ISPN-8892 RestStore should only implement CacheLoader * Convert RestStore * Deprecate AdvancedCacheLoader portion of RestStore * Deprecate RestTargetMigrator

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

2c085ca

process * Convert SoftIndexFileStore

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

eb9cf3a

process * Convert LuceneCacheLoader

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

9f740a2

process * Convert remaining server test loaders

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

0270fbf

process * Added module information for various stores

ISPN-8865 Move AdvancedCacheLoader over to using Publisher instead of

3301101

process * Added some documentation noting new SPI

wburns force-pushed the ISPN-8865_publisher_loader branch from c1510ea to 3301101 Compare May 11, 2018 13:23

danberindei merged commit df9ffb5 into infinispan:master May 11, 2018

ISPN-8865 Move AdvancedCacheLoader over to using Publisher #5794

ISPN-8865 Move AdvancedCacheLoader over to using Publisher #5794

Conversation

wburns commented Feb 23, 2018

wburns commented Feb 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns Feb 26, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns Feb 26, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns commented Feb 26, 2018

wburns commented Feb 26, 2018 • edited Loading

wburns commented Mar 1, 2018

wburns commented Mar 1, 2018

wburns commented Mar 7, 2018

wburns commented Mar 9, 2018

wburns commented Mar 9, 2018

wburns commented Mar 13, 2018

danberindei commented Mar 14, 2018

wburns commented Mar 14, 2018

danberindei left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns commented May 8, 2018

wburns commented May 8, 2018

danberindei left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns May 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns Feb 26, 2018 •

edited

Loading

wburns Feb 26, 2018 •

edited

Loading

wburns commented Feb 26, 2018 •

edited

Loading

wburns May 10, 2018 •

edited

Loading