A thread was stuck reading tdengine, resulting in more than 200 threads that were all waiting for this thread, and now the entire service is inaccessible
Is there any way to check the problem?
Related
My design is as follows：
Make the receiving socket non-blocking.
Set epoll_wait to timeout 0.
Loop in the main thread to receive clients and judge epoll_wait. If an event occurs, create a thread to process I/O operation。
I think this scheme has disadvantages:
Too many threads are opened. Although it can be managed by a thread pool, it seems that a large number of threads need to be opened to handle concurrency.
Use queues to manage read and write tasks, Only a small number of threads are required to process queued tasks. But this may cause server delays.
I have an idea:
The task is handed over to the linux kernel through aio_read and aio_write. This seems to reduce the number of server threads, but I'm not sure if this is potentially risky.
My unused knowledge:
No multi-process programming is used in the server.
Thanks to everyone who suggested.
I have a client-server model. A multithreaded client sends a message to the server over the TCP sockets. The server is also multiple threaded with each request handled by a thread from the worker pool.
Now, the server must send back the message to the client via shared-memory IPC. For example:
multi threaded client --- GET /a.png --> server
|
|
one worker
|
|
\ /
puts the file descriptor into the shared memory
When worker thread adds the information into the shared memory, how do I make sure that it is read by the same client that requested it?
I feel clueless here as to how to proceed. Currently, I have created one segment of shared memory and there are 20 threads on the server and 10 threads on the client.
While you can use IPC between threads, it's generally not a good idea. Threads share all memory anyway since they are part of the same process and there are very efficient mechanisms for communications between threads.
It might just be easier to have the same thread handle a request all the way through. That way, you don't have to hand off a request from thread to thread. However, if you have a pool of requests that are being worked on, it often makes sense to have a thread be able to "put down" a request and then later be able to have that thread or a different thread "pick up" the request.
The easiest way to do this is to make all the information related to the request live in a single structure or object. Use standard thread synchronization tools (like mutexes) to control finding the object, taking ownership of it, and so on.
So when an I/O thread receives a request, it creates a new request object, acquires a mutex, and adds it to the global collection of requests the server is working on. Worker threads can check this global collection to see which requests need work or they can be explicitly dispatched by the thread that created the request.
I'm trying to use Windows Thread Pool API as pat of my C program. In my scenario, I want to send many tasks to the thread pool, and wait until all tasks are finished, and there are no more pending tasks. After all tasks finished I want to close the thread pool and continue execution of my program.
I believe the way to achieve it is using the wait objects described in the link above, but I can't really figure out what is the right way to do that. Does anyone understand if it's possible and what is the right way to do that?
I am reading a journal, it stated
Lighttpd is asynchronous server, and Apache2 is a process-based
server.
What does this actually mean?
Which server will you recommend for RasPi in purpose of monitoring purposes.
Thanks.
See this website for a detailed explanation.
In the traditional thread-based (Synchronous) models, for each client there is one thread which is completely separate and is dedicated to serve that thread. This might cause I/O blocking problems when process is waiting to get completed to release the resources (memory, CPU) in hold. Also,creating separate processes consumes more resources.
Asynchronous servers do not create a new process or thread for a new request. Here the worker process accepts the requests and process thousands of it with the implementation of highly efficient event loops.Asynchronous means that the threads can be executed concurrently with out blocking each other. It enhances the sharing of resources without being dedicated and blocked.
Picture the scenario, I have an ADAPTER written in C that writes messages to SAP (calling an RFC).
The adapter is only called when a new message arrives in the "engine", so can have periods of no activity for up to 1 day or more. This is where the problem come in, the connection handle becomes invalidated on the "low level socket" layer in STANDARD code /or by some SAP parameters on SAP itself that may say "kill handles that are no longer active "
So what I do now is SPAWN a thread that "sits on top of the adapter" and PINGS SAP every 10 seconds or so. The issue here is that I am using the SAME connection handle for sending messages to SAP as well as for the PING / HEARTBEAT message.
SAP says for the RFC handle:
"AN RFC handle can be used in several threads, but can only be active in one thread at a time. AN RFC handle of an RFC connection, created by one thread can be used in
another thread, but these threads have to synchronize the access to this handle."
But now I have tried using "pthread_mutex_lock" etc to make this work but it does not.
I have one GLOBAL "handle", and when my adapter SHARED LIB starts up I launch a thread like follows:
rc = pthread_create(&heartbeatThread, NULL, heartbeatThreadMainLoop, (void *)NULL);
And this thread just PINGS SAP every 10 or so seconds.
In a perfect world I would like the MESSAGING to SAP to take priority here, so the PING should totally wait until it is "quiet" and then start up again.
I have looked at links like:
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html#SYNCHRONIZATION
But I actually want to LOCK / UNLOCK a whole section of code, so as I said if the MESSAGE is going into SAP the PING thread must wait....BUt if the PING thread is busy I would like to somehow INTERRUPT it and say "hey, I need that connection handle for messaging"...
What is a best practice "pattern" for this?
And help would be hugely appreciated
Thanks
Lynton
The whole architecture can be simplified by increasing the scope of ADAPTER.
Instead of its main loop waiting for a request indefinitely, have it time out after 10 seconds. If it times out, do the wake up logic. In either case (request or timeout), reset the timer.
That avoids the whole problem of sharing, and makes ADAPTER responsible for all interaction with SAP.