On Sun, 2022-09-25 at 05:27 +0000, Isaac Cruz wrote: > Sorry, I did not explain well, let me elaborate. > > On 4.x I was extending HttpAsyncService to override closed() method, > and as the parameter was a NHttpServerConnection object I could > obtain metrics from it. > > On 5.x the most similar method I found was setIOSessionListener, but > the disconnected callback receive an IOSession parameter, and there > is no metrics there. So I have not found yet an easy way of getting > metrics on this version. > > Thanks, > Isaac >
I am sorry I am not sure I understand the problem. I am not sure what stops you from reading sent / received bytes data from EndpointDetails Oleg. > -----Original Message----- > From: Oleg Kalnichevski <[email protected]> > Sent: sábado, 24 de septiembre de 2022 11:00 > To: HttpComponents Project <[email protected]> > Subject: Re: HttpCore 5.1.4: Get stats of sent/rcvd bytes > > On Fri, 2022-09-23 at 10:31 +0000, Isaac Cruz wrote: > > Hi, > > > > I want to get statistics of sent and received bytes from an HTTP > > server. I had a working implementation on HttpCore 4.x using > > NHttpServerConnection.getMetrics() that were added up on closing > > connection. Then I migrated to HttpCore 5.1.x and that API > > disappeared, > > Why disappeared? Connection and transport metrics are still > accessible through the execution context. What is wrong with using > HttpConnectionMetrics or EndpointDetails? > > > > so what I am using is AsyncServerBootstrap.setIOSessionDecorator() > > to > > set a custom class that will count bytes on read() and write() > > methods. This works perfectly fine when using plain connections, > > but > > when using HTTPS, read bytes won't work. When receiving an HTTP > > request (just before consumeRequest() is called), read() method is > > called, but returns 0 bytes. But then there are no more calls, even > > though I receive the calls to consume() with the received packets. > > > > What I would expect is that the IOSession decorated would be the > > lowest layer, on encrypted socket, but it looks like it decorates a > > higher level IOSession, on inPlain (so it does not count handshake > > data), and additionally it is not being called for received data. > > > > Is there any other way of getting those metrics? > > > > IOSessionDecorator was initially intended for injecting i/o session > level logging at in order to avoid direct dependency on any logging > framework. What one usually wants to see in the logs is plain data in > a human readable form and not raw TLS data. For that reason the i/o > session events are intercepted at the entry to the protocol layer > post- TLS, and not pre-TLS. I do not think we should change that. > > I hope this helps. > > If still want to introduce an interception point at the i/o channel > level, we can discuss it but do hope it is not going to be necessary. > > Cheers > > Oleg > > > Thanks and regards, > > Isaac > > > > Disclaimer > > > > The information contained in this communication from the sender is > > confidential. It is intended solely for use by the recipient and > > others authorized to receive it. If you are not the recipient, you > > are > > hereby notified that any disclosure, copying, distribution or > > taking > > action in relation of the contents of this information is strictly > > prohibited and may be unlawful. > > > > This email has been scanned for viruses and malware, and may have > > been > > automatically archived by Mimecast, a leader in email security and > > cyber resilience. Mimecast integrates email defenses with brand > > protection, security awareness training, web security, compliance > > and > > other essential capabilities. Mimecast helps protect large and > > small > > organizations from malicious activity, human error and technology > > failure; and to lead the movement toward building a more resilient > > world. To find out more, visit our website. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] > > Disclaimer > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and > others authorized to receive it. If you are not the recipient, you > are hereby notified that any disclosure, copying, distribution or > taking action in relation of the contents of this information is > strictly prohibited and may be unlawful. > > This email has been scanned for viruses and malware, and may have > been automatically archived by Mimecast, a leader in email security > and cyber resilience. Mimecast integrates email defenses with brand > protection, security awareness training, web security, compliance and > other essential capabilities. Mimecast helps protect large and small > organizations from malicious activity, human error and technology > failure; and to lead the movement toward building a more resilient > world. To find out more, visit our website. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
