You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been using the "listening service model" for a while. And we want to try out “polling service mode” mode, but we found a concerning scenario regarding request routing during our testing.
Given a client runtime which has only trusted fingerprint "xxx" and a server subscribing to the queue "server-1" with fingerprint "xxx" we would expect the following:
A service request to ServiceEndpoint("poll://server-1", "xxx") should be routed to the server subscribing to “server-1”.
A service request to ServiceEndpoint("poll://server-1", "yyy") should fail.
However, both scenarios end up routing to the server subscribing to “server-1”. Is this intentional to allow a “competing consumers” pattern or is it a bug?
If it is intentional do you have a suggestion to how we can achieve a strict and secure 1 to 1 communication in polling mode?
The text was updated successfully, but these errors were encountered:
We have been using the "listening service model" for a while. And we want to try out “polling service mode” mode, but we found a concerning scenario regarding request routing during our testing.
Given a client runtime which has only trusted fingerprint "xxx" and a server subscribing to the queue "server-1" with fingerprint "xxx" we would expect the following:
ServiceEndpoint("poll://server-1", "xxx")
should be routed to the server subscribing to “server-1”.ServiceEndpoint("poll://server-1", "yyy")
should fail.However, both scenarios end up routing to the server subscribing to “server-1”. Is this intentional to allow a “competing consumers” pattern or is it a bug?
If it is intentional do you have a suggestion to how we can achieve a strict and secure 1 to 1 communication in polling mode?
The text was updated successfully, but these errors were encountered: