[squid-users] Squid 3.5 with nonblocking ecap adapter

[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).


> 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.