-
Notifications
You must be signed in to change notification settings - Fork 46
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
handling grpc._channel._MultiThreadedRendezvous #104
Comments
Seems like the issue is that subscribe_stream is running on its own thread. |
Hey @brunoonovais , The idea of running subscribe_stream in a separate thread was done for a purpose of scalability to ensure that multiple threads can co-exist. We can try to look if there will be any benefits of changing the structure. Best, |
Sounds good, Anton! The point here is that if a subscription closes (i.e. a
process restarts or a box reload or any other issue), one can treat the
condition if the thread result is passed down. If not, what happens is that
the main script won't catch any exception, and basically get stuck.
…On Sun, Nov 13, 2022 at 8:58 AM Anton Karneliuk ***@***.***> wrote:
Hey @brunoonovais <https://github.com/brunoonovais> ,
The idea of running subscribe_stream in a separate thread was done for a
purpose of scalability to ensure that multiple threads can co-exist. We can
try to look if there will be any benefits of changing the structure.
Best,
Anton
—
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKG3BBH2Y5DQ4T7OUFRGHOTWIDXZRANCNFSM6AAAAAAR4YTWEU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I encountered a similar problem while using subscribe2. While it generally works well, we face issues with the session to the device, such as network problems, node reboot, or service interruptions, I am unable to receive errors through exceptions. The subscribe session stops sending updates and returns nothing, and I am unsure if there is another way to handle this. It would be helpful to have a method to check whether the grpc session to the device is still normal while receiving updates from the subscribe, or perhaps a way to reconnect the existing session again. |
I'm encountering similar issue while trying to subscribe for the path greater than the limit subscription_dict = {'subscription': [{'path': 'openconfig-interfaces:interfaces/', 'mode':'sample'}], 'mode': 'poll', 'encoding':'json'}
subscription_ids = []
for i in range(2):
subscription_id = client.subscribe_poll(subscribe=subscription_dict)
subscription_ids.append(subscription_id)
time.sleep(2) It's throwing me the below error but i'm unable to catch it
Is there any fix? def enqueue_updates():
stub = gNMIStub(channel)
subscription = stub.Subscribe(_client_stream, metadata=metadata)
for update in subscription:
try:
self._updates.put(update)
except Exception as error:
print(str(error))
raise Exception(error) |
@akarneliuk Can you please help us with this? We are interested in capturing the error. |
Hi Folks,
On a subscribe_stream call, we may receive the grpc._channel._MultiThreadedRendezvous exception.
It seems that for some reason, this is not caught by the script using pygnmi, but can be caught inside the enqueue_updates call, example:
I couldn't figure out why, so opening this case to see if we can fix this and close the channel when such error is seen, otherwise it can't be treated. Example of my code that never hits this exception:
A simple way to hit this is by subscribing to a path that doesn't exist.
The text was updated successfully, but these errors were encountered: