Comments (2)
Hmm, that's some interesting points (that also show how difficult it is how to build a robust implementation of such a system).
I think you are even pointing out multiple issues here:
- What is actually not an issue is that multithreading or ordering problems inside the WampClient. Because it internally uses a single thread it can guarantee that all received messages will be processed in order.
- However there really seems to be a small data race here. If a subscribe message the received the action is delayed through rescheduling to the eventloop (https://github.com/Matthias247/jawampa/blob/master/src/main/java/ws/wamp/jawampa/WampClient.java#L1300). This has the advantage that it decouples the actions. However it might lead to problem you describe. If an Event message is pushed from the transport before the handler is executed then the event will be dropped. The chance for this is really minimal (probably only when both Subscribed and Event messages are inside the same IP frame), but nevertheless it exists. Removing
.subscribeOn
should remedy this, but it needs to be checked whether this creates any side effects. For most distributed applications it shouldn't be an issue anyway, because there's always the possiblity that that the server already sent events that are important to you before you connected and subscribed and you might want to design your API around that fact. However this really might require the information whether subscribe was successful. - I agree that being able to retrieve the information that a subscribe succeeded would be helpful in some situations. But I'm currently also not sure what is the best way to express this in the API. One solution would be to have something like
Observable<Observable<PubSubData>> makeSubscribption()
where the first subscribed stream only yields a single value that signals that the subscription was succesful and the result is the actual stream of values to which you would need to subscribe. But the disadvantage is that this is very verbose, that the inner observable would need to buffer incoming events (the user would only get the chance to subscribe later to the Observable later than when the first events could be pushed) and that unsubscribing also gets tricky (Depending on the state you would need to either unsubscribe the outer or inner observable or even both).
Another idea would be that the API stays as it is and the stream always outputs a special first element that only signals success for the subscription. Some kind of static marker instance of thePubSubData
class. But for the overloaded variants ofmakeSubscription
which returnObservable<T>
instead ofObservable<PubSubData>
it gets tricky again. I don't see a way to have a marker instance for every possibleT
type.
from jawampa.
Yes I meant a data race, I didn't mean to imply that there was a threading
issue. In this particular scenario the services are running locally on the
same host so that's probably why I'm seeing it more frequently, in a fully
distributed setup the likelihood would seem to be low.
As for the changing the API or a potential fix, I agree I don't really like
the observable of observable approach either. For now I've just forked
locally and removed the subscribeOn to work around it, but I don't really
think this is the correct fix for what I'm trying to do either. I guess
I'll keep looking into a proper solution. I'm relatively new to RxJava as
well, so I'm not sure if there's a pattern for this type of use case...
On Jun 14, 2015 9:56 AM, "Matthias Einwag" [email protected] wrote:
Hmm, that's some interesting points (that also show how difficult it is
how to build a robust implementation of such a system).I think you are even pointing out multiple issues here:
- What is actually not an issue is that multithreading or ordering
problems inside the WampClient. Because it internally uses a single thread
it can guarantee that all received messages will be processed in order.- However there really seems to be a small data race here. If a
subscribe message the received the action is delayed through rescheduling
to the eventloop (
https://github.com/Matthias247/jawampa/blob/master/src/main/java/ws/wamp/jawampa/WampClient.java#L1300).
This has the advantage that it decouples the actions. However it might lead
to problem you describe. If an Event message is pushed from the transport
before the handler is executed then the event will be dropped. The chance
for this is really minimal (probably only when both Subscribed and Event
messages are inside the same IP frame), but nevertheless it exists.
Removing .subscribeOn should remedy this, but it needs to be checked
whether this creates any side effects. For most distributed applications it
shouldn't be an issue anyway, because there's always the possiblity that
that the serve r alread y sent events that are important to you before you
connected and subscribed and you might want to design your API around that
fact. However this really might require the information whether subscribe
was successful.- I agree that being able to retrieve the information that a subscribe
succeeded would be helpful in some situations. But I'm currently also not
sure what is the best way to express this in the API. One solution would be
to have something like Observable<Observable>
makeSubscribption() where the first subscribed stream only yields a
single value that signals that the subscription was succesful and the
result is the actual stream of values to which you would need to subscribe.
But the disadvantage is that this is very verbose, that the inner
observable would need to buffer incoming events (the user would only get
the chance to subscribe later to the Observable later than when the first
events could be pushed) and that unsubscribing also gets tricky (Depending
on the state you would need to either unsubscribe the outer or inner
observable or even both).
Another idea would be that the API stays as it is and the stream
always outputs a special first element that only signals success for the
subscription. Some kind of static marker instance of the PubSubData
class. But for the overloaded variants of makeSubscription which
return Observable instead of Observable it gets tricky
again. I don't see a way to have a marker instance for every possible T
type.—
Reply to this email directly or view it on GitHub
#44 (comment).
from jawampa.
Related Issues (20)
- State not changed to disconnected when connection is lost HOT 1
- Poloniex sequences HOT 13
- ApplicationError(wamp.error.invalid_uri, [], {}) even when URI is completely valid HOT 1
- How can I send a self-defined Java-class object(client) to fit a C++ class (server) by RPC HOT 1
- Web Connection works well on emulator but fail on real devices HOT 3
- Android < 5.0, TLSv1.2 and jawampa
- Problem with varargs in Publish method HOT 2
- Getting publication succeeded callback while network is disconnected HOT 2
- Subscription Id / Event History
- Convert to rxjava 2. Any plans?
- Subscription SocketTimeoutException
- Application throws java.lang.ClassNotFoundException: jdk.internal.misc.Unsafe exception during the creation of the client instance HOT 1
- Can we publish topic on session connection
- Android doesn't work HOT 1
- Correct way to make a client run
- wss secure websocket connection problem
- How to influence the json encoding/decoding? JsonViews possible? HOT 1
- Jawampa crashes when connections is closed. HOT 3
- Authentication in jawampa
- Cannot connect to server only on Android 7.0
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jawampa.