Squid 3.5 with nonblocking ecap adapter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Squid 3.5 with nonblocking ecap adapter

Christof Gerber
Hi everyone

I am working on an ecap adapter which attaches to Squid 3.5. The
adapter is going to make an external socket call which results in an
REST API call (lookup)  which will cause a delay of some milliseconds
until the response is available. As ecap is blocking I assume Squid
will be blocked during this period of time which is not desirable from
a performance point of view. Is my assumption right that squid will be
blocked until the eCAP API call returns? Is there a way other than
programming the eCAP adapter in asynchronous mode?

Thanks for your help.
Best
Christof

--
Christof Gerber
Email: [hidden email]
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 3.5 with nonblocking ecap adapter

Alex Rousskov
On 11/01/2017 03:20 AM, Christof Gerber wrote:

> [Will Squid] be blocked until the eCAP API call returns?

To answer the exact question above: Yes, the Squid worker making an eCAP
API call will block until that call returns. The same is true for all
other API calls, all system calls, and all internal calls. This is how
C/C++ works. I am stating the obvious for the record, in case somebody
with a different (or insufficient) programming languages background
stumbles upon this thread.

What you are really asking, I suspect, is whether Squid or the eCAP
library uses threads to automatically make eCAP adapter operations
asynchronous to the primary Squid operations. The answer to that
question is "no": The relevant Squid code does not use threads, and
there are no threads in the eCAP library code.

Also, there is no magical layer between Squid and 99% of eCAP calls --
Squid calls go directly to your eCAP adapter code and vice versa. IIRC,
the only (unimportant) exception to that "direct calls" observation is
the eCAP service registry API, where there is a thin eCAP layer
insulating the adapter from the host application. That layer is also
synchronous though.


> Is there a way other than
> programming the eCAP adapter in asynchronous mode?

I do not think there is a better alternative. AFAICT, you only have two
options:

  A) Change Squid to move eCAP calls to thread(s).
  B) Use threads inside the adapter to make its operations asynchronous.

As you know, the sample async adapter and the ClamAV adapter use (B).
That approach has its problems (because it currently does not require
the host application to be threads-aware), but it works reasonably well
for many use cases.


Cheers,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 3.5 with nonblocking ecap adapter

Yuri Voinov


01.11.2017 21:23, Alex Rousskov пишет:

> On 11/01/2017 03:20 AM, Christof Gerber wrote:
>
>> [Will Squid] be blocked until the eCAP API call returns?
> To answer the exact question above: Yes, the Squid worker making an eCAP
> API call will block until that call returns. The same is true for all
> other API calls, all system calls, and all internal calls. This is how
> C/C++ works. I am stating the obvious for the record, in case somebody
> with a different (or insufficient) programming languages background
> stumbles upon this thread.
>
> What you are really asking, I suspect, is whether Squid or the eCAP
> library uses threads to automatically make eCAP adapter operations
> asynchronous to the primary Squid operations. The answer to that
> question is "no": The relevant Squid code does not use threads, and
> there are no threads in the eCAP library code.
>
> Also, there is no magical layer between Squid and 99% of eCAP calls --
> Squid calls go directly to your eCAP adapter code and vice versa. IIRC,
> the only (unimportant) exception to that "direct calls" observation is
> the eCAP service registry API, where there is a thin eCAP layer
> insulating the adapter from the host application. That layer is also
> synchronous though.
>
>
>> Is there a way other than
>> programming the eCAP adapter in asynchronous mode?
> I do not think there is a better alternative. AFAICT, you only have two
> options:
>
>   A) Change Squid to move eCAP calls to thread(s).
>   B) Use threads inside the adapter to make its operations asynchronous.
Alex, AFAIK B) is impossible. Because of I see no way to push body from
ecap library to adapter at whole, not chunk. Or I am stupid bastard? I
see no documented way to do this.

