I am integrating lambda(Python) with RDS proxy, and for some of the examples on the web, I can see people initiating the connection outside the handler, and never closing it.
On the other hand, I have seen examples on which people initiate the connection within the handler.
So, what is the best practice? I assume if you go for the first approach, the idle client connection timeout(RDS proxy) should be short, otherwise you can surpass the connection limit.
If we create the connection outside handler then the same connection can be used for warm starts which is good have if idle timeout is set appropriately.
If the connection is set inside handler then it'll have an overhead of creating and closing connections for each invocations.
Related
How connect to https://api.push.apple.com using http2 with persistent connection ?
Persistent connection is to avoid rapid connection and disconnection:
APNs treats rapid connection and disconnection as a denial-of-service attack
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/APNsProviderAPI.html
Is writing a client in c using https://nghttp2.org the only solution?
(If that question should be ask in another StackExchange website, please do tell me)
Non-persistent connections are a relic of the past. They were used in HTTP/1.0, but HTTP/1.1 already moved to a model where the connections were persistent by default, and HTTP/2 (also being multiplexed) continues on that model of connections being persistent by default.
Independently on the language you are using to develop your applications, any HTTP/2 compliant client will, by default, use persistent connections.
You only need to use the HTTP/2 client library in a way that you don't explicitly close the connection after every request you make.
Typically these libraries employ a connection pool that keeps the connections open, typically until an idle timeout fires.
When your application makes HTTP requests, the library will pick an open connection and send the request. When the response arrives the library will not close the connection but instead put it back into the pool for the next usage.
Just study how the library you want to use allows you to make multiple requests without closing the connection.
I also met this question!
If the connection be idle for a long time (about 1 hour), then function poll catches no socket status changed. It always returns 0 even as on_frame_send_callback was invoked.
Is there anyone can figure out the problem?
I am creating a MS Windows service, which listens for TCP connections. When connected, it gets data from a SQL db and returns it via the TCP socket. What are the drawbacks, if any, of opening a SqlConnection to the SQL Server at service start time, and just re-using that, until it might fail, as opposed to opening a new connection each time a "request" is made? I expect a small number of instantiations of the service functionality - less than 10 a day, but it could be more than that.
Database connections are considered an "expensive" resource, and as such should be opened only when needed, and closed immediately thereafter. As a result, opening a connection early and persisting it would go against that philosophy. Additionally, doing so prevents your underlying framework from making best use of whatever variety of connection pooling it may implement. It just isn't a very scalable practice.
I'm using org.eclipse.jetty.websocketclient and I want to open multiple web sockets to different URLs.
I'm working with Java.
How do I need to do that?
I want to open the web sockets in multiple threads.
1. Do I need to create websocketclient for each connection?
2. Can I use any websocketclient factory? Is there any?
3. Do I need to open only one websocketclient, keep it opened and open somehow web sockets with it?
4. What is wrong with creating multiple websocket clients?
This answer talks about Jetty 9 WebSockets.
you have 1 WebSocketClient, think of it as a Browser, with each call to connect() establishing a new connection.
Each call to connect() should have a new WebSocket instance, each instance will be managed by the WebSocketClient's Executor causing in essence each websocket instance to be on its own thread.
Followup Answers
Ideally, have only 1 WebSocketClient, and start it only once. leave it started for the time period where you have active websocket connections.
Stop the WebSocketClient when there are no more connections.
Generally speaking, avoid reusing objects for multiple requests, unless you know what you are doing. Example: the ClientUpgradeRequest and URI, are associated with the WebSocket Session, which if reused across multiple connections, will have a state change on close of the first connection, making the data invalid for the other connections, then there is also the Garbage collection references that make cleaning up the old connections difficult until all connections are closed.
You can call connect() concurrently, go for it. Each connection attempt is processed based on the Executor behavior (eg: if you have a single threaded Executor, then only 1 connect occurs at a time)
Creating a new WebSocketClient for every connect is excessively wasteful of resources. It would be like starting an entire WebServer for each incoming request. A WebSocketClient manages the selectors, threading, session tracking, etc. I realize where you are coming from, with older http client libraries having this behavior, but even those http clients are updating themselves to this new browser-ish model thanks to spdy and http/2.
Communicate with the database in java, we often follow these steps:
load a driver
get a connection
create a Statement or PreparedStatement
get the ResultSet
close the connection
I am confused that we should close connection, all say that create a connection is expensive, so why we can't do like this:
static
{
try
{
connection = DriverManager.getConnection(connectorURL,
user, password);
} catch (SQLException e)
{
e.printStackTrace();
}
}
We just create a connection as a singleton, and use it everywhere. Couldn't it? If I use it like this, what will happen?
And if I don't close the connection, what will happen?
Also, we will use a connection pool, it will create some connections in the pool, and we get the connection from the pool, the connection in the pool also don't close, why if we don't use pool, we need follow the steps and close the connection if we don't use?
It's so confused and I don't know the what's the principle. Please help me. Thanks.
If we don't close the connection, it will lead to connection memory leakage. Until application server/web server is shut down, connection will remain active, even if the user logs out.
There are additional reasons. Suppose database server has 10 connections available and 10 clients request for the connection. If the database sever grants all of them, and after their usage they are not closed, the database server would not be able to provide any other connection for another request. For that reason we need to close them - it is mandatory.
Furthermore, it might lead to some mischievous activities regarding the integrity of the database.
We just create a connection as a singleton, and use it everywhere. Couldn't it? If I use it like this, what will happen?
In this case, you will have only a single database connection. If database query is having a longer execution time, then other requests for that connection object will have to wait. So, this is not a recommended approach.
And if I don't close the connection, what will happen?
By closing the connection, objects of Statement and ResultSet will be closed automatically. The close() method is used to close the connection. If you forget to do so, it will lead your app to connection memory leak. For Example: Imagine that your app has 10 database connections and 10 users are active at the same time. Later on, 3 users log out of the app, but because you didn't implement connection closing mechanism, those 3 connections remain active, and as a result, your app will not provide any other connection to some other user. Also, increased number of opened connections, in database server, slows down the app. So, release the Connection object's database and JDBC resources immediately, instead of waiting for them to be automatically released.
Also, we will use a connection pool, it will create some connections in the pool, and we get the connection from the pool, the connection in the pool also don't close, why if we don't use pool, we need follow the steps and close the connection if we don't use?
Connection pooling means that connections are reused rather than created each time a connection is requested.
This source says, that: "If the system provides connection pooling, the lookup returns a connection from the pool if one is available. If the system does not provide connection pooling or if there are no available connections in the pool, the lookup creates a new connection. The application benefits from connection reuse without requiring any code changes. Reused connections from the pool behave the same way as newly created physical connections. The application makes a connection to the database and data access works in the usual way. When the application has finished its work with the connection, the application explicitly closes the connection.
The closing event on a pooled connection signals the pooling module to place the connection back in the connection pool for future reuse."
Your application borrows a connection from the pool, uses it, then returns it to the pool by closing it. A connection in the free pool for a long period of time is not considered an issue.
I can't find any information which specify the timeout for building the connection with a WebSocket server. This means, how long can the state "CONNECTING" be active before it changes to "CLOSED"? When the target host doesn't exist the state changes almost immediately, this is easy to find out. But what happens if the DNS lookup takes longer or the server is busy?
The same question arises for the "CLOSING" state when the connection goes through the closing handshake procedure. If the connection fails here, how long does it take until onClose() is called?
Are these two timeouts browser specific? If so, does anyone know any concrete numbers?