Hook life-time events

[iwpnd]

Is your feature request related to a problem? Please describe.

Hooks that live for a limited time are a feature with Tile38, because we can set e.g. EX 3600. I have a hook that expires in 10 minutes. A truck enters the hook and we get an enter event. The trucks stays in the hook and we get consecutive inside events. The truck stays in the hook, the hook gets deleted due to the TTL, and there are no events anymore. From a consumer point of view the state is incomplete, there's no exit ever.

Describe the solution you'd like

I understand that sending an event for every possible truck in a hook is not feasible because of the possible sheer amount.

But I think lifetime events for hooks could solve that issue and notify the consumer that a) there's a new hook you can expect events from now on b) the hook was deleted, don't expect any new events from now on, therefore implicitly sending an exit to attached consumers

In case of b) the consumer can easily continue to update its state itself, because every truck that was in said hook implicitly exits it - that completes the circle of enter/inside/exit.

Describe alternatives you've considered The alternative I considered is tracking the lifetime of a hook in the consumer.

1. consumer gets enter event that has ttl, consumer from then on checks ttl continuously (for inside events) and/or stores/updates lifetime in his own state. Once ttl ran out consumer does whatever he needs to do in order to restore a proper state.

To be frank, this is my only solution right now. Depending on the consumer and his logic this can be easy or can be difficult. It is doable, but I feel that the producer abdicates (wow new word for me) from its responsibility if it sends enter and inside but nothing when it is deleted and therefore leaves a "stale" state with the consumer.

WDYT?

[tidwall]

Makes sense, but I'm not sure about how the implementation would work. The Tile38 hook <-> endpoint connection is passive (stateless may be the proper word), thus an endpoint can be listening without knowledge of state of the geofence.

I guess when a geofence is created or deleted. A notification can be sent to the endpoint with something like:

{"state":"created"}
{"state":"deleted"}

But if the endpoint is not listening then the notification might be lost.

A channel on the other hand can be aware of the state of the geofence because the connection is managed by the server. Allowing for the server to send the state on subscribe.

[iwpnd]

thank you for the response. 🙏🏻

I guess when a geofence is created or deleted. A notification can be sent to the endpoint with something like […]

Yeah something like this would be great.

But if the endpoint is not listening then the notification might be lost.

Almost all of the endpoints are some form of queue or messaging systems. Are there any other reasons an endpoint is not listening other than Tile38 is unable to connect? I remember that for those cases you put the events that cannot be send into an internal queue. How can I understand them getting lost?

[tidwall]

How can I understand them getting lost?

When an endpoint is down the undelivered events get queued, and continually retries to send over a period of time. But eventually Tile38 will give up on old undeliverable events and purge them.

[iwpnd]

So in that regard the behavior would not be different from enter, exit, inside, outside and crosses. If an endpoint is not up to receive that’s out of Tile38s control, at least it tried to inform about its lifetime. Another plus, connection issues are raised on hook creation and fail early and not when the first item enters it.

[tidwall]

I agree with your points and I think that this feature is probably doable.

[tidwall]

This feature has proven to be a little more difficult to implement than I expected.

The main issue is that right now a hook acts both as the geofence and the endpoint communicator.

When a DELHOOK is sent or when a hook has expired due to the EX option (which in turn calls DELHOOK), that geofence is immediately deleted and the endpoint connection is terminated at the same time. Because of that there is no place to send a "deleted" event.

Short of having to redesign the messaging system, perhaps one solution could be to somehow keep the connection opened in the background, at least for long enough to deliver the message. Though I'm not sure what issues that might cause.

[iwpnd]

Thank you very much for spending time on looking into it @tidwall 🙏🏻

I was already afraid it would not be a simple message before h.Close() 😅