>
> As you know, the sample async adapter and the ClamAV adapter use (B).
> That approach has its problems (because it currently does not require
> the host application to be threads-aware), but it works reasonably well
> for many use cases.
>
>
> Cheers,
>
> Alex.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
--
**************************
* C++: Bug to the future *
**************************


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x3E3743A7.asc (2K) Download Attachment
signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Squid 3.5 with nonblocking ecap adapter

Yuri Voinov
In reply to this post by Alex Rousskov


01.11.2017 21:23, Alex Rousskov пишет:

> On 11/01/2017 03:20 AM, Christof Gerber wrote:
>
>> [Will Squid] be blocked until the eCAP API call returns?
> To answer the exact question above: Yes, the Squid worker making an eCAP
> API call will block until that call returns. The same is true for all
> other API calls, all system calls, and all internal calls. This is how
> C/C++ works. I am stating the obvious for the record, in case somebody
> with a different (or insufficient) programming languages background
> stumbles upon this thread.
>
> What you are really asking, I suspect, is whether Squid or the eCAP
> library uses threads to automatically make eCAP adapter operations
> asynchronous to the primary Squid operations. The answer to that
> question is "no": The relevant Squid code does not use threads, and
> there are no threads in the eCAP library code.
>
> Also, there is no magical layer between Squid and 99% of eCAP calls --
> Squid calls go directly to your eCAP adapter code and vice versa. IIRC,
> the only (unimportant) exception to that "direct calls" observation is
> the eCAP service registry API, where there is a thin eCAP layer
> insulating the adapter from the host application. That layer is also
> synchronous though.
>
>
>> Is there a way other than
>> programming the eCAP adapter in asynchronous mode?
> I do not think there is a better alternative. AFAICT, you only have two
> options:
>
>   A) Change Squid to move eCAP calls to thread(s).
>   B) Use threads inside the adapter to make its operations asynchronous.
Also I see no way to exchange between adapter and host with signals
related partial body processing in async manner.

>
> As you know, the sample async adapter and the ClamAV adapter use (B).
> That approach has its problems (because it currently does not require
> the host application to be threads-aware), but it works reasonably well
> for many use cases.
>
>
> Cheers,
>
> Alex.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
--
**************************
* C++: Bug to the future *
**************************


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x3E3743A7.asc (2K) Download Attachment
signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Squid 3.5 with nonblocking ecap adapter

Yuri Voinov
In reply to this post by Alex Rousskov


01.11.2017 21:23, Alex Rousskov пишет:

> On 11/01/2017 03:20 AM, Christof Gerber wrote:
>
>> [Will Squid] be blocked until the eCAP API call returns?
> To answer the exact question above: Yes, the Squid worker making an eCAP
> API call will block until that call returns. The same is true for all
> other API calls, all system calls, and all internal calls. This is how
> C/C++ works. I am stating the obvious for the record, in case somebody
> with a different (or insufficient) programming languages background
> stumbles upon this thread.
>
> What you are really asking, I suspect, is whether Squid or the eCAP
> library uses threads to automatically make eCAP adapter operations
> asynchronous to the primary Squid operations. The answer to that
> question is "no": The relevant Squid code does not use threads, and
> there are no threads in the eCAP library code.
>
> Also, there is no magical layer between Squid and 99% of eCAP calls --
> Squid calls go directly to your eCAP adapter code and vice versa. IIRC,
> the only (unimportant) exception to that "direct calls" observation is
> the eCAP service registry API, where there is a thin eCAP layer
> insulating the adapter from the host application. That layer is also
> synchronous though.
>
>
>> Is there a way other than
>> programming the eCAP adapter in asynchronous mode?
> I do not think there is a better alternative. AFAICT, you only have two
> options:
>
>   A) Change Squid to move eCAP calls to thread(s).
This is absolutely not necessary. The interface of the store ID allows
you to write a threaded asynchronous (thread-aware) helper in
combination with a thread-unaware. This allows its interface. However,
the eCAP interface does not allow this because of the synchronous nature
of the ecap library and this restricts of its interaction with the host.
About this OP asks exactly.
>   B) Use threads inside the adapter to make its operations asynchronous.
>
> As you know, the sample async adapter and the ClamAV adapter use (B).
This sample useless on whole class of cases. For example, it will not
work with gzip compression. I've spent much time in attempts to make
gzip adapter threaded/async. Without any success.
> That approach has its problems (because it currently does not require
> the host application to be threads-aware), but it works reasonably well
> for many use cases.
And it does not work for a much larger number of cases due to library
limitations.
>
>
> Cheers,
>
> Alex.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

