I have a C++ application that connects to an Oracle database via the Qt QSqlDatabase interface. The main application establishes and uses the connection to the database along with starting a child process for unrelated other porpuses. To make this clear: the child process does not use any database relevant stuff.
The problem is now: If the main process gets terminated in an unusual way (it crashes or it gets killed by the user via the Task Manager), I can see that the database session on the Oracle server gets kept alive and does not timeout whatsoever. Absolutely reproducibly, however, the session gets cancelled immediatelly after I kill the child process manually.
As those dangling, orphaned sessions lead to some problems (the simplest beeing that the max session count on the server gets reached), I would really like all sessions to be closed as soon as possible.
My question now is: what is the mechanism that keeps a session alive on the server just because an irrelevant child process is still alive? How can I control this behavior, i.e. tell the oracle client to disconnect any sessions if the main application process dies?
Thanks in advance!
UPDATE
https://bugreports.qt.io/browse/QTBUG-9350
and
https://bugreports.qt.io/browse/QTBUG-4465
On Windows, the child process inherits sockets and file-descriptors even inheritFileDescriptors is set to false
Seems that the bug was fixed in QT5
A discussion about the issue on an Oracle thread:
https://community.oracle.com/thread/1048626
TL;DR; The oracle server does not "know" that the client has disappeared.
Some solutions:
1.There is a terminated connection detection feature:
http://docs.oracle.com/cd/B19306_01/network.102/b14213/sqlnet.htm#sthref474
2.My advice is to try to implement a 'connection pool' if you use QOCI driver. Or you can use ODBC which has support for connection pooling.
Looks like main process didn't terminated successfully and awaits for child process termination in some place of finalization code before closing database connection.
From other side exceptional situation raised by abnormal termination of child process successfully propagated to parent process which starts finalization process and closes connection to Oracle.
So first suggestion is to check if child process properly reacts on kill() and terminate() calls, and even parent process try to terminate child in case of abnormal termination.
Related
Putting existing problems aside, I was moving to test the ability of the server to handle multiple requests in my server application in universal app. It appears that it cannot handle multiple requests as advertised in the documentation. (See the source file ServerTask.cpp and MainPage.xaml.cpp for the related code and the README for background information.)
In background i.e. suspended mode, subsequent requests end up with
WinRT information: The object identifier does not represent a valid object.
EDIT: Just run again and the background ServerTask is not executing at all. When ClientTask is triggered, the app is automatically woken up from Suspended state and netstat indicates that it is listening to the appropriate port but not responding to the requests.
While in the foreground mode, subsequent requests end up with
WinRT information: An existing connection was forcibly closed by the remote host.
which mean that I should not do
delete args->Socket;
after handling the request in MainPage::OnConnectionReceived. If I delete that line, it can handle 2-3 requests and still end up with the same exception. On the other hand, is it the right way to go, leaving open sockets?
How should it be implemented?
I am using CFTHREAD on ColdFusion 8.
Occasionally I find that all the threads stop executing and remain with STATUS=NOT_STARTED
The server monitor tells me that there are no running requests, no running threads and an increasing number of queued threads.
The only way to recover is to restart the ColdFusion instance.
I only use threads in a handful of places. Some of the calls to CFTHREAD are JOINED - in this case I terminate any threads which have not completed within the timeout. Some of the calls to CFTHREAD are fire and forget.
Does anyone know why this might be happening?
Thanks,
William Bibby
In one of my application I already faced thread hanging issue. That's because, my thread was running some HTTP call or huge file downloading procedure, it was facing connection timeout problem.
Due to this thread hanging our server also becomes very busy because resources acquired by the running thread can't be released.
My Solution: Just check from how much time the thread is running. If it more than a specific interval then I was killing the thread by code.
You can use ColdFusion Admin API to kill a thread. If you want how to kill a thread using admin API then see here
I am getting intermittent errors -
child process XXX still did not exit, sending a SIGTERM.. and then a SIGKILL. It occurs intermittently and the web page hangs.
I was not using Daemon process..but now I am, still the problem exists..
Also I have some Error opening file for reading: Permission Denied.
Please can someone help?
I am new to this forum, so sorry if that has been answered before.
If you were not using daemon mode of mod_wsgi, that would imply that Apache must have been restarted at the time that initial message was displayed.
What is occurring is that in trying to do a restart, Apache sends a SIGTERM to its child processes. If they do not exit by their own accord it will send SIGTERM again at 1 second intervals and finally send it a SIGKILL after 3 seconds. The message is warning you of the latter and that it force killed the process.
The issue now is what is causing the process to not shutdown promptly. There could be various reasons for this.
Using an extension module for Python which doesn't work in sub interpreters properly which is deadlocking and hanging the process, preventing it from shutting down. http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
Use of background threads in the Python web application which have not been set as being daemon threads properly with the result they are then blocking process shutdown.
Your web application is simply trying to do too much on process shutdown somehow and not completing within the time limit.
Even if using daemon mode you will likely see this behaviour as it implements a similar shutdown timeout, albeit that the timeout is configurable for daemon mode.
Anyway, force use of the main Python interpreter as explained in the documentation link above
As to the permissions issue, read:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights_Of_Apache_User
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_Working_Directory
In short, ensure access permissions are correct of files/directories you need to access and ensure you are always using absolute path names when accessing the file system.
I am writing a simple web server with C++ that handles long-lived connections. However, I need to reload my web server from time to time. I wonder if there is a way that I can hand over the established connections from one process to another process to be able to retain my established connections after reload.
Would that be enough to only pass file descriptors? what would happen to connection states?
Any similar open source project that does the same thing?
Any thoughts or ideas?
Thanks,
I really have no idea whether this is possible, but I think not. If you fork() then the child will "inherit" the descriptors, but I don't know whether they behave like the should (though I suspect that they do.) And with forking, you can't run new code (can you?) Simple descriptor numbers are process-specific, so just passing them to a new, unrelated process won't work either, and they will be closed when your process terminates anyway.
One solution (in the absence of a simpler one,) is to break your server into two processes:
Front-end: A very simple process that just accepts the connections, keep them open and forwards any data it receives to the second process, and vice versa.
Server: The real web server, that does all the logic and processing, but does not communicate with the clients directly.
The first and second processes communicate via a simple protocol. One feature of this protocol must that it does support the second process being terminated and relaunched.
Now, you can reload the actual server process without losing the client connections (since they are handled by the front-end process.) And since this front-end is extremely simple and probably has very few configurations and bugs, you rarely need to reload it at all. (I'm assuming that you need to reload your server process because it runs into bugs that need to be fixed or you need to change configurations and stuff.)
Another important and helpful feature that this system can have is to be able to transition between server processes "gradually". That is, you already have a front-end and a server running, but you decide to reload the server. You launch another server process that connects to the front-end (while the old server is still running and connected,) and the front-end process forwards all the new client connections to the new server process (or even all the new requests coming from the existing client connections.) And when the old server finishes processing all the requests that it has under processing, it gracefully and cleanly exits.
As I said, this is a solution you might to try only if nothing easier and simpler is found.
I have an application that sends requests to an out of proc COM server whom handles the requests and sends them back to the requesting application.
The client application is really in control of the start-stop of this Out-of-Proc COM server and determines its lifetime so to say.
Because this application has many hundreds of requests at any given time, it mostly has at least 4 of the same COM servers to handle these requests.
The problem is that sometimes this COM servers gets hung up handling a request, which is caught by the requesting application, whom kills the out of proc COM server. This however does not always happen.
What sometimes happens is that the client application requests a COM server kill, which results in the client releasing all references to the COM Server, but the COM server ends up just using 25% of the CPU and just never dies. It seems it just hangs and uses CPU constantly.
The client has mechanism to attempt to kill the COM Server process forcibly if it fails to die, however even that does not seem to work in the cases where the COM server gets into the CPU usage and just hangs.
Has anybody experienced something similar or has some advice on how one could resolve a situation like this?
You need to design all calls in the COM server in such way that they all end in some reasonably short time. Once a new call arrives from the client COM spawns a separate thread and dispatches a call onto that thread. There's no reliable way to interrupt the call - the call needs to end on itself (just return). You achieve this by designing your algorithm appropriately.