Re: Kerberos build failures in HEAD
On Sun, 13 Sep 2009, Henrik Nordstrom wrote: s?n 2009-09-13 klockan 21:30 +0200 skrev Henrik Nordstrom: seems to build fine for me on CentOS 5.2.. but maybe something in the test builds are triggering it.. A full test is running.. Found.. it fails when used in combination with --enable-ssl. This due to OpenSSL (or actually krb5.h I think, included by openssl) ending up including com_err.h without the extern C wrapper, or if you prefer due to the com_err.h include not shielding itself from C++ parsing... Proposed fix: Have src/ssl_support.h include et/com_err.h in an extern C wrapping before OpenSSL includes... Have been bitten by this as well. The proposed fix sounds good to me. Thank you, Alex.
Re: Kerberos build failures in HEAD
mån 2009-09-14 klockan 14:53 +1200 skrev Amos Jeffries: Proposed fix: Have src/ssl_support.h include et/com_err.h in an extern C wrapping before OpenSSL includes... So... does it actually require the extern-C ? com_err.h yes. It's a C header with no built-in C++ shielding, which means any prototypes defined there will mess things up as C++ will process them as C++ type-dependent prototypes, causinglinking to fail as C error_message() is a different linking symbol from C++ error_message(long). Regards Henrik
compute swap_file_sz before packing it
Hello,
A few weeks ago, I stumbled upon swap entry size calculation and
store dir selection bug. I found more problems with the related code.
One of them is discussed in this email.
Apparently, we are packing StoreEntry.swap_file_sz into the stored
entry header before we compute its value. This happens because to
compute swap_file_sz, we need to know swap_hdr_sz, the size of the
stored entry header. To compute swap_hdr_sz, we need to pack the
header, but we cannot pack the header because swap_file_sz field has
not been computed yet. Chicken and egg, hidden behind a bunch of void*
memcopies.
We have not noticed the problem because UFS ignores swap_file_sz (or
supplies its own) in most contexts and COSS simply lacks the part of
the code that would expose the bug (no store rebuilding from the
disk db file).
The attached patch is a work in progress hack to facilitate the
discussion. The patch computes the future swap_hdr_sz without packing
the header, sets swap_file_sz, and then packs the header. It is not
very efficient but appears to work.
If I am on the wrong path here, please shout.
Thank you,
Alex.
Work in progress: compute swap_file_sz before packing it
=== modified file 'src/StoreMeta.h'
--- src/StoreMeta.h 2009-02-01 10:09:23 +
+++ src/StoreMeta.h 2009-09-13 10:26:18 +
@@ -162,6 +162,8 @@
/// \ingroup SwapStoreAPI
SQUIDCEXTERN char *storeSwapMetaPack(tlv * tlv_list, int *length);
/// \ingroup SwapStoreAPI
+SQUIDCEXTERN size_t storeSwapMetaSize(const StoreEntry * e);
+/// \ingroup SwapStoreAPI
SQUIDCEXTERN tlv *storeSwapMetaBuild(StoreEntry * e);
/// \ingroup SwapStoreAPI
SQUIDCEXTERN void storeSwapTLVFree(tlv * n);
=== modified file 'src/store.cc'
--- src/store.cc2009-09-02 05:42:24 +
+++ src/store.cc2009-09-13 11:06:37 +
@@ -1801,12 +1801,18 @@
char const *
StoreEntry::getSerialisedMetaData()
{
+const size_t swap_hdr_sz0 = storeSwapMetaSize(this);
+assert (swap_hdr_sz0 = 0);
+mem_obj-swap_hdr_sz = (size_t) swap_hdr_sz0;
+// now we can use swap_hdr_sz to calculate swap_file_sz
+// so that storeSwapMetaBuild/Pack can pack corrent swap_file_sz
+swap_file_sz = objectLen() + mem_obj-swap_hdr_sz;
+
StoreMeta *tlv_list = storeSwapMetaBuild(this);
int swap_hdr_sz;
char *result = storeSwapMetaPack(tlv_list, swap_hdr_sz);
+assert(static_castint(swap_hdr_sz0) == swap_hdr_sz);
storeSwapTLVFree(tlv_list);
-assert (swap_hdr_sz = 0);
-mem_obj-swap_hdr_sz = (size_t) swap_hdr_sz;
return result;
}
=== modified file 'src/store_swapmeta.cc'
--- src/store_swapmeta.cc 2009-02-01 10:09:23 +
+++ src/store_swapmeta.cc 2009-09-13 11:12:46 +
@@ -52,6 +52,30 @@
}
/*
+ * Calculate TLV list size for a StoreEntry
+ * XXX: Must match the actual storeSwapMetaBuild result size
+ */
+size_t
+storeSwapMetaSize(const StoreEntry * e)
+{
+ size_t size = 0;
+++size; // STORE_META_OK
+size += sizeof(int); // size of header to follow
+
+ const size_t pfx = sizeof(char) + sizeof(int); // in the start of list
entries
+
+size += pfx + SQUID_MD5_DIGEST_LENGTH;
+size += pfx + STORE_HDR_METASIZE;
+size += pfx + strlen(e-url()) + 1;
+
+if (const char *vary = e-mem_obj-vary_headers)
+size += pfx + strlen(vary) + 1;
+
+debugs(20, 3, storeSwapMetaSize( e-url() ): size);
+return size;
+}
+
+/*
* Build a TLV list for a StoreEntry
*/
tlv *
=== modified file 'src/store_swapout.cc'
--- src/store_swapout.cc2009-09-02 05:53:27 +
+++ src/store_swapout.cc2009-09-13 09:24:16 +
@@ -345,7 +345,8 @@
debugs(20, 3, storeSwapOutFileClosed: SwapOut complete: '
e-url() ' to
e-swap_dirn , std::hex std::setw(8)
std::setfill('0')
std::uppercase e-swap_filen);
-e-swap_file_sz = e-objectLen() + mem-swap_hdr_sz;
+//e-swap_file_sz = e-objectLen() + mem-swap_hdr_sz;
+assert(e-swap_file_sz == static_castuint64_t(e-objectLen() +
mem-swap_hdr_sz));
e-swap_status = SWAPOUT_DONE;
e-store()-updateSize(e-swap_file_sz, 1);
R: R: R: R: R: Squid 3 build errors on Visual Studio - problem still present
Hi Henrik, Can you produce a preprocessed source? That's the output of just the preprocessor, not actual compilarion, comparable to gcc -E option. Easier to identify what the compiler actually saw that way... Done. Sorry for the delay, but I'm very busy (as usual ...) I have placed the preprocessed source of two failing files (IpIntercept.cc and QosConfig.cc) here: http://www.acmeconsulting.it/libip.zip Regards Guido Guido Serassio Acme Consulting S.r.l. Microsoft Gold Certified Partner Via Lucia Savarino, 110098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: guido.seras...@acmeconsulting.it WWW: http://www.acmeconsulting.it
Re: Kerberos build failures in HEAD
Alex Rousskov wrote: On Sun, 13 Sep 2009, Henrik Nordstrom wrote: s?n 2009-09-13 klockan 21:30 +0200 skrev Henrik Nordstrom: seems to build fine for me on CentOS 5.2.. but maybe something in the test builds are triggering it.. A full test is running.. Found.. it fails when used in combination with --enable-ssl. This due to OpenSSL (or actually krb5.h I think, included by openssl) ending up including com_err.h without the extern C wrapper, or if you prefer due to the com_err.h include not shielding itself from C++ parsing... Proposed fix: Have src/ssl_support.h include et/com_err.h in an extern C wrapping before OpenSSL includes... Have been bitten by this as well. The proposed fix sounds good to me. Thank you, Alex. Okay, and in light that it's a nasty hack around some brokenness. I suggest the include should go in the compat library. compat/compat_shared.h is the file for non-OS-specific bits. Simply wrapping an include of com_err.h inside there with a documentation note quoting Henriks analysis above. Should fix it for all the main Squid code and some helpers. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE19 Current Beta Squid 3.1.0.13
clientNatLookup: NAT lookup failed: ioctl(SIOCGNATL)
Dear All, 2009/09/14 15:30:32| clientNatLookup: NAT lookup failed: ioctl(SIOCGNATL) The above message is appearing every minute in the cache.log I have searched the forums and I did not get any information . My server is under test and I am afraid to put it into production. Below are the information about the server. - hardware is Sun 2200 - OS is solaris 10 - Squid is the latest of ver 3 - Configure was done with --enable-ipf-transparent option - mode is transparent, so ipnat.conf has one line with: rdr elxl0 0.0.0.0/0 port 80 - 194.126.5.36 port 3128 tcp - http port 80 transparentline on squid.conf Please advice if there is anything missing in configuring the server. thank you and Best Regards, Paul -- View this message in context: http://www.nabble.com/clientNatLookup%3A-NAT-lookup-failed%3A-ioctl%28SIOCGNATL%29-tp25435399p25435399.html Sent from the Squid - Development mailing list archive at Nabble.com.
Re: Squid-smp : Please discuss
mån 2009-09-14 klockan 22:43 +1200 skrev Amos Jeffries: on epoll ( select ) implementations in squid. It is found that epoll is polling all the descriptors processing them one by one. There is an important FD used by http port which is always busy, but has to wait for other descriptors in queue to be processed. The http_port is far from that buzy. Unless you are under heavy overload the http_port is not ready most poll loops. The only traffic seen on that filedescriptor is accepting of new connections. Additionally with the nature of HTTP data flow the timing between connection establishement and processing the new connection is not very critical, as long as it gets done within reasonable time. There is a large margin thanks to the time it takes for the client to send the first request. Then, I also found that it is possible to separateworking of all fd handlers , e.g fd used by http port.(tried) This can be done by making some changes in codes. The issue preventing this is how to deal with the access to all shared data. Will need quite a bit of locks to be introduced if starting to introduce threads. Special pseudo-thread handling is already hacked up in a pseudo-thread poller for DNS replies. Which is complicating the FD handling there. Hmm.. is there? Where? Checking the state of epoll in Squid-3 I notice it's in the same shape 2.5 was, missing the cleanups and generalizations done in Squid-2. In squid-2 we do have a set of incoming filedescriptors which are polled more frequently than the others if there is too much work in the select loop. But users of high traffic servers have found that for epoll this makes accepting new connections too agressive, and Squid runs better (more smoothly) with this disabled. That allows making the whole select loop(s) happen in parallel to the rest of Squid. Simply accepts and spawns AsyncJob/AsyncCall entries into the main squid processing queue. Workable? Yes, but i kind of doubt it will give any benefit at all. When Squid is running under normal load epoll queue length is in the range of 10-40, not more, and occationally the http_port fd's is marked ready (far from always). The epoll in itself is not very heavy operation, the heavy part is reading and processing the request/response data. But the up side is that this is a easy spot to attack to try adding and experimenting with threading. The accept() is very isolated in the amount of data it needs access to. Regards Henrik
Re: clientNatLookup: NAT lookup failed: ioctl(SIOCGNATL)
mån 2009-09-14 klockan 06:02 -0700 skrev Paul Khadra: Dear All, 2009/09/14 15:30:32| clientNatLookup: NAT lookup failed: ioctl(SIOCGNATL) The above message is appearing every minute in the cache.log Which means Squid and your NAT kernel do not talk properly to each other, making the original destination information unavailable to Squid. - OS is solaris 10 - Configure was done with --enable-ipf-transparent option Which version of ipfilter? Regards Henrik
Re: compute swap_file_sz before packing it
mån 2009-09-14 klockan 02:04 -0600 skrev Alex Rousskov: Apparently, we are packing StoreEntry.swap_file_sz into the stored entry header before we compute its value. This happens because to compute swap_file_sz, we need to know swap_hdr_sz, the size of the stored entry header. To compute swap_hdr_sz, we need to pack the header, but we cannot pack the header because swap_file_sz field has not been computed yet. Chicken and egg, hidden behind a bunch of void* memcopies. Hmm... are we really packing that one? I thougt we only packed the objet size in STORE_META_OBJSIZE which is excluding the TLV header. Right... it's in STORE_META_STD. Just ignore that one as a design error. Use STORE_META_OBJSIZE instead, and calculate the file size as object size + header size if needed. The attached patch is a work in progress hack to facilitate the discussion. The patch computes the future swap_hdr_sz without packing the header, sets swap_file_sz, and then packs the header. It is not very efficient but appears to work. Do we need that? COSS rebuildig is quite content with using STORE_META_OBJSIZE. If I am on the wrong path here, please shout. Maybe. Or at least a redundant path. Note: when the store progresses with separation of headers data this will get even fuzzier with file size changing over time for the same object as headers gets updated. By that time we quite likely move HTTP headers into the TLV header, but that's future. Regards Henrik
Re: Squid-smp : Please discuss
On Mon, 14 Sep 2009, Amos Jeffries wrote:
I think we should take this on-list so the others with more detailed
knowledge can give advice in case I have my facts wrong about AsyncCalls...
I am afraid this discussion focuses on a small part of a much bigger
problem so finalizing the design decisions here may be counter
productive until we have an agreement on how to split Squid into
threads in general.
There are a few different ways to partition Squid and most of them
have been discussed in the past. I am not sure whether the discussions
have ever reached a consensus point. I am also not sure there is
consensus whether we should design for 2 cores, 8, cores, 16 cores, 32
cores, or more, or all of the above?
There is also a question on how configurable everything should be. For
example, if the box has only two cores, will the user be able to
specify which threads are created and which created threads run on
which core? Also, will the user be able to specify whether memory or
disk cache is shared?
I also agree that the major difficulty here is not implementing the
threading code itself, but making sure that no shared data is accessed
unlocked. This is easy when you start from scratch, but we have a lot
of globals and static objects accessed all around the code. Protecting
each of them individually by hand would require a lot of coding and
risk. IMO, we need to add a few classes that would make sharing global
data simple and safe. This is where C++ would help a lot.
And even the protection of globals requires a high-level design plan:
do we protect global objects like Config or individual data types like
SquidString?
Finally, I agree that making accepting code into a thread may lead to
too aggressive incoming stream of requests that would overwhelm the
other parts of the system. I have recently observed that kind of
behavior in another threaded performance-focused application. This
does not mean that accept must not be a thread, but it means that we
should think how the overall design would prevent one thread from
overloading others with work.
Cheers,
Alex.
Sachin Malave wrote:
On Sun, Sep 13, 2009 at 7:52 PM, Amos Jeffries squ...@treenet.co.nz
wrote:
On Sun, 13 Sep 2009 07:12:56 -0400, Sachin Malave sachinmal...@gmail.com
wrote:
Hello Amos,
As discussed before, I am analyzing codes for the changes as on
http://wiki.squid-cache.org/Features/SmpScale, and have concentrated
on epoll ( select ) implementations in squid. It is found that epoll
is polling all the descriptors processing them one by one. There is
an important FD used by http port which is always busy, but has to
wait for other descriptors in queue to be processed.
Then, I also found that it is possible to separateworking of all fd
handlers , e.g fd used by http port.(tried)
This can be done by making some changes in codes.
i have been trying to code test these changes since last few days,
of course this may not be correct or need some improvements to meet
our requirements, Please give me feedback and tell me dependencies i
might have not considered,
Again one important issue, I know that, doing changes as mentioned
below will create and kill thread after each timeout but we can extend
it further, and make a separate thread that will never exit, we will
discuss on this issue later, before everything, please check proposed
changes so that we can move further.
You mean the main http_port listener (port 3128 etc)?
This is currently not handled specially, due to there being more than one
listener FD in many Squid setups (multiple http_port and https_port then
other protocols like HTTPS, ICP, HTCP, DNS), any threading solution needs
to handle the listeners agnostic of what they do. Though splitting
listener
FD accepts into a separate loop from other FD does seem sound.
Special pseudo-thread handling is already hacked up in a pseudo-thread
poller for DNS replies. Which is complicating the FD handling there. What
I'd like to see is resource-locking added to the Async queue when adding
new queue entries.
That allows making the whole select loop(s) happen in parallel to the rest
of Squid. Simply accepts and spawns AsyncJob/AsyncCall entries into the
main squid processing queue.
Workable?
*Changes are tagged with NEW
1. inside client_side.cc
void clientHttpConnectionsOpen(void)
{
.
httpfd=fd; //httfd now holding http file descriptor (NEW)
.
.
.
comm_accept(fd, httpAccept, s);
}
2. inside comm_epoll.cc
int kdpfdHttp;
int useHttpThread = 1;
void comm_select_init(void)
{
peventsHttp = (struct epoll_event *) xmalloc(1 *
sizeof(struct epoll_event)); //NEW
kdpfdHttp = epoll_create(1); //NEW
}
void commSetSelect(int fd, unsigned int type, PF * handler, void
*client_data, time_t timeout)
{
if (!F-flags.open) {
if
Re: R: R: R: R: R: Squid 3 build errors on Visual Studio - problem still present
mån 2009-09-14 klockan 11:27 +0200 skrev Guido Serassio:
Done. Sorry for the delay, but I'm very busy (as usual ...)
I have placed the preprocessed source of two failing files
(IpIntercept.cc and QosConfig.cc) here:
http://www.acmeconsulting.it/libip.zip
Odd... std::string::npos is declared as follows:
namespace std;
templateclass _Elem,
class _Traits,
class _Ax
class basic_string
: public _String_val_Elem, _Ax
{
public:
static const size_type npos;
};
templateclass _Elem,
class _Traits,
class _Alloc
const typename basic_string_Elem, _Traits, _Alloc::size_type
basic_string_Elem, _Traits, _Alloc::npos =
(typename basic_string_Elem, _Traits,
_Alloc::size_type)(-1);
typedef basic_stringchar, char_traitschar, allocatorchar
string;
Maybe Visual Studio drops the const attribute when trying to convert the
value from const std::string:size_type to const String::size_type
and gets lost somehow, even with the value as such being a simple size_t
integer..
What does it say about the attached code? My attempt in isolating the
String npos = std::string::npos code with as little change as possible
(had to kill the char_traits thing as that used template syntax not
accepted by G++ which slightly changes how size_type is declared)
Regards
Henrik
typedef long size_t;
namespace std {
templateclass _Ty class allocator
{
public:
typedef size_t size_type;
};
templateclass _Elem,
class _Traits,
class _Ax
class basic_string
{
public:
typedef typename _Ax::size_type size_type;
static const size_type npos;
};
templateclass _Elem,
class _Traits,
class _Alloc
const typename basic_string_Elem, _Traits, _Alloc::size_type
basic_string_Elem, _Traits, _Alloc::npos =
(typename basic_string_Elem, _Traits, _Alloc::size_type)(-1);
typedef basic_stringchar, char, allocatorchar
string;
};
class String {
typedef size_t size_type;
static const size_type npos = std::string::npos;
};
Re: compute swap_file_sz before packing it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a small meta point: The new function you're adding looks like it should be a method to me. - -Rob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkquyF4ACgkQ42zgmrPGrq4kDQCeLjIz1zAP9F4nvCPz7gkrxbyw Q5cAnR8qzBjnwR97OgPa1tFxyq9Lv+5R =XS/a -END PGP SIGNATURE-
[PATCH] Log additional header for the navigation from BlackBarry Device
I hope this tiny patch can be useful also for other user, so i put here for
review and possible merge if you like.
Thanks in advance
Elia
~~~
This patch permit to log the additional Header used by BlackBarry
and to remove these via http_headers squid.conf directive.
For example
logformat BlackBerry %ts.%03tu %6tr %a %Ss/%03Hs %st %rm %ru %un
%Sh/%A %mt %{Rim-device-id}h %{Rim-device-email}h /*Log BB
headers*/
access_log /usr/local/squid/var/logs/access.log BlackBerry bes /*In this
case the logging is redirected based on ACL*/
……
acl bes src XX.XX.XX.XX/255.255.255.255/*IP Server BES*/
……
header_access Rim-device-email deny all /*Remove header
from GET*/
header_access Rim-device-id deny all /*Remove header
from GET*/
---
src/HttpHeader.c |3 +++
src/enums.h |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/HttpHeader.c b/src/HttpHeader.c
index 61be2e3..f2dd83d 100644
--- a/src/HttpHeader.c
+++ b/src/HttpHeader.c
@@ -111,6 +111,8 @@ static const HttpHeaderFieldAttrs HeadersAttrs[] =
{Referer, HDR_REFERER, ftStr},
{Request-Range, HDR_REQUEST_RANGE, ftPRange},/* usually matches
HDR_RANGE */
{Retry-After, HDR_RETRY_AFTER, ftStr}, /* for now (ftDate_1123 or
ftInt!) */
+{Rim-device-id, HDR_RIM_DEVICE_ID, ftStr}, /* Header added
for BlackBerry */
+{Rim-device-email, HDR_RIM_DEVICE_EMAIL, ftStr}, /* Header added
for BlackBerry */
{Server, HDR_SERVER, ftStr},
{Set-Cookie, HDR_SET_COOKIE, ftStr},
{Transfer-Encoding, HDR_TRANSFER_ENCODING, ftStr},
@@ -221,6 +223,7 @@ static http_hdr_type RequestHeadersArr[] =
HDR_IF_MATCH, HDR_IF_MODIFIED_SINCE, HDR_IF_NONE_MATCH,
HDR_IF_RANGE, HDR_MAX_FORWARDS, HDR_PROXY_CONNECTION,
HDR_PROXY_AUTHORIZATION, HDR_RANGE, HDR_REFERER, HDR_REQUEST_RANGE,
+HDR_RIM_DEVICE_ID, HDR_RIM_DEVICE_EMAIL,
HDR_USER_AGENT, HDR_X_FORWARDED_FOR, HDR_TE, HDR_EXPECT
};
diff --git a/src/enums.h b/src/enums.h
index 694f033..d9cfabf 100644
--- a/src/enums.h
+++ b/src/enums.h
@@ -240,6 +240,8 @@ typedef enum {
HDR_REQUEST_RANGE, /* some clients use this, sigh */
HDR_REFERER,
HDR_RETRY_AFTER,
+HDR_RIM_DEVICE_ID, /* added for Blackberry */
+HDR_RIM_DEVICE_EMAIL, /* added for Blackberry */
HDR_SERVER,
HDR_SET_COOKIE,
HDR_UPGRADE,
--
1.5.5.6
0001-Log-additional-header-for-the-navigation-from-BlackB.patch
Description: Binary data
Build failed in Hudson: 2.HEAD-i386-OpenBSD-4.5 #7
See http://build.squid-cache.org/job/2.HEAD-i386-OpenBSD-4.5/7/changes Changes: [squidadm] Synchronized with cvs.squid-cache.org -- Started by upstream project 2.HEAD-amd64-CentOS-5.3 build number 10 Building remotely on vobsd $ computing changelog + ./bootstrap.sh automake : autoconfg: Bootstrapping ./bootstrap.sh[90]: aclocal: not found aclocal failed Autotool bootstrapping failed. You will need to investigate and correct before you can develop on this source tree
Re: clientNatLookup: NAT lookup failed: ioctl(SIOCGNATL)
On Mon, 14 Sep 2009 23:32:33 +0200, Henrik Nordstrom hen...@henriknordstrom.net wrote: mån 2009-09-14 klockan 06:02 -0700 skrev Paul Khadra: Dear All, 2009/09/14 15:30:32| clientNatLookup: NAT lookup failed: ioctl(SIOCGNATL) The above message is appearing every minute in the cache.log Which means Squid and your NAT kernel do not talk properly to each other, making the original destination information unavailable to Squid. - OS is solaris 10 - Configure was done with --enable-ipf-transparent option Which version of ipfilter? Regards Henrik ... and what exact numeric release of squid? The transparent: option has been deprecated for a while now in the betas. Amos
Re: Squid-smp : Please discuss
On Mon, 14 Sep 2009 16:14:12 -0600 (MDT), Alex Rousskov rouss...@measurement-factory.com wrote: On Mon, 14 Sep 2009, Amos Jeffries wrote: I think we should take this on-list so the others with more detailed knowledge can give advice in case I have my facts wrong about AsyncCalls... I am afraid this discussion focuses on a small part of a much bigger problem so finalizing the design decisions here may be counter productive until we have an agreement on how to split Squid into threads in general. Aye. Thats the idea. There are a few different ways to partition Squid and most of them have been discussed in the past. I am not sure whether the discussions have ever reached a consensus point. I am also not sure there is consensus whether we should design for 2 cores, 8, cores, 16 cores, 32 cores, or more, or all of the above? The partitioning discussion must have happened well before my time. The last few years its been consensus that the components get partitioned into SourceLayout components and AsyncCalls codepaths. Further partitioning we have not discussed recently. There is also a question on how configurable everything should be. For example, if the box has only two cores, will the user be able to specify which threads are created and which created threads run on which core? Also, will the user be able to specify whether memory or disk cache is shared? This can be decided and added after the initial experiments and locking tests yes? When squid is starting to push CPU intensive stuff into threads other than the current main one. I also agree that the major difficulty here is not implementing the threading code itself, but making sure that no shared data is accessed unlocked. This is easy when you start from scratch, but we have a lot of globals and static objects accessed all around the code. Protecting each of them individually by hand would require a lot of coding and risk. IMO, we need to add a few classes that would make sharing global data simple and safe. This is where C++ would help a lot. And even the protection of globals requires a high-level design plan: do we protect global objects like Config or individual data types like SquidString? IMHO, objects/types which may be written to or deleted while a thread is trying to read from it. RefCounting done properly forms a lock on certain read-only types like Config. Though we are currently handling that for Config by leaking the memory out every gap. SquidString is not thread-safe. But StringNG with its separate refcounted buffers is almost there. Each thread having a copy of StringNG sharing a SBuf equates to a lock with copy-on-write possibly causing issues we need to look at if/when we get to that scope. Finally, I agree that making accepting code into a thread may lead to too aggressive incoming stream of requests that would overwhelm the other parts of the system. I have recently observed that kind of behavior in another threaded performance-focused application. This does not mean that accept must not be a thread, but it means that we should think how the overall design would prevent one thread from overloading others with work. Cheers, Alex. The biggest question underlying SMP before we can even look at locking and resources is whether AsyncCalls is a suitable interface between threads (thread A schedules call, thread B runs it...) or do we need yet another queuing mechanism. Locking can be iteratively/incrementally done as things are converted. Each resource will have its own challenges and requirements. We can't face them all now and expect to get it right. When the async question is answered we look at exactly what the best way to lock the queue is. This is a small scope though suitable for experimenting with some easily adapted area of the code as a starting point with a clearly measurable works/fails. It's only locking dependence is on the immediate data and what queue to add the next event/call/whatever to. Then as you point out, how to prevent the accept()'s overloading the main queue as multi-threads funnel down to the old central one. The 'safe' approach is to convert the hard way. From server-facing code out to client-facing. Unfortunately that approach does involve a lot more locking design problems very early on. Amos Sachin Malave wrote: On Sun, Sep 13, 2009 at 7:52 PM, Amos Jeffries squ...@treenet.co.nz wrote: On Sun, 13 Sep 2009 07:12:56 -0400, Sachin Malave sachinmal...@gmail.com wrote: Hello Amos, As discussed before, I am analyzing codes for the changes as on http://wiki.squid-cache.org/Features/SmpScale, and have concentrated on epoll ( select ) implementations in squid. It is found that epoll is polling all the descriptors processing them one by one. There is an important FD used by http port which is always busy, but has to wait for other descriptors in queue to be processed. Then, I also found that
Re: Squid-smp : Please discuss
I think we should take this on-list so the others with more detailed knowledge can give advice in case I have my facts wrong about AsyncCalls... I am afraid this discussion focuses on a small part of a much bigger problem so finalizing the design decisions here may be counter productive until we have an agreement on how to split Squid into threads in general. Aye. Thats the idea. There are a few different ways to partition Squid and most of them have been discussed in the past. I am not sure whether the discussions have ever reached a consensus point. I am also not sure there is consensus whether we should design for 2 cores, 8, cores, 16 cores, 32 cores, or more, or all of the above? The partitioning discussion must have happened well before my time. The last few years its been consensus that the components get partitioned into SourceLayout components and AsyncCalls codepaths. Further partitioning we have not discussed recently. I'm going to kick-start a new round then. If the approach has already been discussed, please forgive me and ignore this post. The idea is.. but what if we tried using a shared-nothing approach? Quick run-down: there is farm of processes, each with its own cache_mem and cache_dir(s). When a process receives a request, it parses it, hashes it somehow (CARP or a variation thereof) and defines if should handle it or if some other process should handle it. If it's some other process, it uses a Unix socket and some simple serialization protocol to pass around the parsed request and the file descriptor, so that the receiving process can pick up and continue servicing the request. There are some hairy bits (management, accounting, reconfiguration..) and some less hairy bits (hashing algorithm to use, whether there is a master process and a workers farm, or whether workers compete on accept()ing), but on a first sight it would seem a simpler approach than the extensive threading and locking we're talking about, AND it's completely orthogonal to it (so it could be viewed as a medium-term solution while AsyncCalls-ification remains active as a long-term refactoring activity, which will eventually lead to a true MT-squid) Please forgive me if it's a 5AM sleep-deprivation-induced brain-crap, or if this approach was already discussed and discarded. -- /kinkie
Re: Squid-smp : Please discuss
On Tue, 2009-09-15 at 14:27 +1200, Amos Jeffries wrote: RefCounting done properly forms a lock on certain read-only types like Config. Though we are currently handling that for Config by leaking the memory out every gap. SquidString is not thread-safe. But StringNG with its separate refcounted buffers is almost there. Each thread having a copy of StringNG sharing a SBuf equates to a lock with copy-on-write possibly causing issues we need to look at if/when we get to that scope. General rule: you do /not/ want thread safe objectse for high usage objects like RefCount and StringNG. synchronisation is expensive; design to avoid synchronisation and hand offs as much as possible. -Rob signature.asc Description: This is a digitally signed message part
Why does Squid-2 return HTTP_PROXY_AUTHENTICATION_REQUIRED on http_access DENY?
G'day. This question is aimed mostly at Henrik, who I recall replying to a similar question years ago but without explaining why. Why does Squid-2 return HTTP_PROXY_AUTHENTICATION_REQUIRED on a denied ACL? The particular bit in src/client_side.c: int require_auth = (answer == ACCESS_REQ_PROXY_AUTH || aclIsProxyAuth(AclMatchedName)) !http-request-flags.transparent; Is there any particular reason why auth is tried again? it forces a pop-up on browsers that already have done authentication via NTLM. I've written a patch to fix this in Squid-2.7: http://www.creative.net.au/diffs/2009-09-15-squid-2.7-auth_required_on_auth_acl_deny.diff I'll create a bugtraq entry when I have some more background information about this. Thanks, adrian
Re: Squid-smp : Please discuss
On Tue, Sep 15, 2009 at 1:18 AM, Adrian Chadd adr...@squid-cache.org wrote: Guys, Please look at what other multi-CPU network applications do, how they work and don't work well, before continuing this kind of discussion. Everything that has been discussed has already been done to death elsewhere. Please don't re-invent the wheel, badly. Adrian 2009/9/15 Robert Collins robe...@robertcollins.net: On Tue, 2009-09-15 at 14:27 +1200, Amos Jeffries wrote: RefCounting done properly forms a lock on certain read-only types like Config. Though we are currently handling that for Config by leaking the memory out every gap. SquidString is not thread-safe. But StringNG with its separate refcounted buffers is almost there. Each thread having a copy of StringNG sharing a SBuf equates to a lock with copy-on-write possibly causing issues we need to look at if/when we get to that scope. General rule: you do /not/ want thread safe objectse for high usage objects like RefCount and StringNG. synchronisation is expensive; design to avoid synchronisation and hand offs as much as possible. -Rob Yes synchronization is always expensive . So we must target only those areas where shared data is updated infrequently. Also if we are making thread then the amount of work done must be more as compared to overheads required in thread creation, synchronization scheduling. If we try to provide locks to existing data structures then synchronization factor will definitely affect to our design. Redesigning of such structures and there behavior is time consuming and may change whole design of the Squid. Whatever it may be.. WE HAVE TO MOVE SQUID TO MULTI-CORE... because future is MULTI-CORE.. Anyways still there are many question in my mind but as am new here, would like to spend some time in analysis of current design PLEASE cope with my speed -- Mr. S. H. Malave MTech, Computer Science Engineering Dept., Walchand College of Engineering, Sangli. Mob. 9860470739 sachinmal...@wce.org.in
Re: Squid-smp : Please discuss
Guys, Please look at what other multi-CPU network applications do, how they work and don't work well, before continuing this kind of discussion. Everything that has been discussed has already been done to death elsewhere. Please don't re-invent the wheel, badly. Adrian 2009/9/15 Robert Collins robe...@robertcollins.net: On Tue, 2009-09-15 at 14:27 +1200, Amos Jeffries wrote: RefCounting done properly forms a lock on certain read-only types like Config. Though we are currently handling that for Config by leaking the memory out every gap. SquidString is not thread-safe. But StringNG with its separate refcounted buffers is almost there. Each thread having a copy of StringNG sharing a SBuf equates to a lock with copy-on-write possibly causing issues we need to look at if/when we get to that scope. General rule: you do /not/ want thread safe objectse for high usage objects like RefCount and StringNG. synchronisation is expensive; design to avoid synchronisation and hand offs as much as possible. -Rob
Re: Squid-smp : Please discuss
On Tue, Sep 15, 2009 at 1:38 AM, Adrian Chadd adr...@squid-cache.org wrote: 2009/9/15 Sachin Malave sachinmal...@gmail.com: On Tue, Sep 15, 2009 at 1:18 AM, Adrian Chadd adr...@squid-cache.org wrote: Guys, Please look at what other multi-CPU network applications do, how they work and don't work well, before continuing this kind of discussion. Everything that has been discussed has already been done to death elsewhere. Please don't re-invent the wheel, badly. Yes synchronization is always expensive . So we must target only those areas where shared data is updated infrequently. Also if we are making thread then the amount of work done must be more as compared to overheads required in thread creation, synchronization scheduling. Current generation CPUs are a lot, lot better at the thread-style sync primitives than older CPUs. There's other things to think about, such as lockless queues, transactional memory hackery, atomic instructions in general, etc, etc, which depend entirely upon the type of hardware being targetted. If we try to provide locks to existing data structures then synchronization factor will definitely affect to our design. Redesigning of such structures and there behavior is time consuming and may change whole design of the Squid. Adrian And current generation libraries are also far better than older, like OpenMP, creating threads and handling synchronization issues in OpenMP is very easy... Automatic locks are provided, u need not to design your own locking mechanisms Just a statement and u can lock the shared variable... Then the major work remains is to identify the shared access. I WANT TO USE OPENMP library. ANY suggestions.
Re: Why does Squid-2 return HTTP_PROXY_AUTHENTICATION_REQUIRED on http_access DENY?
On Tue, 2009-09-15 at 15:22 +1000, Adrian Chadd wrote: G'day. This question is aimed mostly at Henrik, who I recall replying to a similar question years ago but without explaining why. Why does Squid-2 return HTTP_PROXY_AUTHENTICATION_REQUIRED on a denied ACL? The particular bit in src/client_side.c: int require_auth = (answer == ACCESS_REQ_PROXY_AUTH || aclIsProxyAuth(AclMatchedName)) !http-request-flags.transparent; Is there any particular reason why auth is tried again? it forces a pop-up on browsers that already have done authentication via NTLM. Because it should? Perhaps you can expand on where you are seeing this - I suspect a misconfiguration or some such. Its entirely appropriate to signal HTTP_PROXY_AUTHENTICATION_REQUIRED when a user is denied access to a resource *and if they log in differently they could get access*. -Rob signature.asc Description: This is a digitally signed message part