--
**************************
* C++: Bug to the future *
**************************


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x3E3743A7.asc (2K) Download Attachment
signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Squid 3.5 with nonblocking ecap adapter

Alex Rousskov
In reply to this post by Yuri Voinov
On 11/01/2017 09:26 AM, Yuri wrote:
>>> Is there a way other than
>>> programming the eCAP adapter in asynchronous mode?

>> I do not think there is a better alternative. AFAICT, you only have two
>> options:
>>
>>   A) Change Squid to move eCAP calls to thread(s).
>>   B) Use threads inside the adapter to make its operations asynchronous.

> AFAIK B) is impossible.

It is not only possible but implemented in sample and production
adapters (as I have said later in the same email).


> I see no way to push body from ecap library to adapter at whole, not
> chunk.

This part of your assertion does not compute for me:

* First of all, it seems completely unrelated to the OP question.

* Second, the body is not pushed "from the eCAP library". Body bytes are
"pushed from" ("made available by" would be a more accurate term) the
host application (e.g., Squid) to (for) the adapter and vice versa. The
amount and timing of body bytes availability are determined by the side
doing the "pushing" and, naturally, body data presence on that side.

Many adapters "stream" message content (processing each body piece on
the fly) and some adapters accumulate whole bodies before acting on
them. The best design depends on the adapter purpose and various
risk/resources/performance/complexity trade-offs.


> I see no documented way to do this.

Asynchronous adapter API is documented in libecap/doc/async.txt. There
are no detailed tutorials, but there is working code to study.

There is no documentation dedicated to body exchanges, but each
adapter::Xaction::ab*() and host::Xaction::vb*() method is briefly
documented and there are public working adapters that illustrate the use
of those methods.

If you have questions specific to eCAP, then this Squid mailing list is
not the right place to ask them, but see http://www.e-cap.org/support/


> And it does not work for a much larger number of cases due to library
> limitations.

AFAICT, you are conflating developer failures with library limitations.
The eCAP library is far from perfect, but it does not have the flaws you
allege.


HTH,

Alex.


>> As you know, the sample async adapter and the ClamAV adapter use (B).
>> That approach has its problems (because it currently does not require
>> the host application to be threads-aware), but it works reasonably well
>> for many use cases.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 3.5 with nonblocking ecap adapter

Yuri Voinov


01.11.2017 23:37, Alex Rousskov пишет:

> On 11/01/2017 09:26 AM, Yuri wrote:
>>>> Is there a way other than
>>>> programming the eCAP adapter in asynchronous mode?
>>> I do not think there is a better alternative. AFAICT, you only have two
>>> options:
>>>
>>>   A) Change Squid to move eCAP calls to thread(s).
>>>   B) Use threads inside the adapter to make its operations asynchronous.
>> AFAIK B) is impossible.
> It is not only possible but implemented in sample and production
> adapters (as I have said later in the same email).
"Stop talking - just show the code." :) (Ideally - in C++, not in C. And
not adapter sample - it's illustrates nothing because it is mixture of
C++03 and pure C pthreads).

