public interface Informable<T>
Modifier and Type | Method and Description |
---|---|
default SharedIndexInformer<T> |
inform()
Similar to a
Watch , but will attempt to handle failures after successfully started. |
default SharedIndexInformer<T> |
inform(ResourceEventHandler<? super T> handler)
Similar to a
Watch , but will attempt to handle failures after successfully started. |
SharedIndexInformer<T> |
inform(ResourceEventHandler<? super T> handler,
long resync)
Similar to a
Watch , but will attempt to handle failures after successfully started. |
CompletableFuture<List<T>> |
informOnCondition(Predicate<List<T>> condition)
|
SharedIndexInformer<T> |
runnableInformer(long resync)
Similar to a
Watch , but will attempt to handle failures after successfully started. |
Informable<T> |
withIndexers(Map<String,Function<T,List<String>>> indexers)
The indexers to add to
SharedInformer s created by subsequent inform calls; |
Informable<T> |
withLimit(Long limit)
Set the limit to the number of resources to list at one time.
|
Informable<T> withIndexers(Map<String,Function<T,List<String>>> indexers)
SharedInformer
s created by subsequent inform calls;indexers
- to customize the indexingInformable
Informable<T> withLimit(Long limit)
If the list fails to complete it will be re-attempted with this limit, rather than falling back to the full list. You should ensure that your handlers are either async or fast acting to prevent long delays in list processing that may cause results to expire before reaching the end of the list.
WARNING As noted in the go client: "paginated lists are always served directly from etcd, which is significantly less efficient and may lead to serious performance and scalability problems."
limit
- of a items in a list fetchInformable
default SharedIndexInformer<T> inform()
Watch
, but will attempt to handle failures after successfully started.
and provides a store of all the current resources.
This returned informer will not support resync.
This call will be blocking for the initial list and watch.
You are expected to call stop to terminate the underlying Watch.
Additional handlers can be added, but processing of the events will be in the websocket thread, so consider non-blocking handler operations for more than one handler.
SharedIndexInformer
default SharedIndexInformer<T> inform(ResourceEventHandler<? super T> handler)
Watch
, but will attempt to handle failures after successfully started.
and provides a store of all the current resources.
This returned informer will not support resync.
This call will be blocking for the initial list and watch.
You are expected to call stop to terminate the underlying Watch.
Additional handlers can be added, but processing of the events will be in the websocket thread, so consider non-blocking handler operations for more than one handler.
handler
- to notifySharedIndexInformer
SharedIndexInformer<T> inform(ResourceEventHandler<? super T> handler, long resync)
Watch
, but will attempt to handle failures after successfully started.
and provides a store of all the current resources.
This call will be blocking for the initial list and watch.
You are expected to call stop to terminate the underlying Watch.
Additional handlers can be added, but processing of the events will be in the websocket thread, so consider non-blocking handler operations for more than one handler.
handler
- to notifyresync
- the resync period or 0 for no resyncSharedIndexInformer
SharedIndexInformer<T> runnableInformer(long resync)
Watch
, but will attempt to handle failures after successfully started.
and provides a store of all the current resources.
You are expected to call stop to terminate the underlying Watch.
Additional handlers can be added, but processing of the events will be in the websocket thread, so consider non-blocking handler operations for more than one handler.
resync
- the resync period or 0 for no resyncSharedIndexInformer
CompletableFuture<List<T>> informOnCondition(Predicate<List<T>> condition)
Future
when the list at this context satisfies the given Predicate
.
The predicate will be tested against the state of the underlying informer store on every event.
The returned future should be cancelled by the caller if not waiting for completion to close the underlying informercondition
- the Predicate
to testCompletableFuture
of the list of items after the condition is metCopyright © 2015–2020 Red Hat. All rights reserved.