The scenario is how InputReaderThread communicates to b2g(main) thread.
Is XPCOM needed in this scenario? Be more specific, will these threads communicate to each other through pipe? shared memory or socket?
I dont find any document discusses this topic yet, please let me know if there is any available on the site.
Related
I have a Multi-Client Single-Server application where client and server gets connected through sockets. Client and Server are in different machine.
In client Application, client socket gets connected to server and sends data periodically to server.
In server application server socket listens for client to connect. When a client is connected, new thread is created for client to receive data.
for example: 1 client = 1 thread created by server for receiving data. If its 10000 client, server creates 10000 threads. This seems not good and scalable too.
My Application is in Java.
Is there an alternate method for this problem?
Thanks in advance
This is a typical C10K problem. There are patterns to solve this, one examples is Reactor pattern
Java NIO is another way where the incoming request can be processed in non blocking way. See a reference implementation here
Yes, you should not need a separate thread for each client. There's a good tutorial here that explains how to use await to handle asynchronous socket communication. Once you receive data over the socket you can use a fixed number of threads. The tutorial also covers techniques to handle thousands of simultaneous communications.
Unfortunately given the complexity it's not possible to post the code here, so although link-only answers are frowned upon ...
I would say it's a perfect candidate for an Erlang/Elixir application. Whatsapp, RabbitMQ...
Erlang processes are cheap and fast to start, Erlang manages the scheduling for you so you don't have to think about the number of threads, CPUs or even machines, Erlang manages garbage collection for each process after you don't need it anymore.
Haskell is slow, Erlang is fast enough for most applications that are not doing heavy calculations and even then you can use it and hand off the heavy lifting to a C process.
What are you writing in?
Yes, you can use the Actor model, with e.g. Akka or Akka.net. This allows you to create millions of actors that run on e.g. 4 threads. Erlang is a programming language that implements the actor model natively.
However, actors and non-blocking code won't do you much good if you are relying on blocking library calls for backend services that you rely on, such as (the most prominent example in the JVM world) JDBC calls.
There is also a rather interesting approach that Haskell uses, called green threads. It means that the runtime threads are very lightweight and are dynamically mapped to OS threads. It also means that you get a certain amount of scalability "for free", with no need to write non-blocking IO code. It does however require a good IO manager in the runtime to schedule the IO operations efficiently, and GHC Haskell has had a substantial amount of work put into that in recent years.
I want to write a android system server for socket can. Im currently designing this and wondered if there is any way to get informed if data on a Linux/POSIX socket is available without calling read() and poll the result any time.
Yes, there are several ways to do this, among them i/o multiplexing, signal-drive i/o, and asynchronous i/o.
It's likely that for your purposes multiplexing will suffice and it is by far the easiest to implement and get right. Investigate select, poll or epoll There are an abundance of articles, references, and examples available and no shortage of questions/answers here to help you get started. Most common programming languages have a mechanism to expose these services.
I am confused if we should make our own threads in servlet or not,as they have threading mechanism
internally?. If yes how can we make sure if the program thread safe? How to implement thread safe mechanism in servlets.
You are asking two different questions:
I am confused if we should make our own threads in servlet or not,as
they have threading mechanism internally?.
Normally, you should not start threads in a Java EE application. If you need seperate threads, make sure you use a Scheduler Service that your application knows about, so that it has the chance to shut down the threads when the application is shut down. Quartz is what's used most of the time.
If yes how can we make sure if the program thread safe? How to
implement thread safe mechanism in servlets.
Servlets are just like any other Java class. Find a tutorial on thread safety or read Java Concurrency in Practice.
From what you write in the comment, I understand that you have a set of threads continuusly monitoring log-files and sending email if something interresting is found in the log.
First question: why is this a servlet? Is there a web-gui? What is this used for?
For the log-scanning part, I would have implemented that as a separate process outside of the servlet-container. For everything this process found which it needs to send somewhere, I would add a message to a JMS-queue. Then I would create a messagedriven bean to recieve messages from this queue and send them as email. (This is really an integration problem, transforming messages from JMS to email, you might want to look into something like Mule to solve this).
As for how to integrate this with your servlet, it depends on what your servlet does in addition to scanning logs (I suppose it presents the user with some kind of interface)
With this design, you can chose to re-write the programs generating the log in the future. Instead of having one program writing log and another program parsing the log, the first program might as well put the interresting message directly on the JMS-queue. In other words, you can change the log-generation part of your architecture in the future, without having to re-write the mail-sending part.
I also had a similar concern.
Only EJB specification disallows the creation of threads from the application.
It is ok to start a thread from a servlet.
I have done it many times with no problems but to be honest I am not 100% sure:
that this is allowed by container but is violating a standard
or
it is allowed by all containers.
But in Tomcat I never had an issue starting threads from a servlet.
You can make it thread safe the same way you do in every multithreading program.
You will use all the available constructs offered by Java for synchronization.
I'm trying to learn the lock/mutex stuff using boost library, but all that I found from the internet is too abstract or complicated.
Would you guys recommend me some tutorials, which are easy to understand? Thanks.
I'm working on a project. Server-Client architecture.
The server can receive messages from the client or send messages to client. The server can also send messages using multiple threads.
I believe that I have to do thread synchronization to handle multiple threads for sending messages via the same connection, right?
Can you guys give me a simple pseudo code snippet?
Skip mutexes and threads, read about Boost.Asio if you are designing a client server architecture. Particularly, study the asynchronous design that it promotes with concurrency without the explicit use of threads.
I am looking for any strategies people use when implementing server applications that service client TCP (or UDP) requests: design patterns, implementation techniques, best practices, etc.
Let's assume for the purposes of this question that the requests are relatively long-lived (several minutes) and that the traffic is time sensitive, so no delays are acceptable in responding to messages. Also, we are both servicing requests from clients and making our own connections to other servers.
My platform is .NET, but since the underlying technology is the same regardless of platform, I'm interested to see answers for any language.
The modern approach is to make use of the operating system to multiplex many network sockets for you, freeing your application to only processing active connections with traffic.
Whenever you open a socket it's associated it with a selector. You use a single thread to poll that selector. Whenever data arrives, the selector will indicate the socket which is active, you hand off that operation to a child thread and continue polling.
This way you only need a thread for each concurrent operation. Sockets which are open but idle will not tie up a thread.
Using the select() and poll() methods
Building Highly Scalable Servers with Java NIO
A more sophosticated aproach would be to use IO Completion ports. (Windows)
With IO Completion ports you leave to the operating system to manage polling, which lets it potentially use very high level of optimization with NIC driver support.
Basically, you have a queue of network operations which is OS managed, and provide a callback function which is called when the operation completes. A bit like (Hard-drive) DMA but for network.
Len Holgate wrote an eccelent series on IO completion ports a few years ago on Codeproject:
http://www.codeproject.com/KB/IP/jbsocketserver2.aspx
And
I found an article on IO completion ports for .net (haven't read it though)
http://www.codeproject.com/KB/cs/managediocp.aspx
I would also say that it is easy to use completion ports compared to try and write a scaleable alternative. The problem is that they are only available on NT (2000, XP, Vista)
If you were using C++ and the Win32 directly then I'd suggest that you read up about overlapped I/O and I/O Completion ports. I have a free C++, IOCP, client/server framework with complete source code, see here for more details.
Since you're using .Net you should be looking at using the asynchronous socket methods so that you don't need have a thread for every connection; there are several links from this blog posting of mine that may be useful starting points: http://www.lenholgate.com/blog/2005/07/disappointing-net-sockets-article-in-msdn-magazine-this-month.html (some of the best links are in the comments to the original posting!)
G'day,
I'd start by looking at the metaphor you want to use for your thread framework.
Maybe "leader follower" where a thread is listening for incoming requests and when a new request comes in it does the work and the next thread in the pool starts listening for incoming requests.
Or thread pool where the same thread is always listening for incoming requests and then passing the requests over to the next available thread in the thread pool.
You might like to visit the Reactor section of the Ace Components to get some ideas.
HTH.
cheers,
Rob