26

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: S> In advance I thank. A standard pattern to send messages to itself: 1. Read the message from queue TODO 2. Sent the message in queue IN PROGRESS 3. Sent ACK to queue TODO 4. Started to do 5. Made 6. Read the message from queue IN PROGRESS and sent on it ACK 5. Sent the message to queue DONE If fell, you read  from queue IN PROGRESS and you do them, and then you switch on TODO.

27

Re: To store a state for service + rabbitmq

Hello, Cyberax, you wrote: a C> Hello, Sharov, you wrote: S>> the Question: as well as on what similar storage is better for organizing - mysql, nosql. There is something similar ? The task unpretentious, the decision for certain . Not one decade. It would not be desirable to invent a bicycle. The C> Is some variants. As my preferences: a C> 1) to Throw out on three letters RabbitMQ and simply to make queue of tasks. Working nodes periodically interrogate it, taking away jobs. The taken away jobs thus are marked at once as "in process". The logic with , falling, etc. is elementarily added if needed directly in request "give-me-following-task". Well and simple table MySQL/PostgreSQL will be scaled to hundreds tasks a second. To throw out not a variant, not my moped.> 2) If so it would be desirable to eat a C a cactus we do the message "the task it is received" idempotent and it is combined with a template "the invisible message". I.e. The working node takes the message, without confirming it, and sends on a central node acknowledgement "ja-ja-work". In case of falling (after a while) the message again becomes visible and other node starts it to execute, repeatedly sending "ja-ja-work". I somehow and planned to make, was then clarified that the come message is necessary ack, . Queue removes it. Above like conciliatory proposals with double ack have been found. Cs> In my practice, with a state on messages result difficult protocols only in  so I would begin with 1). At us yet the difficult protocol, and hardly becomes difficult.

28

Re: To store a state for service + rabbitmq

Hello, itslave, you wrote: I> Hello, neFormal, you wrote: F>> if to trust docks the occupied messages after death will be returned in queue. I> the HARDWARE marked that most likely a little ack on one  in its case does not transit. Therefore input queue usage as temporal storage most likely not . Queue as storage, even temporal, not the best idea. At it others f-ii. I> Though that that the sender demands that acknowledgement that its message is accepted - at least atypically. Normally it has enough 200  from queue the Message "to begin operation" and operation performance after all not queue is engaged.

29

Re: To store a state for service + rabbitmq

Hello, Cyberax, you wrote: a C> Hello, itslave, you wrote: Cs>>> 1) periodically it interrogate Working nodes, taking away jobs. I>> HERE tell, whether you know standard decisions for loading equalization on working nodes? A C> In a case with poll-model all is simple - the working node knows the loading and it takes simple not new jobs, yet does not receive enough the free capacity. In the elementary case it is enough to look that the number of the active tasks is no more number CPU. I and did. Other moment that queue in any way does not hinder it. There there is prefetch, i.e. a sampling defined kol-va messages.

30

Re: To store a state for service + rabbitmq

Hello, pestis, you wrote: P> Hello, Sharov, you wrote: S>> In advance I thank. P> a standard pattern to send messages to itself: P> 1. Read the message from queue TODO P> 2. Sent the message in queue IN PROGRESS P> 3. Sent ACK to queue TODO P> 4. Started to do P> 5. Made P> 6. Read the message from queue IN PROGRESS and sent on it ACK P> 5. Sent the message to queue DONE P> If fell, you read  from queue IN PROGRESS and you do them, and then you switch on TODO. The interesting decision. But on conscience to use queue as storage () not so somehow...

31

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: S> Queue as storage, even temporal, not the best idea. At it others f-ii. The guaranteed delivery of the message is widespread enough variant of the contract of queue. It implies temporal storage of messages. S> the message "to begin operation" and after all not queue is engaged in operation performance. And what for about it the nobility to the supplier of messages? I would understand that it the operation termination, but the beginning interests... As operation can be begun some times and is only once finished.

32

Re: To store a state for service + rabbitmq

Hello, itslave, you wrote: I> Hello, Sharov, you wrote: S>> Queue as storage, even temporal, not the best idea. At it others f-ii. I> the Guaranteed delivery of the message is widespread enough variant of the contract of queue. It implies temporal storage of messages. All the same to store the state (in the given special case - the message) to the output agent is better in other place. S>> the message "to begin operation" and after all not queue is engaged in operation performance. I> and what for about it the nobility to the supplier of messages? I would understand that it the operation termination, but the beginning interests... As operation can be begun some times and is only once finished. Speech not about ack "start operation", and that it is necessary to answer "operation started".

33

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: S> All the same to store the state (in the given special case - the message) to the output agent is better in other place. The disputable statement. S> speech not about ack "start operation", and that it is necessary to answer "operation started". And what for?

34

Re: To store a state for service + rabbitmq

Hello, itslave, you wrote: I> Hello, Sharov, you wrote: S>> All the same to store the state (in the given special case - the message) to the output agent is better in other place. I> the disputable statement. SRP? S>> speech not about ack "start operation", and that it is necessary to answer "operation started". I> And what for? That  the side notified the user that handling over its data began

35

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: I>> the disputable statement. S> SRP? It is not broken - the guaranteed delivery of the message implies also storage of the message and  if the message is not processed. S> that  the side notified the user that handling over its data began with the point of view of the user - handling began when the message delivered in queue But is more serious, I would start to dig aside that the sender accepted a little ack -   it will be easier and more reliable.

36

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: S> Speech not about ack "start operation", and that it is necessary to answer "operation started". At saving  in queue for ` operation started ` it is possible to accept an affirmative reply on setting in queue.

37

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: S> In this part of arguing no queue is present - we considered the message from queue, made ack. Now it is a question of storage of messages considering that rabbit can even add on the screw the queue, the separate storage should be justified.

38

Re: To store a state for service + rabbitmq

Hello, neFormal, you wrote: F> Hello, Sharov, you wrote: S>> Speech not about ack "start operation", and that it is necessary to answer "operation started". F> at saving  in queue for ` operation started ` it is possible to accept an affirmative reply on setting in queue. Well as, and if all output agents fell, and all is shown to the user that ? The output agent should answer this message that is valid started.

39

Re: To store a state for service + rabbitmq

Hello, neFormal, you wrote: F> Hello, Sharov, you wrote: S>> In this part of arguing no queue is present - we considered the message from queue, made ack. Now it is a question of storage of messages F> considering that rabbit can even add on the screw the queue, the separate storage should be justified. Messages are stored some time. I.e. it at all persistent storage type .

40

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: S> Well as and if all output agents fell, and all is shown to the user that ? The output agent should answer this message that is valid started. Well and if he started and then failed - the user about it does not learn. Sense to outweigh on the output agent responsibility of queue - to guarantee delivery...

41

Re: To store a state for service + rabbitmq

Hello, Sharov, you wrote: S> Well as and if all output agents fell, and all is shown to the user that ? The output agent should answer this message that is valid started. And if then falls? It turns out that started, but not in_progress.  after transmission of control it any more care of the supplier. In default  it is possible to search in dead letters or to find and at once to put in the DB, if absolutely .