I have a problem with the design of mysql client library.
MySQL requires that each thread that uses the MySQL API first call mysql_thread_init()
and at the end call
mysql_thread_end().
If the thread fails to call
mysql_thread_end(),
then MySQL will block the main thread at program termination and wait for this threads to call
mysql_thread_end().
If that doesn't happen, then it prints an error message to STDERR. Not a very user-friendly behavior.
now the problem is that i m inside an ISAPI dll, it's not me who create the thread (nor destructing it), it's IIS that manage it.
How can i be warned then the thread will end to call mysql_thread_end ?
Related
I have an Apache Camel route which handles messages from a queue. To better understand what is happening at runtime I also keep the execution state in a database (number of retries, last execution state,...). I would like to use the redelivery mechanism from the exception handler but which performs some processing on every failure to update my database record.
from("jms:myinputqueue")
.onException(RetriableException.class)
.maximumRedeliveries(5)
.maximumRedeliveryDelay(10000)
.useOriginalMessage()
.to("log:store error information in database about each attempt") // (1)
.end() // onException
.to("log:apply business logic here which can throw exceptions")
;
The part (1) is only executed after all retries are exhausted, so only once.
I've read Apache Camel- Message Redelivery happens before onexception block executes but the suggested solution ''onRedelivery'' is executed before the beginning of a new retry. I need to store the result on each failure so I can save the last state (error message) in the database.
Any suggestions ?
There is an onExceptionOccurred processor you can use that is called when the exception happened.
Its included in Camel 2.17 onwards: https://issues.apache.org/jira/browse/CAMEL-9069
I am fetching couchbase mutations through java code similar to run function in https://github.com/couchbase/couchbase-kafka-connector/blob/master/src/main/java/com/couchbase/kafka/CouchbaseReader.java . We subscribe with a io scheduler instead of toBlocking at the end. We get mutations and streamEndMessages but we never get onComplete. Hence the code just waits until killed.
We use core-io-1.2.6, and with top of branch core-io-1.3.0.
This is known limitation at the moment, which will be fixed in next version
In Lablgtk, whenever there is an exception in a callback, the exception is automatically caught and an error message is printed in the console, such as:
(prog:12345) LablGTK-CRITICAL **: gtk_tree_model_foreach_func:
callback raised an exception
This gives no stack trace and no details about the exception, and because it is caught I cannot retrieve this information myself.
Can I enable more detailed logging information for this case? Or prevent the exception from being caught automatically?
I guess the best way to do so is to catch your exception manually and handle it yourself.
let callback_print_exn f () =
try f () with
e -> my_exn_printer e
Assuming val my_exn_printer : exn -> unit is your custom exception printer, you can simply print your callbacks exceptions by replacing ~callback:f by ~callback:(callback_print_exn f) in your code.
Of course, you can also with that method send that exception to another
thread, register a "callback id" that would be passed along with your exception...
About the stack trace, I'm not sure you can retrieve it easily. As it's launched as a callback, you probably want to know the signal used and that can be stored in your callback handler.
I had another similar issue, but this time it was harder to find where to put the calls to intercept the exception.
Fortunately, this time there was a very specific error message coming from the Glib C code:
GLib-CRITICAL **: Source ID ... was not found when attempting to remove it`
Stack Overflow + grep led me to the actual C function, but I could not find which of the several Lablgtk functions bound to this code was the culprit.
So I downloaded the Glib source, added an explicit segmentation fault to the code, compiled it and used LD_LIBRARY_PATH to force my modified Glib version to be loaded.
Then I ran the OCaml binary with gdb, and I got my stack trace, with the precise line number where the Lablgtk function was being called. And from there it was a quick 3-line patch.
Hacks like this one (which was still faster than trying to find where to intercept the call) could be avoided by having a "strict mode" preventing exceptions from being automatically caught. I still believe such a switch should be available for Lablgtk users, and hope it will eventually be available.
When i use IMvxmessenger i get an exception that says An exception of type 'System.Exception' occurred in mscorlib.dll but was not handled in user code WinRT information: The application called an interface that was marshalled for a different thread. Additional information: The application called an interface that was marshalled for a different thread.If there is a handler for this exception, the program may be safely continued.
From the information in your question it's very hard to add much real advice.
Clearly you are using a message from the messenger to access something that is thread critical.
MvvmCross and WinRT both provide ways to marshal method calls on to specific threads - e.g. there are several different Subscribe methods provided by the messenger to allow you to specify context - see https://github.com/MvvmCross/MvvmCross/wiki/MvvmCross-plugins#messenger
The three different options for subscribing for messages differ only in terms of which thread messages will be passed back on:
Subscribe - messages will be passed directly on the Publish thread. These subscriptions have the lowest processing overhead - messages will always be received synchronously whenever they are published. You should use this type of subscription if you already know which type of thread the Publish will be called on and if you have a good understanding on the resource and UI usage of your message handler.
SubscribeOnMainThread - any message published on a background thread will be marshalled to the main UI thread. This type of subscription is ideal if your message handler needs to perform some resource-unintensive task which involves interacting with the UI.
SubscribeOnThreadPoolThread - messages will always be queued for thread pool processing. This always involves an asynchonous post - even if the message is published on an existing ThreadPool thread. This type of subscription is ideal if your message handler needs to perform some resource-intensive task as it won't block the UI, nor the message publisher.
Let suppose I create a class, and in this class I declare a method that will run a loop.
My question is what will be behavior of loop, if I dispose the object of class and condition of loop is yet true - will loop execute or terminate.
Usually the object (variable) is managed by a single thread. So you may not be able dispose of easily because the thread is still running in the loop. If you mult-thread and you call in a method that modifies this variable (your object) on the a different thread you may crash your program. If your loop in a UI thread which has a message pump (sta thread) and you call a method directly from another thread then you app will crash as this is not allowed.
All in all what do you want to do ? Mark Byers's condition "The code keeps running" is the most possiable outcome of this I think. But you have a bug either way - don't attempt to drive a car and then just jump out of it without stopping.