-
Notifications
You must be signed in to change notification settings - Fork 701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detecting if a client is still connected while processing a request #1249
Comments
It may not be a very natural thing, at least at the low level.
The low level is processing an event loop (either e-poll or libevent). If
there is incoming traffic, it triggers the waiting event loop to exit and
then the Pistache code services the activated event(s).
Once the activated events have been serviced, the event loop is called
again for the next events, and that’s when you would see the disconnect in
your scenario (though you may also see Send fail meanwhile due to
disconnect, as you said).
Now, we could potentially have a second event loop in a second thread,
which could be triggered by a disconnect while the first thread is busy
processing the incoming traffic.
But today Pistache never has an event being monitored in multiple loops at
the same time, so it might require some surgery.
Can you say more about the exact situation you’re solving for - what
Pistache APIs is it using, what is it trying to do, why would the early
termination of the traffic processing be helpful?
…On Thu, Oct 10, 2024 at 4:52 AM jacky309 ***@***.***> wrote:
While processing a request, is it possible to be somehow notified if the
client connection has been closed, in order to stop the processing earlier,
if we are not going to be able to send the response anyway ?
—
Reply to this email directly, view it on GitHub
<#1249>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFMA232RVIZ722CCAXZPQDZ2ZTADAVCNFSM6AAAAABPWTLRYGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU3TQNRSGA3TQMY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
NOTICE: This email and its attachments may contain privileged and
confidential information, only for the viewing and use of the intended
recipient. If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution, acting upon, or use of the
information contained in this email and its attachments is strictly
prohibited and that this email and its attachments must be immediately
returned to the sender and deleted from your system. If you received this
email erroneously, please notify the sender immediately. Xage Security,
Inc. and its affiliates will never request personal information (e.g.,
passwords, Social Security numbers) via email. Report suspicious emails to
***@***.*** ***@***.***>
|
The early termination would be useful to avoid "consuming" one server thread for a client which is already disconnected anyway, since the way the request is currently processed is basically via a while loop inside our request handler, which does not end until the client has disconnected. We have been able to implement that mechanism with a patched version of Pistache, but we would like to get rid of that patch now. |
@jacky309, you might want to look at Pistache's support for streaming a continuous response to the client. I've never used it personally, but it might solve your problem. I don't know how it handles the socket being closed by the client, but whoever wrote that code probably already contemplated that scenario. |
@kip, good idea.
@jacky309, using a second thread at the application level (your level)
might be possible. If you're able, perhaps you could share the key code
fragments in your application, together with your patch of Pistache that
enabled the two-thread approach?
…On Fri, Oct 11, 2024 at 2:02 PM Kip ***@***.***> wrote:
@jacky309 <https://github.com/jacky309>, you might want to look at
Pistache's support for streaming a continuous response to the client. I've
never used it personally, but it might solve your problem. I don't know how
it handles the socket being closed by the client.
—
Reply to this email directly, view it on GitHub
<#1249 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFMA236FCFI6K53HXGD2P3Z3A4FXAVCNFSM6AAAAABPWTLRYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGEYTMNBTG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
NOTICE: This email and its attachments may contain privileged and
confidential information, only for the viewing and use of the intended
recipient. If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution, acting upon, or use of the
information contained in this email and its attachments is strictly
prohibited and that this email and its attachments must be immediately
returned to the sender and deleted from your system. If you received this
email erroneously, please notify the sender immediately. Xage Security,
Inc. and its affiliates will never request personal information (e.g.,
passwords, Social Security numbers) via email. Report suspicious emails to
***@***.*** ***@***.***>
|
While processing a request, is it possible to be somehow notified (even with some polling) if the client connection has been closed, in order to stop the processing earlier, if we are not going to be able to send the response anyway ?
The text was updated successfully, but these errors were encountered: