-
Notifications
You must be signed in to change notification settings - Fork 9
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
How to make multiple COV-subscriptions #22
Comments
I understand. You want a thing that you can create that has the same parameters as Call this thing a There is a new cov-client-shell.py sample that should help get you started. The interesting bits are here where it waits for some incoming change or the |
Thanks a lot, got it running with this! Should anyone else have this use case:
With Python version > 3.10 I get the following error message:
Tried to fix this, e.g. with asyncio.gather, but did not get it to run. I also tried to subscribe more than 255 data points at the same time, but it didn't work. Can a subscription context manager only manage 255 COV subscriptions? If there are more than 255 subscriptions, do I need to create multiple context subscription managers? |
Ok, I have not tested it with anything higher than 3.10.
Were these all from the same device or from different devices? There's nothing in the code itself that would limit it, but I suspect you are running into resource limitations of the devices you are talking to. This API does not use SubscribeCOVPropertyMultiple, I'll have to check around and see if I have any "real world" devices to test against. There is one context manager per subscription, so you are already creating multiple context managers (and multiple "fini" events, etc). The fact that you're failing at 255 does seem suspicious!
At the time that it fails, do you get back an error from the device? |
Ha! The application is running out of invoke identifiers. Each confirmed service gets a unique invoke identifier in the request on the client side which is returned by the server in the confirmation. This is to line up multiple requests and their responses on the client side. Without the request going out on the wire and being confirmed, the invoke identifier is in limbo, and you are stacking up lots of requests. The answer is to put a leaky bucket (a.k.a. token bucket) in the application that allows it to have some number of simultaneous outstanding requests per destination and as they get confirmed "drain" another request from the queue. A queue would work, then the loop that adds requests would block until there's some room. I deliberately did not add this at the application layer, there are a number of different possible implementations and I didn't want to bake one into the code. There is also the tricky part about retry attempts and timers, in theory the client state machine shouldn't start until the request actually leaves. |
Hi, I would need to be able to dynamically add and remove COV subscriptions in my application. How can this be realized? I have the example "cov-client.py" running and also get COV notifications from the server, however I am not clear how to subscribe to multiple objects. Can someone please help me here? Thank you very much.
Great work by the way, love this project!
The text was updated successfully, but these errors were encountered: