You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the server has two modes of operation. At start, it works the same as the C++ gearmand. When a connection is made to it and the "streaming" option is selected, it changes semantics to those better supporting streaming clients. Currently this means:
Clients receive a FAIL event if the worker disconnects, instead of being silently retried by the server.
Uniqueid jobs have their results queued and sent to newly connected clients, so that the series of DATA/WARNING/COMPLETE events are identical across all workers.
On reflection, I want to change the second one to be:
Uniqueid foreground jobs result in an error.
This would remove substantial complexity, while maintaining the same promises. I don't believe that streaming uniqueid foreground jobs are sufficiently useful to justify the code needed to support them.
The text was updated successfully, but these errors were encountered:
I think this mode could be very beneficial also for scenarios other than streaming, but the naming does not really promote it's use. If I understand this correctly, the feature could also be named "fail fast"-mode? This would probably promote it's use in scenarios where fail fast operation is the wanted behaviour.
I personally think that having a "fail fast" mode more prominently documented would also be a good way to convey users the "default" retry logic of the gearmand server. Currently this information is not very easy to come by in the official gearmand documentation(s).
Do you envision the streaming option having some other needs than those which could be described as "fail fast" operation? And if so, could the streaming mode be an extra mode on top of the "fail fast" mode?
This isn't prominently documented because it hasn't been released yet. Beyond that, it requires that you be using a server that supports the feature, that is, the Abraxas server.
But, you're right, one is "execute no more then once", the other is either "make uniqueid foreground connections all receive the same packets" or "disallow uniqueid foreground connections". I'd be fine with having separate options for these.
Currently, the server has two modes of operation. At start, it works the same as the C++ gearmand. When a connection is made to it and the "streaming" option is selected, it changes semantics to those better supporting streaming clients. Currently this means:
On reflection, I want to change the second one to be:
This would remove substantial complexity, while maintaining the same promises. I don't believe that streaming uniqueid foreground jobs are sufficiently useful to justify the code needed to support them.
The text was updated successfully, but these errors were encountered: