A) If I have a java application which starts up and waits for socket connections on a specified port. Is there a way i could maintain a session connection in php after a user validates, i.e a persistent connection?
B) I mean, I'm trying to understand how its done with mysql and php. How does mysql or php know what the last opened connection was so you don't have to do mysql_connect after ?
C) Is there any benefit to opening and closing a connection on each page load or is it better to maintain a persistent connection?
D) If the latter is true in C, can you describe or give an example of how it would be achieved in a php --> Java connection
A) No, there isn't.
B) mysql_pconnect() works because of how the web server and php cooperates. The web server will typically launch a number of child processes which handles request. Each child process can only handle a single request at a time, and concurrency is achieved by sending concurrent requests to different processes.
Each such process has its own instance of PHP, which is reused for each new request. This allows PHP modules to maintain some state between requests. You cannot do this from regular PHP code, it has to be an extension written in C. There's no guarantees about this, though. A process can be killed and relaunched at any time.
Sidenote: Of course, not all web servers uses processes like this. It's rather common to use a threaded approach instead. This doesn't work on PHP, though, since not all extensions are thread safe. Therefore PHP always has to run on a web server that creates child processes to handle requests. This mode (MPM) is called prefork on Apache.
C) As I said, you don't have the choice. On a fast network, the overhead for opening a new connection is quite small, though.
Related
I've been looking into making a simple Sockets-based game in Java, and read in multiple places that client sockets are destroyed after a single exchange. Is this good practice for continued connections? The server needs to maintain a connection with a client (i.e. not using socket.accept() every time it wants to tell a client about something), but can't wait every time for the client's response. I already have the server/client running in separate threads, but won't destroying the socket after every exchange mean re-acquiring (or failing to re-acquire) a connection to that client? I've seen so many conflicting websites about sockets in Java and how they should be implemented.
There's no hard and fast rules, but it does depend slightly on what data rates you want to achieve.
For example, YouTube is a streaming video service, but the video data is delivered by means of the client using https to fetch batches of video data. Inefficient, yes, but very easy to program for. There's lots of reasons to use https for an application like YouTube (firewalls, etc), but ultimate power saving and network performance were not one of them. The "proper" way would be to use a protocol like RTP which uses UDP to deliver small packets of data which can then be rearranged into order, you also have to deal with missing frames at the CODEC level, etc. Much less network traffic, friendly to bandwidth constrained network links, but significantly more difficult to deal with traversing across firewalls, in client software, etc.
So if your game is sending modest amounts of data, the only thing wrong with setting up and tearing down a whole socket connection for every message is the nagging feeling you yourself will have that it is somehow not the most efficient solution.
Though it sounds like you have a conflict between the need to communicate between client / server and a need to process something else whilst waiting for the communication to complete. Here you're getting into asynchronous I/O territory. To make that easy i strongly suggest you take a look at ZeroMQ - that will make everything a whole lot simpler.
and read in multiple places that client sockets are destroyed after a single exchange.
Only in the places where that actually happens. There are numerous contexts where it doesn't, the outstanding example being HTTP, where every effort is made to reuse connections.
Is this good practice for continued connections?
The question is a contradiction in terms. A continued connection is a connection that isn't closed. A closed connection can't be continued.
The server needs to maintain a connection with a client (i.e. not using socket.accept() every time it wants to tell a client about something), but can't wait every time for the client's response.
The word you are groping for here is 'session'.
I already have the server/client running in separate threads, but won't destroying the socket after every exchange mean re-acquiring (or failing to re-acquire) a connection to that client?
Yes.
I've seen so many conflicting websites about sockets in Java and how they should be implemented.
You should use a connection pool at the client; a request loop at the server that looks for multiple requests per connection; a client-side facility that closes idle connections after some idle timeout; and a read timeout at the server that closes connections on which no request has been read within the timeout.
I am using Elasticsearch 1.5.1 and Tomcat 7. Web application creates a TCP client instance as Singleton during server startup through Spring Framework.
Just noticed that I failed to close the client during server shutdown.
Through analysis on various tools like VisualVm, JConsole, MAT in Eclipse, it is evident that threads created by the elasticsearch client are live even after server(tomcat) shutdown.
Note: after introducing client.close() via Context Listener destroy methods, the threads are killed gracefully.
But my query here is,
how to check the memory occupied by these live threads?
Memory leak impact due to this thread?
We have got few Out of memory:Perm gen errors in PROD. This might be a reason but still I would like to measure and provide stats for this.
Any suggestions/help please.
Typically clients run in a different process than the services they communicate with. For example, I can open a web page in a web browser, and then shutdown the webserver, and the client will remain open.
This has to do with the underlying design choices of TCP/IP. Glossing over the details, under most cases a client only detects it's server is gone during the next request to the server. (Again generally speaking) it does not continually poll the server to see if it is alive, nor does the server generally send a "please disconnect" message on shutting down.
The reason that clients don't generally poll servers is because it allows the server to handle more clients. With a polling approach, the server is limited by the number of clients running, but without a polling approach, it is limited by the number of clients actively communicating. This allows it to support more clients because many of the running clients aren't actively communicating.
The reason that servers typically don't send an "I'm shutting down" message is because many times the server goes down uncontrollably (power outage, operating system crash, fire, short circuit, etc) This means that an protocol which requires such a message will leave the clients in a corrupt state if the server goes down in an uncontrolled manner.
So losing a connection is really a function of a failed request to the server. The client will still typically be running until it makes the next attempt to do something.
Likewise, opening a connection to a server often does nothing most of the time too. To validate that you really have a working connection to a server, you must ask it for some data and get a reply. Most protocols do this automatically to simplify the logic; but, if you ever write your own service, if you don't ask for data from the server, even if the API says you have a good "connection", you might not. The API can report back a good "connections" when you have all the stuff configured on your machine successfully. To really know if it works 100% on the other machine, you need to ask for data (and get it).
Finally servers sometimes lose their clients, but because they don't waste bandwidth chattering with clients just to see if they are there, often the servers will put a "timeout" on the client connection. Basically if the server doesn't hear from the client in 10 minutes (or the configured value) then it closes the cached connection information for the client (recreating the connection information as necessary if the client comes back).
From your description it is not clear which of the scenarios you might be seeing, but hopefully this general knowledge will help you understand why after closing one side of a connection, the other side of a connection might still think it is open for a while.
There are ways to configure the network connection to report closures more immediately, but I would avoid using them, unless you are willing to lose a lot of your network bandwidth to keep-alive messages and don't want your servers to respond as quickly as they could.
I am in the process of building a client-server application and I would really like an advise on how to design the server-database connection part.
Let's say the basic idea is the following:
Client authenticates himself on the server.
Client sends a request to server.
Server stores client's request to the local database.
In terms of Java Objects we have
Client Object
Server Object
Database Object
So when a client connects to the server a session is created between them through which all the data is exchanged. Now what bothers me is whether i should create a database object/connection for each client session or whether I should create one database object that will handle all requests.
Thus the two concepts are
Create one database object that handles all client requests
For each client-server session create a database object that is used exclusively for the client.
Going with option 1, I guess that all methods should become synchronized in order to avoid one client thread not overwriting the variables of the other. However, making it synchronize it will be time consuming in the case of a lot of concurrent requests as each request will be placed in queue until the one running is completed.
Going with option 2, seems a more appropriate solution but creating a database object for every client-server session is a memory consuming task, plus creating a database connection for each client could lead to a problem again when the number of concurrent connected users is big.
These are just my thoughts, so please add any comments that it may help on the decision.
Thank you
Option 3: use a connection pool. Every time you want to connect to the database, you get a connection from the pool. When you're done with it, you close the connection to give it back to the pool.
That way, you can
have several clients accessing the database concurrently (your option 1 doesn't allow that)
have a reasonable number of connections opened and avoid bringing the database to its knees or run out of available connections (your option 2 doesn't allow that)
avoid opening new database connections all the time (your option 2 doesn't allow that). Opening a connection is a costly operation.
Basically all server apps use this strategy. All Java EE servers come with a connection pool. You can also use it in Java SE applications, by using a pool as a library (HikariCP, Tomcat connection pool, etc.)
I would suggested a third option, database connection pooling. This way you create a specified number of connections and give out the first available free connection as soon as it becomes available. This gives you the best of both worlds - there will almost always be free connections available quickly and you keep the number of connections the database at a reasonable level. There are plenty of the box java connection pooling solutions, so have a look online.
Just use connection pooling and go with option 2. There are quite a few - C3P0, BoneCP, DBCP. I prefer BoneCP.
Both are not good solutions.
Problem with Option 1:
You already stated the problems with synchronizing when there are multiple threads. But apart from that there are many other problems like transaction management (when are you going to commit your connection?), Security (all clients can see precommitted values).. just to state a few..
Problem with Option 2:
Two of the biggest problems with this are:
It takes a lot of time to create a new connection each and every time. So performance will become an issue.
Database connections are extremely expensive resources which should be used in limited numbers. If you start creating DB Connections for every client you will soon run out of them although most of the connections would not be actively used. You will also see your application performance drop.
The Connection Pooling Option
That is why almost all client-server applications go with the connection pooling solution. You have a set connections in the pool which are obtained and released appropriately. Almost all Java Frameworks have sophisticated connection pooling solutions.
If you are not using any JDBC framework (most use the Spring JDBC\Hibernate) read the following article:
http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html
If you are using any of the popular Java Frameworks like Spring, I would suggest you use Connection Pooling provided by the framework.
Along the last years i used Apache httpd server for my servers.
As i understand it - the biggest advantage in using Nginx is that Apache opens a different Thread for each HTTP request - which might load my server very quickly, while Nginx uses some other technique (Event driven) in order to take the maximum out of my server's memory and hardware.
So far so good.
I'm building a new web service which i expect to have lots of HTTP traffic so i've decided to use Nginx.
As a good Java programmer i like Java more than PHP but i have a concept problem using it in my case:
In all the post I've found that the way to use Java on it is to wrap the application with Nginx + Tomcat (or other JavaServer) + Java - so, if i understand correctly - i will not get the Nginx advantage since the Tomcat will open a new thread for each request in order to use the Java web service.
Questions:
Did i understand it correctly?
Does using Nginx with PHP does open a new process for each request but not a new thread ?
You understand it correctly. In this case, nginx plays as a reverse proxy, tomcat works as an application server. IN most of time, the bottleneck appeared in application level: application server of application itself.
PHP use process not thread to execute requests, each request needs a php-cgi process to deal with, only when this request finished, the process would be released to deal with other request. For php-fpm, it usually pre-fork many child processes, like a pool, and we need to calculate the size of this pool according to the real QPS and stat of machine.
Yes you got it correctly, what you're doing here is putting an extra layer above the tomcat, so you'll not get the advantage, the only advantage that you'll get is serving assets ( images and static files ) without passing them to the apache, which might give a slight advantage.
Why php is has this advantage: because when using nginx instead of running php as a module of apache (mod_php) we install a separate server php-fcgi or php-fpm, so it's independent of apache's method of spawning workers or threads or whatever.
Is there any way to hide the http requests a java application makes from wireshark or any other traffic monitoring processes on the machine?
possible to hide certain string data from being exposed via jvm monitor?
Is there any way to hide the http requests a java application makes from wireshark or any other traffic monitoring processes on the machine?
It depends. You can protect against simple packet sniffing by using SSL etc to secure the network connection; i.e. use HTTPS. However, if someone/something has maximum privileges on a typical machine, they can (in theory) get around any scheme you attempt to erect. For instance, they could get into the JVM and figure out what keys are being used to encrypt the SSL traffic.
Hiding the existence or the destination of the HTTP requests is impossible.
possible to hide certain string data from being exposed via jvm monitor?
If someone can attach a Java debugger to your JVM, then can (in theory) see any data that it contains and observe anything that it does. There's nothing you can do about that.
Reading between the lines, it seems like you are trying to implement some kind of secure communication channel between your server and a copy of your software running on a machine / platform that you can't trust. Put simply, this is theoretically impossible. You are better off looking for a scheme where it doesn't matter if someone can see the network traffic. (It is hard to advise without knowing what it is you are trying to do.)
If you use https instead of http it cannot be eavesdropped.