LightblueNotificationRepositoryConfig (event-handler-lightblue 0.1.13 API)

Skip navigation links

All Classes

Summary:
Nested |
Field |
Constr |
Method

Detail:
Field |
Constr |
Method

All Known Implementing Classes:

EventHandlerConfigEntity, MutableLightblueNotificationRepositoryConfig
```
public interface LightblueNotificationRepositoryConfig
```

Method Summary

All Methods Instance Methods Abstract Methods
Modifier and Type	Method and Description
`Set<String>`	`getEntityNamesToProcess()` Governs whether or not notifications are processed based on their associated entity's name.
`java.time.Duration`	`getNotificationExpireThreshold()` How long before a notification is available for retrieval do we drop the notification and let it be reprocessed?
`java.time.Duration`	`getNotificationProcessingTimeout()` How long can a notification remain processing before we allow it to be retrieved again for reprocessing?

- Method Detail
  - getEntityNamesToProcess
```
Set<String> getEntityNamesToProcess()
```
    Governs whether or not notifications are processed based on their associated entity's name.
  - getNotificationProcessingTimeout
```
java.time.Duration getNotificationProcessingTimeout()
```
    How long can a notification remain processing before we allow it to be retrieved again for reprocessing?
  - getNotificationExpireThreshold
```
java.time.Duration getNotificationExpireThreshold()
```
    How long before a notification is available for retrieval do we drop the notification and let it be reprocessed?
    In other words, this governs when we stop processing a notification in flight because we're too near when another retrieval may see it is past its getNotificationProcessingTimeout() and retrieve it for reprocessing.
    N.B. The existence of this configuration is a function of our current transaction scheme. This could go away, for instance, if we either atomically updated a notification's processing timestamp before adding its document events. Other alternative schemes are possible.