lp:~squid/squid/stl

Created by Francesco Chemolli and last modified
Get this branch:
bzr branch lp:~squid/squid/stl
Members of squid can upload to this branch. Log in for directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
squid
Project:
Squid
Status:
Merged

Recent revisions

14593. By Source Maintenance <email address hidden>

SourceFormat Enforcement

14592. By Christos Tsantilas

assertion failed: Write.cc:41: "!ccb->active()"

Bug description:
   - The client side and server side are finished
   - On server side the Ftp::Relay::finalizeDataDownload() is called and
     schedules the Ftp::Server::originDataCompletionCheckpoint
   - On client side the "Ftp::Server::userDataCompletionCheckpoint" is
     called. This is schedules a write to control connection and closes
     data connection.
   - The Ftp::Server::originDataCompletionCheckpoint is called which is
     trying to write to control connection and the assertion triggered.

This bug is an corner case, where the client-side (FTP::Server) should
wait for the server side (Ftp::Client/Ftp::Relay) to finish its job before
respond to the FTP client. In this bug the existing mechanism, designed
to handle such problems, did not worked correctly and resulted to a double
write response to the client.

This patch try to fix the existing mechanism as follows:

- When Ftp::Server receives a "startWaitingForOrigin" callback, postpones
  writting possible responses to the client and keeps waiting for the
  stopWaitingForOrigin callback

- When the Ftp::Server receives a "stopWaitingForOrigin" callback,
  resumes any postponed response.

- When the Ftp::Client starts working on a DATA-related transaction, calls the
  Ftp::Server::startWaitingForOrigin callback

- When the Ftp::Client finishes its job or when its abort abnormaly, checks
  whether it needs to call Ftp::Server::stopWaitingForOrigin callback.

- Also this patch try to fix the status code returned to the FTP client
  taking in account the status code returned by FTP server. The
  "Ftp::Server::stopWaitingForOrigin" is used to pass the returned status code
  to the client side.

This is a Measurement Factory project

14591. By Amos Jeffries

Bug 4458: Squid 4 behaviour change with external ACL arguments

14590. By Alex Rousskov

Detect when a child method declaration hides parent's virtual method.

Adding -Woverloaded-virtual exposed one problem in the existing code.

14589. By eduard-bagdasaryan

Author: Eduard Bagdasaryan <email address hidden>
Added ACL-driven server_pconn_for_nonretriable squid.conf directive.

This directive provides fine-grained control over persistent connection
reuse when forwarding HTTP requests that Squid cannot retry. It is
useful in environments where opening new connections is very expensive
and race conditions associated with persistent connections are very rare
and/or only cause minor problems.

14588. By Alex Rousskov

Trying to avoid "looser throw specifier" error with Wheezy GCC.

AFAICT, the default CbdataParent destructor gets implicit
"noexcept(true)" specifier (because the default destructor does not
throw itself, and CbdataParent has no data members or parents that could
have contributed potentially throwing destructors). The AsyncJob child
uses a lot of things that might throw during destruction (the compiler
cannot tell for sure because we do not use noexcept specifiers). Thus,
the compiler has to use "noexcept(false)" specifier for ~AsyncJob, which
is "looser" that "noexcept(true)" for ~CbdataParent and, hence, violates
the parent interface AsyncJob is implementing/overriding.

I have doubts about the above analysis because many other compilers,
including GCC v5 and clang are happy with the default virtual
CbdataParent destructor. If my analysis is correct, then the rule of
thumb is: Base classes must not use "= default" destructors until all
our implicit destructors become "noexcept".

14587. By Alex Rousskov

Improve class declaration consistency a bit. No functionality changes.

14586. By Alex Rousskov

Use CBDATA_CHILD() instead of CBDATA_CLASS() to mark overridden methods.

TODO: If this works across the build farm, convert other AsyncJob kids.

14585. By Alex Rousskov

Fixed clang -Winconsistent-missing-override warning.

AsyncJob classes can now use C++11 overrides as long as they use the new
CBDATA_CHILD() macro instead of old CBDATA_CLASS().

I have prohibited multiple CBDATA_CHILD() classes on the same
inheritance branch by adding the "final" specifier to toCbdata(). Such
classes feel dangerous because they may have different sizes and it is
not obvious to me whether the cbdata code will call the right size-
specific delete for them. We can easily relax this later if needed.

14584. By Alex Rousskov

Bug 7: Update cached entries on 304 responses.

New Store API to update entry metadata and headers on 304s.
Support entry updates in shared memory cache and rock cache_dirs.
No changes to ufs-based cache_dirs: Their entries are still not updated.

* Atomic StoreEntry metadata updating

   StoreEntry metadata (swap_file_sz, timestamps, etc.) is used
   throughout Squid code. Metadata cannot be updated atomically because
   it has many fields, but a partial update to those fields causes
   assertions. Still, we must update metadata when updating HTTP
   headers. Locking the entire entry for a rewrite does not work well
   because concurrent requests will attempt to download a new entry
   copy, defeating the very HTTP 304 optimization we want to support.

   Ipc::StoreMap index now uses an extra level of indirection (the
   StoreMap::fileNos index) which allows StoreMap control which
   anchor/fileno is associated with a given StoreEntry key. The entry
   updating code creates a disassociated (i.e., entry/key-less) anchor,
   writes new metadata and headers using that new anchor, and then
   _atomically_ switches the map to use that new anchor. This allows old
   readers to continue reading using the stale anchor/fileno as if
   nothing happened while a new reader gets the new anchor/fileno.

   Shared memory usage increase: 8 additional bytes per cache entry: 4
   for the extra level of indirection (StoreMapFileNos) plus 4 for
   splicing fresh chain prefix with the stale chain suffix
   (StoreMapAnchor::splicingPoint). However, if the updated headers are
   larger than the stale ones, Squid will allocate shared memory pages
   to accommodate for the increase, leading to shared memory
   fragmentation/waste for small increases.

* Revamped rock index rebuild process

   The index rebuild process had to be completely revamped because
   splicing fresh and stale entry slot chain segments implies tolerating
   multiple entry versions in a single chain and the old code was based
   on the assumption that different slot versions are incompatible. We
   were also uncomfortable with the old cavalier approach to accessing
   two differently indexed layers of information (entry vs. slot) using
   the same set of class fields, making it trivial to accidentally
   access entry data while using slot index.

   During the rewrite of the index rebuilding code, we also discovered a
   way to significantly reduce RAM usage for the index build map (a
   temporary object that is allocated in the beginning and freed at the
   end of the index build process). The savings depend on the cache
   size: A small cache saves about 30% (17 vs 24 bytes per entry/slot)
   while a 1TB cache_dir with 32KB slots (which implies uneven
   entry/slot indexes) saves more than 50% (~370MB vs. ~800MB).

   Adjusted how invalid slots are counted. The code was sometimes
   counting invalid entries and sometimes invalid entry slots. We should
   always count _slots_ now because progress is measured in the number
   of slots scanned, not entries loaded. This accounting change may
   surprise users with much higher "Invalid entries" count in cache.log
   upon startup, but at least the new reports are meaningful.

   This rewrite does not attempt to solve all rock index build problems.
   For example, the code still assumes that StoreEntry metadata fits a
   single slot which is not always true for very small slots.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:~squid/squid/trunk
This branch contains Public information 
Everyone can see this information.

Subscribers