Comments (10)
but can be useful to others coming from google to solve this issue
Definitely! And who knows, perhaps we implement your solution as well. I’m just not sure about this, yet.
This seems like a dead end, so I'm closing this issue
Sorry for that annoying situation here, but let’s keep the issue open. We have to keep in mind that this is something that we have to fix, wait for an upstream fix, or implement a workaround.
from android-ddp.
Excellent point, thank you!
The cause of this behavior may be that the session ID, which is declared here and set here as received from the server after the connection has been established, is cleared when disconnecting from the server.
If we then re-connect with a new session ID, the server has no way to know what subscriptions to send to us. They’re lost. So this commit is an attempt to fix this issue by not dropping the session ID.
You can test the version with the potential fix by changing your Gradle dependency to the following:
compile 'com.github.delight-im:Android-DDP:0f743e22b7c4405c95695ca58f50e2ad9b1ff5e1'
Does that change anything?
from android-ddp.
Nope, the problem has not been solved using that version of the library. I have been inspecting the mSessionID variable across an execution of the application, and tried several executions. If I don't do any disconnect, the session ID will be always the same, but when calling to disconnect, when the server reconnects, sends a new session ID (or, at least, this is the behavior I can extract from this (cropped) log):
Meteor_id: 98J2ofghY6xyNuSNe
Meteor
onOpen
Meteor
send
message == {"msg":"connect","support":["1","pre2","pre1"],"session":"98J2ofghY6xyNuSNe","version":"1"}
dispatching
Meteor
onTextMessage
payload == {"server_id":"0"}
Meteor
onTextMessage
payload == {"msg":"connected","session":"2PGdyj5WkSCnG4ogR"}
Meteor
send
message == {"msg":"method","id":"03c60e15-2143-4c96-9011-c3a3b622253e","params":[{"resume":"Mepu9vxA2o8qaZ5EvElHJHhLOYCTx7DnTZj6kIgGmUd"}],"method":"login"}
dispatching
Meteor
onTextMessage
payload == {"msg":"added","collection":"users","id":"vn397TWBuP55o68r5",
"fields":{"emails":[{"address":"*vfrico*","verified":true}],
"profile":{"type":"human","layers":[{"privilege":"public","id":"ROUTESMAD","sendTo":"False"}],
"description":""},"username":"*vfrico*"}}
Meteor_id: 2PGdyj5WkSCnG4ogR
My application has a wrapper for this Meteor DDP library, so we have simulated the desired behavior by tracking with lists the topics subscribed. We also have created two simple methods, pause() and resume() to manage a pause for the server.
I don't know if this solution is too ad-hoc and would worth to integrate on the library and publish a PR with it...
Thanks
from android-ddp.
Thanks a lot for testing and debugging this!
the session ID will be always the same, but when calling to disconnect, when the server reconnects, sends a new session ID (or, at least, this is the behavior I can extract from this (cropped) log)
That’s also what I read from your log. The client-to-server message
{"msg":"connect",...,"session":"98J2ofghY6xyNuSNe",...}
really should ask the server to pick up this session ID and re-use it. The server then responding with
{"msg":"connected","session":"2PGdyj5WkSCnG4ogR"}
is a bit strange but could still mean that the server picked up the ID correctly and just refreshed the ID, keeping any associated state. But that’s apparently not what happened. From your log, however, it is not obvious if this really did not happen. Are you really sure that subscriptions are not remembered anymore from that point on?
From what I can read in the specification of the protocol, which is a bit vague and lacks detail, what we do is correct here. So I would say this may be a Meteor issue or at least something where we don’t know if this is the behavior they expect. Perhaps keeping subscriptions across connections (albeit with the same session ID) is not something they have actually implemented.
Your wrapper and the workaround sound interesting, and could really be something for this library. But at this point I feel we would rather be hiding the symptoms and concealing what’s actually happening, ignoring the underlying bugs. So if there’s any chance we could fix something here or the Meteor project could clear things up, I’d rather do that.
from android-ddp.
I do not have a total control over the remote Meteor server. I will ask for more information about if this is a server issue or a client issue.
I have checked and with my workaround I receive the subscriptions after a pause->resume cycle, but with the actual branch issue-144
I don't get any updates after a disconnect->reconnect cycle.
As you say, it is better to solve the actual problem rather than having a workaround.
from android-ddp.
Thanks!
I do not have a total control over the remote Meteor server. I will ask for more information about if this is a server issue or a client issue.
No problem. It really seems like a server issue. Or we got something wrong with our understanding of the protocol. It doesn’t look like a simple implementation issue in the client.
I have checked and with my workaround I receive the subscriptions after a pause->resume cycle, but with the actual branch
issue-144
I don't get any updates after a disconnect->reconnect cycle.
Too bad! We can confirm that the provided (old) session ID is not picked up by the server (which just sends a new one). Additionally, it seems the server does not remember the previous subscriptions, either.
I see three possibilities here for why this happens:
- Meteor’s protocol (DDP) does not support this and it was never meant to be supported.
- There’s a bug in Meteor’s protocol (DDP) with regard to this issue (or the two symptoms we’ve seen).
- We’ve misunderstood how Meteor’s protocol (DDP) is supposed to work.
from android-ddp.
Finally, I couldn't get any information about the remote server, so I can't go too far on this issue. I don't have time to fire up a Meteor server and research where the error could be.
Without having clear how the Meteor server works, maybe when executing disconnect()
is possible that the server forget that sessionID and that may be the reason why sends a new sessionID. Maybe this feature is used to reconnect after a network problem rather than after the client has executed a disconnect()
.
from android-ddp.
Well, I have found this searching a bit on Google: Meteor Server's Connection
Currently when a client reconnects to the server (such as after
temporarily losing its Internet connection), it will get a new connection
each time. The onConnection callbacks will be called again, and the
new connection will have a new connection id.In the future, when client reconnection is fully implemented,
reconnecting from the client will reconnect to the same connection
on the server: the onConnection callback won’t be called for that
connection again, and the connection will still have the
same connection id.
So, this means that is a possible future upgrade 😩
Edit: As a reference, I have implemented on the library something similar than I have on my wrapper. It is not tested: vfrico@3e68cb9
from android-ddp.
Without having clear how the Meteor server works, maybe when executing
disconnect()
is possible that the server forget that sessionID and that may be the reason why sends a new sessionID. Maybe this feature is used to reconnect after a network problem rather than after the client has executed adisconnect()
.
That would clearly have been the most obvious explanation. We also thought that the problem occurs only with manual disconnects which may intentionally destroy the old session. But that’s not actually the case. If the disconnect happens due to network problems, the old session is not picked up, either.
Well, I have found this searching a bit on Google: Meteor Server's Connection
It is not entirely clear whether this is really talking about the exact same thing, because it uses different vocabulary. But unfortunately, it really seems that this has not been implemented in Meteor yet, although the DDP specification supports it.
As a reference, I have implemented something similar: vfrico@3e68cb9
Looks good. I would definitely prefer the behavior to be fixed in a clean way, possibly requiring a fix in Meteor, but we may not get that. Otherwise, implementing that workaround in the basic methods for reconnecting (or just connecting in general) would probably be preferable to adding another set of methods with new semantics. And finally, with that solution, the server will probably re-send all the data after reconnecting. That is not optimal, but maybe the best we can get.
from android-ddp.
Looks good. I would definitely prefer the behavior to be fixed in a clean way, possibly requiring a fix in Meteor, but we may not get that. Otherwise, implementing that workaround in the basic methods for reconnecting (or just connecting in general) would probably be preferable to adding another set of methods with new semantics. And finally, with that solution, the server will probably re-send all the data after reconnecting. That is not optimal, but maybe the best we can get.
I didn't add a PR because I know is not the preferrable way to go, and might not be included on the library, but can be useful to others coming from google to solve this issue.
This seems like a dead end, so I'm closing this issue
from android-ddp.
Related Issues (20)
- Json result containing null value are converted to {"$InfNaN":0} HOT 5
- Notify only specific user HOT 1
- Switch to GSON HOT 3
- How to use android-ddp with requery HOT 1
- destroyInstance() breaks if not connected HOT 2
- Insert byte[] in collection HOT 3
- SubscribeListener does not has the callback response? HOT 3
- i cannot connect to server HOT 1
- wifi -> lte, when internet connection is changed, Connection timed out is occured immediately HOT 1
- Multi subscribe
- How to call methods with array of objects with keys HOT 1
- How to get collections without database HOT 1
- Is it possible to get a MongoDB database from the Meteor connection? HOT 1
- Can you add a method to use a JSONObject or JSONArray or JSON String instead of an array of objects? HOT 1
- wss error handshake HOT 10
- I subscribe, I cancel the subscription and then I subscribe again and the OnDataAdded does not trigger
- Any listener (or method) to find out if all the subscribed data was received from server? HOT 2
- Is there any way to cancel the "call" request?
- Unable to use websocket connection over ssl HOT 2
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 android-ddp.