Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: no way to access tuple(s) in zgossip #1459

Closed
mvala opened this issue Jun 8, 2016 · 5 comments
Closed

Problem: no way to access tuple(s) in zgossip #1459

mvala opened this issue Jun 8, 2016 · 5 comments

Comments

@mvala
Copy link
Member

mvala commented Jun 8, 2016

I would like to use zgossip and i can send some configuration tuples to the zgossip cluster, but didn't find command i have to send to get specific tuple or tuples back? In documentation there is

At any point the application can access the node's set of tuples.

Can you give me hint?

@bluca
Copy link
Member

bluca commented Jan 1, 2017

This is not implemented yet, only the count can be dumped. A new API message for the actor could be added that triggers a dump, perhaps.

@bluca bluca changed the title How do i access tuple(s) in zgossip? Problem: no way to access tuple(s) in zgossip Jan 1, 2017
@bluca
Copy link
Member

bluca commented Jan 1, 2017

Of course any received tuple will be delivered to the applicatio:

DELIVER key value -- new tuple delivered from network

So in theory one could build manually a zhash and maintain it, but it would be duplicated so I do see a case for a way to access the database at any moment.

@bluca
Copy link
Member

bluca commented Jan 1, 2017

I have implemented 2 new commands:

    * KEYS -- return number of keys followed by each key in its own frame
    * TUPLE key -- return value associated with requested key

bluca@17528ad

But thinking about it, it feels a bit awkward to use.

Given all tuples are delivered to the application as DELIVER messages upon receipt, it's really trivial to keep and use them if needed, so I'd be more inclined to just fix the documentation unless there's a particular reason to add the new api.

@sphaero
Copy link
Contributor

sphaero commented Jan 2, 2017

I've had this discussion with @hintjens in the past for Zyre:
zeromq/zyre#297

I think we decided back then that the Zyre was already sending the Hello's which implies you should already know what peers are available so no need to request this from the API again.

This might apply here as well?

@bluca
Copy link
Member

bluca commented Jan 2, 2017

Thanks, that insight was helpful. I also agree with that conclusion. I've opened a PR to fix the documentation.

I'll keep the other solution around in my fork if someone comes up with a valid use case for being able to dump the internal state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants