|
From: Mike D. <md...@sp...> - 2015-01-10 16:33:47
|
That approach sounds right to me. Use the handler to just spawn off your long-running job, cache the parameters in the job (in particular keeping the tcp conn pointer alive will keep the connection open), and return right away. Then when the job is finished, use response_writer to schedule an async response to the request.
-Mike
From: Rohan Shetty <she...@ya...<mailto:she...@ya...>>
Reply-To: Rohan Shetty <she...@ya...<mailto:she...@ya...>>
Date: Friday, January 9, 2015 at 9:40 PM
To: Microsoft Office User <md...@sp...<mailto:md...@sp...>>, "pio...@li...<mailto:pio...@li...>" <pio...@li...<mailto:pio...@li...>>
Subject: Re: [pion-users] How to increase the the "concurrent processing threads" in pion - Handle leak
Hi Mike,
Thanks for the detailed response.
In my case, I have a blocking handler. I guess every blocking handler consumes a thread. Please correct if my understanding is not right. I would appreciate if you suggest a solution(or a work around).
e.g. would the following work?
- In the handler, I would store the variables (PtrHttpRequest, PtrTcpConn). And without sending the response, I would return from the handler.
- I will use a thread, which would make use of the above variables(PtrHttpRequest, PtrTcpConn), and send the response.
Would the above approach consume a pion thread?
Any help is appreciated.
Regards,
Rohan
________________________________
From: Mike Dickey <md...@sp...<mailto:md...@sp...>>
To: Rohan Shetty <she...@ya...<mailto:she...@ya...>>; "pio...@li...<mailto:pio...@li...>" <pio...@li...<mailto:pio...@li...>>
Sent: Friday, January 9, 2015 10:37 PM
Subject: Re: [pion-users] How to increase the the "concurrent processing threads" in pion - Handle leak
Pion is asynchronous, so 8 threads should be able to handle many thousands of concurrent connections. Unless you have some sort of blocking code in your handler, there is probably no reason to increase it beyond the number of physical cores (8 threads should fully utilize 8 physical cores).
From: Rohan Shetty <she...@ya...<mailto:she...@ya...>>
Reply-To: Rohan Shetty <she...@ya...<mailto:she...@ya...>>
Date: Thursday, January 8, 2015 at 9:30 PM
To: "pio...@li...<mailto:pio...@li...>" <pio...@li...<mailto:pio...@li...>>
Subject: [pion-users] How to increase the the "concurrent processing threads" in pion - Handle leak
Hi,
I use the following code, which is working fine
pion::http::server_ptrm_HttpServer;
unsigned int m_iPort = 0
//Listen only in the loopback interface
boost::asio::ip::address addr(boost::asio::ip::address_v4::loopback());
// If port =0, then the HttpServer would take a free available port
boost::asio::ip::tcp::endpoint endpoint(addr, m_iPort);
// Create a web server and specify the port on which it will listen.
m_HttpServer = pion::http::server_ptr(new pion::http::server(endpoint));
m_HttpServer->start();
Following is the handler used for testing this.
void CPalHttpServer::RequestHandlerForPalRoot(constrequest_ptr & PtrHttpRequest,
connection_ptr & PtrTcpConn)
{
string HELLO_HTML = "<html><body>PAL Service!</body></html>";
response_writer_ptr writer(response_writer::create(PtrTcpConn, * PtrHttpRequest,
boost::bind(&connection::finish, PtrTcpConn)));
writer->write(HELLO_HTML);
writer->send()
}
By default PION supports around 8 threads, which will limit only 8 concurrent HTTP requests.
I tried the following code, in which I have tried to increasing the thread to 100. Is this the right ?
pion::http::server_ptrm_HttpServer;
pion::single_service_scheduler m_DefaultScheduler;
m_DefaultScheduler.set_num_threads(100);
unsigned int m_iPort = 0
//Listen only in the loopback interface
boost::asio::ip::address addr(boost::asio::ip::address_v4::loopback());
// If port =0, then the HttpServer would take a free available port
boost::asio::ip::tcp::endpoint endpoint(addr, m_iPort);
// Create a web server and specify the port on which it will listen.
m_HttpServer = pion::http::server_ptr(new pion::http::server(m_DefaultScheduler, endpoint));
m_HttpServer->start();
Problem: There is couple of handle leaks for every http request processing.
i.e when client sends the http request, I could see couple of handle leaks.
Any help is appreciated
Regards,
Rohan
|