Replace live query `EventBus` implementation with direct cursor
See original GitHub issueShould:
+
simplify things significantly
+
better report errors with server
+
shut down better
-
take up more resources on server (cursor-per-live-query)
…
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
nakadi/nakadi-event-bus-api.yaml at master - GitHub
A distributed event bus that implements a RESTful API abstraction on top of Kafka-like queues - nakadi/nakadi-event-bus-api.yaml at master · zalando/nakadi.
Read more >Amazon EventBridge FAQs | Event Bus | Amazon Web Services
Get answers to Amazon EventBridge FAQs on topics like schema registry, SaaS integrations, limits & performance, architectural best practices and more.
Read more >Apex Developer Guide - Salesforce Implementation guides
Apex is designed to thread together multiple query and DML statements into a single unit of work on the Salesforce server. Developers.
Read more >Zalando RESTful API and Event Guidelines
cursor : an opaque pointer to a page, never to be inspected or constructed by clients. It usually (encrypted) encodes the page position,...
Read more >Winter '23 Release Notes - Salesforce Help
The Winter '23 release helps you grow your business, reduce costs, and create efficiencies. How to Use the Release NotesOur release notes offer...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Released with
v2.1.0
Right, sometimes it fails ones for a persistence entity and stops receiving any new updates for the same persistence entity even after the actor restart. Restart helps to catch up on previous updates because it is probably reading events from the journal first when
eventsByPersistenceId
stream starts, right? I’m not sure if it breaks for all entities for the same plugin id or only for a single entity.We only saw this in prod so far, where we have some amount of concurrent updates. Not sure how to reproduce this consistently. Perhaps writing some automated test can help, I can try writing one when I have time.