Issue or missunderstanding related to subscriptions.

[d-e-s-o]

Issue or missunderstanding related to subscriptions.

[All8Up]

I have a functional solution to this now. Thanks.

Just to clarify though:

If I use it inside the current loop it will be blocking (of the other polled items) while the command is in progress?

It's possible I am misunderstanding, but it's still an async function, so conceptually everything else should be able to make progress, I'd say. But (and I am not sure I am understanding your sample code 100%), I'd think you may run into borrowing issues with respect to stream.

Sorry, to be more clear, if I used drive within the select which is supposed to be polling the data stream, I would not be polling the other streams, i.e. the order updates and the command channel, not to mention any data items that came in during the subscription change would be lost as mentioned below. While that would probably be fine in normal use, if I'm building a proxy for the streams, that would be rather bad to drop data and of course have the latency issues on the other channels.

What I was considering is spinning up two separate tasks: one for all the data stuff as I have it now and the other that takes the subscription portion from connect and simply resolves the future returned from subscribe. If I'm reading things correctly, as long as I await the future and the other task is still polling the stream, it should work?

I think so, yeah.

So, this does seemingly work, I'll know more when the actual market opens of course.

[d-e-s-o]

Could you use drive function to resolve the future on the command dispatch path itself, i.e., in the Commands::ChangeSubscriptions handler block? Do you have the stream available there (I suppose you may into borrowing issues then, but not 100% sure)? It's not great, I agree, and certainly questionable if you intend to have high throughput in your proxy, but if I recall correctly it's all you will get.

Just conceptually (again, if I remember correctly), you can only ever have a single Subscription::subscribe operation in flight (which is kind of where the mut self comes from). The reason is that all it does in the background is to send a control message (request) over the stream and then wait for a control message response. From the Alpaca side, at least last I checked, there was no correlation between control message requests and responses, so we can't infer that this response belongs to that request and then dispatch accordingly. All we can say is that this is a control message that we just received, give it to the entity that made the last request. So in order to be correct, there can only be one requestor and all authenticate/subscribe/unsubscribe operations need to be serialized.

[All8Up]

I don't think that whatever I do will actually use the drive macro due to it requiring both the subscribe future and the mut stream. I.e. I can't use the drive macro outside of the current select because it needs the mut stream in addition to the future. If I use it inside the current loop it will be blocking (of the other polled items) while the command is in progress? (Also, I think any data messages that happen to show up get eaten? Wasn't sure about that bit.) What I was considering is spinning up two separate tasks: one for all the data stuff as I have it now and the other that takes the subscription portion from connect and simply resolves the future returned from subscribe. If I'm reading things correctly, as long as I await the future and the other task is still polling the stream, it should work?

[d-e-s-o]

I don't think that whatever I do will actually use the drive macro due to it requiring both the subscribe future and the mut stream.

Fair enough. Your use case is different than what it was designed for.

If I use it inside the current loop it will be blocking (of the other polled items) while the command is in progress?

It's possible I am misunderstanding, but it's still an async function, so conceptually everything else should be able to make progress, I'd say. But (and I am not sure I am understanding your sample code 100%), I'd think you may run into borrowing issues with respect to stream.

(Also, I think any data messages that happen to show up get eaten? Wasn't sure about that bit.)

Yep. I thought the documentation made that clear, but looking at it I don't see it mentioned either...

What I was considering is spinning up two separate tasks: one for all the data stuff as I have it now and the other that takes the subscription portion from connect and simply resolves the future returned from subscribe. If I'm reading things correctly, as long as I await the future and the other task is still polling the stream, it should work?

I think so, yeah.