I'm working locally with Firestore for the web (Firebase version 9.8.2) and am trying to enable persistence. This works fine on initial page load, and also on refreshes, but once the source code is changed (even a trivial change like changing the text content of a DOM node), I receive the following error after calling enableIndexedDbPersistence:
Failed to obtain exclusive access to the persistence layer. To allow shared access, multi-tab synchronization has to be enabled in all tabs. If you are using experimentalForceOwningTab:true, make sure that only one tab has persistence enabled at any given time.
This same error occurs in the same way even if experimentalForceOwningTab:true is set.
According to the API Reference docs for enableIndexedDbPersistence, the property is now called forceOwnership (not experimentalForceOwningTab). This works!
Related
Here's the definition for the query, when I navigate to a page or the app restarts, all useGet...Query just returns the cache data (the data with the specific parameter indicated in the red box). Why does it not update when the page rerenders and only returns cache data? I will set many invalidate tags to ensure it can be forced to refetch but it does not work.
As I'm working with the expo, I don't know why but after I uninstalled the expo and re-install it then it works fine.
It seems restricting that I can only get a snapshot from my database to read data from on data change. Is there something I'm missing about OnDataChange?
What if I want to populate a page with data read dynamically from my database, yet no data is changing in the database? I still need to call OnDataChange?
Firebase's onDataChange fires immediately with a snapshot of the current value in the database and subsequently whenever the data changes.
In fact, the Firebase documentation says this:
This method is triggered once when the listener is attached and again every time the data, including children, changes.
The simple answer is you can't block the User Interface with a long running task such as a database query or network request. At best the user will have an unresponsive application at worst an "application not responding exception" (ANR)crash will happen. That's why it is designed with a listener pattern. I assume this is android we are talking about, however the answer is valid for other platforms. If you are doing this on a background thread yes you could do what you are saying, in theory. I don't think firebase is designed that way.
Meteor is supposed to pre-load a small part of Mongo client-side so that it can simulate changes to the DB. Thus making any changes to the page happen instantly while the real DB update happens in the background.
However, on my site I'm seeing a 1-2 second delay on simple actions that make changes to the DB, such as deleting a post.
Is there some extra coding that needs to be done to ensure the client-side simulation works?
As Michel Floyd Pointed out, if your meteor method is defined as server only code, there is no way to simulate the method call on the client.
Try moving Meteor method declarations into shared code, and see if that changes latency time.
also, without seeing some code and project structure the problem could be else where...
If you are using server-side method only, make sure your Mongodb has oplog tailing enabled, so that the change is picked up immediately and sent to the client. If you are using like a hosted db, like the free mlab, it's possible you have no oplog, the meteor falls back to querying the db periodically to check for changes.
But in any case, if the method is server side only, you will always have delays. Like mentioned in this thread, move the method definition outside the server folder (like /lib) só that the method becomes available on th client.
I'm building a somewhat big application. When changing code the server restart and force refresh on the client.
The client keep his session data, but I seem to lose the Meteor.Collection previously sync data, forcing my user to re-sync everything.
I use 0.5.7(did not see anything in 0.5.8 about that)
Is that the expected behavior or I'm I missing something?
This can be tested by adding something like that at your client start (Assuming Components is your Meteor.Collection)
console.log("Length: ", Components.find().fetch().length);
No, you're not missing anything. The collection data should be re-synced on code pushes. However, if your collection data takes more than a second or two to load in, you should look into trying to send less data to the client by creating finer-grained subscriptions that only send data the client needs at the moment.
I'm using web api self host inside a windows service and I've encountered a problem and after googling for couple of hours haven't found a reasonable answer.
One of the api controllers serves large stream of data (not really that large, couple of tens of MB). It takes some time to produce data so I've decided to use TransferMode.StreamedResponse to minimize the time client has to wait for response. I've also added a CompressHandler and custom CompressedContent (derived from HttpContent) mostly based on a following answer.
The controller returns an instance of IDataReader, which is then serialized by custom formatter which is lastly compressed inside CompressedContent that I've mentioned. The whole data passing is streamed so while the client receives data, a data reader on server side may still be reading rows from database. Everything works fine when client is acting nicely.
The problem occurs when a client drops connection while the data is still being serialized to the underlying network stream. I've tried to watch for IsFaulted task inside of ContinueWith delegate (in CompressedContent from the link) and dispose underlying network Stream. Unfortunately the CommunicationException (The specified network name is no longer available) is still being thrown when the control leaves my code. From the stacktrace it looks like the exception is thrown when the Web Api tries to close (end) the underlying network stream (http channel?). As it happens with unobserved exceptions it brings entire windows service down.
I've mitigated the problem by setting windows service recovery options but I would like to know if this failure can be handled in code.
Is there a way to setup a custom error handler (IErrorHandler presumably) inside web api self hosting service mode to prevent this kind of error?
I'm using Beta version, I will try to reproduce this error on RC but I somehow doubt that setting up this kind of error handler would change in any way
We had the same issue. I was able to submit a fix to MS and they have in turn released a nightly build that fixes this. They are looking at back porting the fix to the RTM. You can see the pull release here: http://aspnetwebstack.codeplex.com/SourceControl/network/forks/rdean79/issue284/contribution/3329