>
>
>> I see no way to push body from ecap library to adapter at whole, not
>> chunk.
> This part of your assertion does not compute for me:
>
> * First of all, it seems completely unrelated to the OP question.
>
> * Second, the body is not pushed "from the eCAP library". Body bytes are
> "pushed from" ("made available by" would be a more accurate term) the
> host application (e.g., Squid) to (for) the adapter and vice versa. The
> amount and timing of body bytes availability are determined by the side
> doing the "pushing" and, naturally, body data presence on that side.
Do not cling to words. You understand what I mean. And, for that matter,
yes, the host gives the body - but through the library. If I understand
the design correctly. Otherwise it is not clear, what does the library
have to do with and why is it needed?

>
> Many adapters "stream" message content (processing each body piece on
> the fly) and some adapters accumulate whole bodies before acting on
> them. The best design depends on the adapter purpose and various
> risk/resources/performance/complexity trade-offs.
>
>
>> I see no documented way to do this.
> Asynchronous adapter API is documented in libecap/doc/async.txt. There
> are no detailed tutorials, but there is working code to study.
Seriously? Here is a text file with common words you call good
documentation?
>
> There is no documentation dedicated to body exchanges, but each
> adapter::Xaction::ab*() and host::Xaction::vb*() method is briefly
> documented and there are public working adapters that illustrate the use
> of those methods.
The key word is "briefly". How much public working async adapters do you
know? Which I can study?

>
> If you have questions specific to eCAP, then this Squid mailing list is
> not the right place to ask them, but see http://www.e-cap.org/support/
>
>
>> And it does not work for a much larger number of cases due to library
>> limitations.
> AFAICT, you are conflating developer failures with library limitations.
> The eCAP library is far from perfect, but it does not have the flaws you
> allege.
Ha. Ok, let's agree on it.

>
>
> HTH,
>
> Alex.
>
>
>>> As you know, the sample async adapter and the ClamAV adapter use (B).
>>> That approach has its problems (because it currently does not require
>>> the host application to be threads-aware), but it works reasonably well
>>> for many use cases.
--
**************************
* C++: Bug to the future *
**************************


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x3E3743A7.asc (2K) Download Attachment
signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Squid 3.5 with nonblocking ecap adapter

Alex Rousskov
On 11/01/2017 11:45 AM, Yuri wrote:
> 01.11.2017 23:37, Alex Rousskov пишет:
>>>> B) Use threads inside the adapter to make its operations asynchronous.

>>> AFAIK B) is impossible.

>> It is not only possible but implemented in sample and production
>> adapters (as I have said later in the same email).

> "Stop talking - just show the code." :)

I have already pointed to the relevant code: For example, the eCAP
ClamAV adapter implements (B) since version 2.


> (Ideally - in C++, not in C. And
> not adapter sample - it's illustrates nothing because it is mixture of
> C++03 and pure C pthreads).

All eCAP adapters use C++ because eCAP API requires C++. Some may also
use C libraries (because there are no better C++ alternatives and/or for
other reasons). Your disqualification of adapters using C libraries in
general and pthreads in particular makes no sense to me in this context.
I assume it is just a misunderstanding of how things actually work and
recommend avoiding making broad statements about C inapplicability.


> yes, the host gives the body - but through the library. If I understand
> the design correctly. Otherwise it is not clear, what does the library
> have to do with and why is it needed?

In this context, the eCAP library role is mostly limited to allowing the
dynamic linker to find the right class method where the host application
calls the adapter or where the adapter calls the host application. The
library itself is a thin shim that does not "do" much besides declaring
method names. The eCAP library does not store body pieces, for example.
This makes phrases like "body from ecap library" invalid/misleading. In
my earlier email, I just wanted to clarify that misunderstanding in case
somebody stumbles upon this thread while trying to understand how things
work.

I do not intend to continue this thread because I find your messages too
hostile and not Squid-specific enough. If you have eCAP-specific
questions, please do not post them here. Use eCAP support channels
instead: http://www.e-cap.org/support/


Thank you,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users