Server not online example? about qactive HOT 7 CLOSED

Thanks for the feedback! I plan to explain Qactive in a future part of my RP101 video series:

Playlist: https://www.youtube.com/playlist?list=PLzLa5EktSmly4OP2nvzGfwdbVDn52d1rM
Source: https://github.com/RxDave/ReactiveProgramming

You can think of Qactive as simply stretching an observable over the wire. Currently, Qactive doesn't provide any facilities for persistence, fault tolerance, or sequence numbers. I believe it's the latter that you're looking for specifically; i.e. identify particular messages so that clients don't see repeats. The semantics of a query in Qactive are entirely up to you. If you want an observable that tracks client identifiers and message identifiers, then you'll have to define it yourself.

Furthermore, Qactive wasn't intended to implement a peer-to-peer service bus architecture. It's a client/server architecture, with a persistent duplex socket connection.

That said, I'm not necessarily opposed to extending it or redesigning it, but I simply have no need for a different kind of architecture at the moment.

I know it's probably not the answer you're looking for, but it's all I've got at the moment. :-)

from qactive.

hmm I wish to reopen this case as I did not find an observable way to restart the client subscription methods like Repeat, Catch, OnErrorResumeNext have no effect, the only way is to recreate the Query from Scratch and re Subscribe.

from qactive.

Persistence and fault tolerance are not currently provided by Qactive. It's a larger problem with many factors and possible solutions. Bart De Smet's presumably ongoing project, along with his supporting version of Rx, addresses these issues, but I don't think it has been released yet.

It depends on what you need exactly, and what trade-offs you're willing to make.

Expression trees are serializable in Qactive using a BinaryFormatter. (I'm still working on my improved graph serializer, so BinaryFormatter will have to do for now.) Thus you can persist a client's query by serializing it to memory, and/or a file or DB. You'll also need an identification mechanism. There's an example in the source's examples project that illustrates how to send arguments along with a query, and perhaps this can be used to authenticate a client, to uniquely identify their query. Theoretically, you could also define your own server sink that does something like the following (presuming that we only want to allow one standing query per client):

1. When a query arrives, after it's been rewritten on the server, do a lookup with the client ID and compare the persisted query with the serialized query.
2. If they are different, then replace it and continue; however, multicast the query so that it remains active even if the client disconnects..
3. If they are the same, then reconnect to the existing query (I don't have any suggestion at the moment as to how that may work exactly. But I'll definitely think more about it.)
4. If the client goes offline, then the server should timestamp it. A background process must kill any queries that have been determined to have become orphaned, based on duration and perhaps other factors.

This is obviously not an exhaustive analysis, but hopefully it illustrates the difficulty in designing a general solution to this problem. E.g., how does unique identification work? What technologies are used for persistence? What is the policy for orphan detection? How can a client permanently handle its query in a timely manner?

I'll think about it more and leave this item open. Thanks for your question!

Edits: Fixed typos.

from qactive.

Hmm, on a second read of your question, I'm not sure that I actually answered the right one?

If the server goes offline, then surely the client is stuck right? The point of running a query on the server is because you require data from that server, so if it goes offline, then it's not like you can simply rum the query on the client. Or am I misunderstanding your question?

from qactive.

from qactive.

from qactive.

RxDave commented on Aug 14
I plan to explain Qactive in a future part of my RP101 video series

I watched your RP101 videos and you don't seem to have finished the series. I was very interested in the way you composed the queries together, but was disappointed that you spent so much time on WPF and analysing the spec and so little time on Rx. There are so few resources on the internet that go beyond the basics of reactive programming in C# that it's hard to learn the paradigm.

from qactive.