I have called it as described in official documentation, in onDestroy() of my activity and initialized it in oncreate() but sometimes it gives error " Realm is already closed making it unusable"
A realm object is associated with the current thread it has been obtained on. That means you can only read and write to that realm on the same thread.
Running from a different thread? Instantiate a new realm on that
thread.
Related
There is a requirement in my project where I have class in which I am creating ros2 node (using rclpy) I have to create a publisher and subscriber which subscribe to specific topic ,but I have to publish msg to the topic based on the recieved msg in the callback.
I need to use th above object in other part of the project.
As rclpy.spin() will block the process I tried to run it in a thread ,but I am getting "generator already executing" runtime exception.
Can you please tell me how to resolve this issue or what is the alternate solution for my usecase
Looking for some clarification as to how one can log caught exceptions using flutter's firebase_crashlytics package.
If I understand correctly (and from running some sample code) Crashlytics.instance.log('text'); will only add logs to the next crash report, rather than send off a non-fatal issue itself.
I'm looking for functionality which is equivalent to Crashlytics.logException(e); on Android, e.g.
try {
throwException();
} catch (e) {
Crashlytics.logException(e);
}
which allows you to log caught exceptions so they appear as non-fatal issues in the Crashlytics dashboard.
Is this currently possible with flutter's firebase_crashlytics package?
Is calling Crashlytics.instance.recordError('text', StackTrace.current) the way to achieve this for now?
Many thanks!
Short answer, yes.
Crashlytics.instance.recordError() is the equivalent of Crashlytics.logException()
If you dig into the Flutter firebase_crashlytics source code, you can actually see what Android APIs are involved.
Flutter’s recordError() invokes the method Crashlytics#onError in the Android library.
And tracing Crashlytics#onError, you’ll see that it goes to Crashlytics.logException(exception);
Additional note, you’ll also notice why Crashlytics.instance.log() ”will only add logs to the next crash report”. These logs are added to a ListQueue<String> _logs which is then packaged into the next call of recordError()
A snippet of Flutter’s invocation of Crashlytics.logException():
_recordError(...) {
...
final String result = await channel
.invokeMethod<String>('Crashlytics#onError', <String, dynamic>{
'exception': "${exception.toString()}",
'context': '$context',
'information': _information,
'stackTraceElements': stackTraceElements,
'logs': _logs.toList(),
'keys': _prepareKeys(),
});
}
And some reference notes for Crashlytics.logException():
To reduce your users’ network traffic, Crashlytics batches logged
exceptions together and sends them the next time the app launches.
For any individual app session, only the most recent 8 logged
exceptions are stored.
To add to the accepted answer, Crashlytics.instance.recordError() has now been deprecated for the new method FirebaseCrashlytics.instance.recordError(exception, stack).
BONUS TIP:
I had this problem where all the logged exceptions are grouped under the same issue in Crashlytics dashboard. These might be different crashes of the same or different code components. Due to this, I had to manually go through each instance of the crash to verify.
From my own testing, I found out the grouping is based on the top-most line in the stack trace you passed into the method above. Luckily, Dart has an easy way to get the current stack trace using StackTrace.current.
So to properly group the issues: get the current stack trace at the time of the exception and pass it in FirebaseCrashlytics.instance.recordError(exception, stack).
Hope this helps someone out there, I looked everywhere on the internet for a similar issue but can't find any.
I am facing an issue in my deployment where I am using a completable future to do asynchronous task in tomcat servlet (version 8.5.23).
I am aware that my following question could not say much about the implementation details but unfortunately I could not come up with a simple example to recreate the issue. Please pardon me for that. I hope that some experts in the field can give me high level advice or suggestion which I could further look into it.
It’s a follow up of my previous question Do the task asynchronously but reply first.
What I would like to do was “whenever I receive a request from the client then I have to start a task which may take an hour. Therefore I have immediately reply to the user that ‘the task has started’ before the task finishes.
I initially used AsyncContext.start() to do this but what I found that AsyncContext won’t return the response to the client until it calls the onComplete(AsyncEvent event).
Therefore I replaced AsyncContext.start() with CompletableFuture.runAsync(Runnable). It initially appeared to me that it’s doing the correct job but later I found out that it’s giving me an issue.
In my task I was using com.caucho.hessian.client.HessianProxyFactory.create(Class api, String urlName) to create proxy class of backend interface but
after using the completable future then a runtime occurs which says the java.lang.RuntimeException: java.lang.IllegalArgumentException: interface MyInterface is not visible from class loader.
I will be grateful if, somebody can throw some light into the issue
I found out a solution for my issue. It seems to work now but I do not know whether it would it create a new issue. I basically ensured that the async task used the same class loader.
ClassLoader cl = Thread.currentThread().getContextClassLoader();
CompletableFuture.runAsync(() -> {
try {
Thread.currentThread().setContextClassLoader(cl);
.......
We are using the SQLite.NET PCL in a Xamarin application.
When putting the database under pressure by doing inserts into multiple tables we are seeing BUSY exceptions being thrown.
Can anyone explain what the difference is between BUSY and LOCKED? And what causes the database to be BUSY?
Our code uses a single connection to the database created using the following code:
var connectionString = new SQLiteConnectionString(GetDefaultConnectionString(),
_databaseConfiguration.StoreTimeAsTicks);
var connectionWithLock = new SQLiteConnectionWithLock(new SQLitePlatformAndroid(), connectionString);
return new SQLiteAsyncConnection (() => { return connectionWithLock; });
So our problem turned out to be that although we had ensured within the class we'd written that it only created a single connection to the database we hadn't ensured that this class was a singleton, therefore we were still creating multiple connections to the database. Once we ensured it was a singleton then the busy errors stopped
What I've take from this is:
Locked means you have multiple threads trying to access the database, the code is inherently not thread safe.
Busy means you have a thread waiting on another thread to complete, your code is thread safe but you are seeing contention in using the database.
...current operation cannot proceed because the required resources are locked...
I am assuming that you are using async-style inserts and are on different threads and thus an insert is timing out waiting for the lock of a different insert to complete. You can use synchronous inserts to avoid this condition. I personally avoid this, when needed, by creating a FIFO queue and consuming that queue synchronously on a dedicated thread. You could also handle the condition by retrying your transaction X number of times before letting the Exception ripple up.
SQLiteBusyException is a special exception that is thrown whenever SQLite returns SQLITE_BUSY or SQLITE_IOERR_BLOCKED error code. These codes mean that the current operation cannot proceed because the required resources are locked.
When a timeout is set via SQLiteConnection.setBusyTimeout(long), SQLite will attempt to get the lock during the specified timeout before returning this error.
Ref: http://www.sqlite.org/lockingv3.html
Ref: http://sqlite.org/capi3ref.html#sqlite3_busy_timeout
I have applied the following solution which works in my case(mobile app).
Use sqlitepclraw.bundle_green nugget package with SqlitePCL.
Try to use the single connection throughout the app.
After creating the SQLiteConnection.
Apply busytime out using following call.
var connection = new SQLiteConnection(databasePath: path);
SQLite3.BusyTimeout(connection.Handle, 5000); // 5000 millisecond.
I am trying to make a multi threaded Qt Application that uses QGLWidgets and I keep getting this error.(I am trying to paint from another thread using QPainter)
And it also looks like I have a huge memory leak because of it.
The error is "QGLContext::makeCurrent() : wglMakeCurrent failed: The operation completed successfully"
I believe this is related to a rather old issue from the Qt mailing list as described here. In short, if the thread calling makeCurrent() does not equal the thread where the device context was retrieved, GetDC() is called. As outlined in the linked thread, the problem is that ReleaseDC() is not called accordingly, resulting in a handle leak, and triggering Windows to return NULL in the call to GetDC() at some point, which makes wglMakeCurrent() fail. I don't know, however, why GetLastError() claims "The operation completed successfully" in this case.