This repository has been archived by the owner on Oct 31, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 284
Message Queue #2223
Labels
Comments
Queue should be implemented as separate Possible schema implementation could look like this: CREATE TABLE queue (
node_id text not null primary key,
task_id text,
subtask_id text,
msg_type int,
-- pickled slots tuple
msg_slots blob,
) Alternative approach would be to store API proposal: def put(node_id: receivers uuid, task_id: uuid, subtask_id: uuid, msg_type: int, msg_slots: tuple) -> None:
# ...
def get(node_id: receivers uuid, task_id: uuid, subtask_id: uuid) -> Iterator[golem_messages.message.base.Message]:
"""Returns iterator of messages.
Can be used by an established TaskSession between ourselves and node_id
to know what messages should be sent."""
# ...
def waiting() -> Iterator[tuple(node_id, task_id, subtask_id)]:
"""Returns iterator of (node_id, task_id, subtask_id) that has pending messages.
Can be used by TaskServer to know which nodes it should connect to.
"""
# ... |
This was referenced Mar 14, 2019
Merged
Why separate DB? |
@mplebanski idea of separate db has been dropped. |
Merged
# for free
to subscribe to this conversation on GitHub.
Already have an account?
#.
Implement a Message Queue service that persistently stores messages outside of task sessions.
It would simplify
TASK_CONN_TYPES
. Developer would no longer need to create infamous_add_pending_request
,__connection_established_for_XXX
,__connection_failure_for_XXX
,__connection_final_failure_for_XXX
quartet. He would instead just callmessage_queue.put(node_id, ..., msg description)
It would also solve the persistence issue.
Updated 2018-02-26: more elaborated gains @jiivan
Updated 2018-02-26: no longer needed by Concent -- @jiivan
TaskSession
statelessTaskServer
- replace the connection types with a unified transport layer utilizing the Message QueueThe text was updated successfully, but these errors were encountered: