This allows the fragments to be moved without rewriting the table which is
at the end of the set of fragments and so will need to be moved by the
collector last.
On Jun 9, 2017 11:58 AM, "Alan Carroll"
wrote:
The offsets are in the stripe directory under the cache key for the
fragment.
On Frid
For objects which do not have more than one version (alternate, e.g. Vary
header) and where the header and body fit into a single fragment only a
single seek is required.
This is the case for many smaller objects, e.g. images.
On Tue, Jun 6, 2017 at 8:34 AM, Alan Carroll <
solidwallofc...@yahoo-i
While large objects are not stored contiguously, the chunk size is
configurable (as Alan pointed out).
Increasing the chunk size increases memory usage and decreases the number
of seeks required to
read an object. It does not decease the number of seeks required to write
the object because
we use
Sorry about the empty merge commits.
Figured out the workflow after a break.
Looks like it should be <<= in both cases where e->hits >>= 1 exists.
Let me do some testing.
On Wed, Jan 21, 2015 at 5:57 PM, Zhouhaojun wrote:
> Hi，
>
> That's exactly what i thought. But even if using ">>=" instead of "<<=",
> there still seems to be some inconsistency with the comment ( Acc
I'm with Brian. You need to do this some time with templates and it seems
busy to me. However there are probably exceptions...
On May 21, 2014 2:31 PM, "Brian Geffon" wrote:
> I think this-> is incredibly ugly an unnecessary, what does it really get
> us? It will be become convention just as ap
The fix was to run ldconfig after installing ATS.
john
On Sat, Aug 24, 2013 at 10:25 AM, John Plevyak wrote:
>
> 4.0! Nice.
>
> On Ubuntu 13.04 with gcc 4.8.1
>
> It reports:
>
> sudo /usr/local/bin/trafficserver status
> This script needs to be ported to this OS
4.0! Nice.
On Ubuntu 13.04 with gcc 4.8.1
It reports:
sudo /usr/local/bin/trafficserver status
This script needs to be ported to this OS
Also just running sudo /usr/local/bin/trafficserver start exists with no
error, but ATS not started.
sudo /usr/local/bin/traffic_server
/usr/local/bin/traffi
Nuke it.
On Mon, Jul 29, 2013 at 3:13 PM, Leif Hedstrom wrote:
> Hi all,
>
> long story short, I'd like to nuke the TS_MICRO options, and whatever
> other options that were only exposed through TS_MICRO. I think this is a
> useless feature today, and it doesn't even work (won't build).
>
> Plea
pthread_self() on x86 accesses a register on CPU, so it is quite fast (i.e.
no syscall).
john
On Thu, May 23, 2013 at 11:22 PM, Yunkai Zhang wrote:
> Oh, I read the implementation of pthread_self() in glibc just now, It's
> simple then I guessed,
>
> It seems an overkill optimization. I think
I'll be there, in and out for meetings.
john
On Tue, Apr 23, 2013 at 8:24 PM, Brian Geffon wrote:
> Ill be there, so will Manjesh and Nick Berry.
>
>
> On Apr 23, 2013, at 8:23 PM, Leif Hedstrom wrote:
>
> > On 4/23/13 3:14 PM, Leif Hedstrom wrote:
> >> Hi all,
> >>
> >> With short notice, th
> >> _ink_atomiclist_remove in ink_queue.o
> > >>
> > >> I have an email out to the clang devs, but no response yet.
> > >>
> > >>>
> > >>>
> > >>> Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
>
aligned (16))) head_p;
>
>
> Thanks.
> Brian
>
> On Tue, Mar 19, 2013 at 3:47 PM, John Plevyak wrote:
>
> > I believe the problem is with INK_QUEUE_LD which is not atomic:
> >
> > diff --git a/lib/ts/ink_queue.h b/lib/ts/ink_queue.h
> > index 6ac9945..20fbf9
I believe the problem is with INK_QUEUE_LD which is not atomic:
diff --git a/lib/ts/ink_queue.h b/lib/ts/ink_queue.h
index 6ac9945..20fbf9a 100644
--- a/lib/ts/ink_queue.h
+++ b/lib/ts/ink_queue.h
@@ -72,7 +72,7 @@ extern "C"
#endif
#if TS_HAS_128BIT_CAS
-#define INK_QUEUE_LD(dst,src) *((__int1
Works fine for me on a smoke test +1
On Thu, Mar 14, 2013 at 2:30 PM, Leif Hedstrom wrote:
> This vote (barely!!) passes with 3 +1 votes.
>
> Seriously, we have a real problem if the PMC isn't voting on our release
> candidates. Do we need to extend the release process to 7 days? Obviously a
>
I'd like to see the aio patch. We evaluated several types early on but the
performance was not there and the writes were getting starved. I'd expect
to see lots of testing under various loads and workloads.
On Mar 9, 2013 12:18 AM, "Yongming Zhao" wrote:
> we have three big patches on the way:
Since it it is under the simplified BSD, we can simply not include the
hazard pointer files to avoid any potential problem.
john
On Fri, Mar 8, 2013 at 12:17 PM, Brian Geffon wrote:
> My only concern with concurrencykit is the use of hazard pointers, it's my
> understanding that hazard pointers
+1
On Mar 8, 2013 6:39 AM, "Leif Hedstrom" wrote:
> On 3/8/13 4:24 AM, Theo Schlossnagle wrote:
>
>> Would we consider just pulling in concurrencykit? We'll get this and many
>> other composed primitives from an active community for free.
>>
>
> I discussed this with John a while ago, and we both
I'll take a look. I was thinking we should make this move. Glad to see
it.
On Mar 7, 2013 9:13 PM, "Brian Geffon" wrote:
> Hello all,
>
> So to those of you familiar with the freelists you know that it works this
> way the head pointer uses the upper 16 bits for a version to prevent the
> ABA p
wrote:
> On Sun, Dec 30, 2012 at 1:57 AM, John Plevyak wrote:
>
> > This code in ::put() implements the LRU, and as you can see, it uses the
> > LRU data structure (i.e. simple list from most recently used to least):
> >
> > while (bytes > max_bytes) {
>
This code in ::put() implements the LRU, and as you can see, it uses the
LRU data structure (i.e. simple list from most recently used to least):
while (bytes > max_bytes) {
RamCacheLRUEntry *ee = lru.dequeue();
if (ee)
remove(ee);
else
break;
}
On Sat, Dec 29, 2012 a
I added a bit of a design document.
https://cwiki.apache.org/confluence/display/TS/DiskStorageLayout
I didn't include anything about how the initial CacheKey is generated
because that is a function of HTTP (i.e. what does actually constitute a
"unique" document).
john
On Fri, Dec 21, 2012 at 7:
Unfortunately most of the docs were lost when the code was in storage
before being revived at yahoo. However I can answer questions and try to
do a writeup in my spare time.
On Dec 21, 2012 11:19 AM, "Wei Bo" wrote:
>
>
>
>
> Hi all, Is there a document/notes available describing how the Apache
Very interesting. Any idea as to the cause?
john
On Tue, Jun 19, 2012 at 2:15 PM, Bryan Call wrote:
> Since attachments are stripped out:
>
> http://people.apache.org/~bcall/3.1.3_vs_3.1.4.pdf
>
> -Bryan
>
> On Jun 19, 2012, at 1:58 PM, Bryan Call wrote:
>
> > This is a simple write up I did c
I like this proposal, but I would rather not have a 3.3.x and just freeze
the trunk and only allow commits from patches attached in jira. This would
add extra incentive to get the release out and not check in buggy stuff to
near that date as all your commits will have to go through jira.
john
On
Do we have a list of show stoppers?
On May 12, 2012 4:31 PM, "Leif Hedstrom" wrote:
> On 5/12/12 5:29 PM, Arno Töll wrote:
>
>> Hi,
>> On 13.05.2012 01:24, Leif Hedstrom wrote:
>>
>>> You know what the cutoff time is ?
>>>
>> not exactly, we're awaiting an announcement by the release team in the
I wouldn't mind getting that RAM cache patch in if Bryan is OK with it.
john
On Thu, May 10, 2012 at 1:55 PM, Leif Hedstrom wrote:
> We're so close, please close whatever bugs should be closed for 3.1.4,
> move out whatever should be moved out. We need to get this sucker out, so
> we can make a
OK, then it would seem best to open a bug and attach the file to the bug.
On Sat, Apr 28, 2012 at 10:15 AM, Mladen Turk wrote:
> On 04/28/2012 06:17 PM, John Plevyak wrote:
>
>> I didn't get an attachment. Did anyone else?
>>
>>
> Nope. It's ASF polic
I didn't get an attachment. Did anyone else?
john
On Fri, Apr 27, 2012 at 11:07 AM, taorui wrote:
> the attachment is the results for the mail server not support image.
> On Sat, 2012-04-28 at 02:02 +0800, taorui wrote:
> > Hi, guys, We (taobao.com) did some analysis (include the hotpot and
>
Interesting. Maybe there is a bug in the overflow code. 1/2 is
significant. Is the hot set stable or does it change? Do you fit the
working set? Clubs has more overhead but should be more robust (sans
bugs).
On Apr 27, 2012 4:10 PM, "Bryan Call" wrote:
> I wanted to know if anyone else has d
Great. Then it seems like it is time to make the move into the 21st
century.
john
On Tue, Mar 27, 2012 at 3:46 PM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> I would presume that applies to the functions documented on the page, not
> getaddrinfo which is mentioned only in passing.
Search for the line:
"The lookup functions above all have one in common: they are not reentrant
and therefore unusable in multi-threaded applications. Therefore provides
the GNU C library a new set of functions which can be used in this context."
Perhaps it operates differently if _POSIX_SOURCE i
FYI: According to
http://www.gnu.org/software/libc/manual/html_node/Host-Names.html
The glibc versions of getaddrinfo are still not thread safe.
john
On Mon, Mar 26, 2012 at 7:58 PM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> I filed TS-1166, TS-1167, TS-1168, to track some of th
I really should have looked more closely at what their posts as well. It
took a long time for me to remember how lock switching was supposed to
work. I think it is far too brittle and clearly it was poorly documented.
I am going to add some inline documentation and when I can break some time
awa
I found the problem and it has nothing to do with any of this. The
problem, as quite rightly pointed out by weijin is that when the closed
flag by one thread, another thread can delete the NetVC. This is expected
and desirable, however, unfortunately do_io_close() is accessing the "nh"
variable (
:
IOBufferReader * ua_buffer_reader;
On Sat, Mar 17, 2012 at 10:34 PM, John Plevyak wrote:
>
> RE: TS-857 commented on that with a patch.
> RE: TS-1114, I commented on that. That is a serious bug. We need to get
> that committed.
>
> john
>
>
> On Sat, Mar 17, 2012 at 8:48 P
gt; I am just think of that we try to focus on how to do io_close is far
> away to fix the problem
>
> FYI
>
> 在 2012-03-17六的 20:35 -0700，John Plevyak写道：
> > This makes no sense at all then. If there is no sharing there should be
> > only one thread in play, so there can&#
This makes no sense at all then. If there is no sharing there should be
only one thread in play, so there can't be a thread A and a thread B. I'd
love to know where that other thread comes from. It seems like a deeper
problem. I added asserts a while back to ensure that a transaction stayed
ent
On Thu, Mar 15, 2012 at 11:01 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Thursday, March 15, 2012, 9:26:33 AM, you wrote:
>
> > [The lock] is only de-allocated after the close() by which time all
> > references to that NetVC should have been dropped by the client.
>
> Yes, I unde
On Thu, Mar 15, 2012 at 7:05 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Wednesday, March 14, 2012, 9:29:43 PM, John Plevyak wrote:
>
> > My view is that this is only one of many failure modes, albeit the most
> > common one.
>
> I disagree because
This looks to be superior to that patch, so I would be for replacing that.
I still see this as a quite complicated bandaid, but if it makes things
better in the short term, I am not opposed.
john
On Wed, Mar 14, 2012 at 11:44 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> One thin
HttpServerSession split across threads like that? I
> have no idea. But it seems to happen much more with forward proxy (note: I
> have only indirect evidence for that).
>
I question I have as well. This should not be the case and is going to
cause performance problems. That said, it sho
Here are my comments for what they are worth.
First, let me detail the issue this is trying to address.
The way that most clients work with VCs is via and Processor::open_
which calls back with and OPEN event at which point they set VIOs mutex
field and from this point on, access to the VC is
I think if we switch to fine-grained locking and away from large-grained
try-locks we could deal with the latency issue and get the most out of the
accept thread since we could synchronise between the accept and net threads
faster. This is likely to be easier with a simplified codebase as well.
On
I think Leif has it right about the use cases and meaning of
frequent_accept. Given how much has changed kernel-wise since that code
was originally written, it isn't clear how much we save by limiting some
accepts to a single thread non-blocking (i.e. epoll() makes the marginal
cost of another fd
just wrap some big locks around the problem areas then push them down (a la
multi-threading the FreeBSD kernel). In the short term we will have some
contention problems, but that is better than crashing.
john
On Wed, Dec 14, 2011 at 9:52 AM, Leif Hedstrom wrote:
> On 12/14/11 10:28 AM, J
I have been thinking about this a lot and I think Alan is right. The
locking design of ATS is not appropriate
for an Apache project. The design worked when it was a few full time
people sitting within feet of each
other all day (and chunks of the night) but the world has moved on and we
should
On Tue, Dec 13, 2011 at 3:51 PM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Tuesday, December 13, 2011, 3:30:06 PM, you wrote:
>
> > No other thread can call vc->do_io_close if they don't have the pointer
> to
> > it.
>
> Turns out that at least other thread does have a pointer.
>
This worked for 15 years. This is how Traffic Server was designed and how
it has run for years at AOL with uptime measured in months under very high
load on multi-processors with weaker memory guarantees than x86 (e.g.
Alpha).
Some new bug comes along and suddenly something which has been field t
This is done intentionally. The reason is to catch bugs, not to hide them.
By overwriting the pointer, bugs in client code will be caught faster and
caught in optimized code which is more likely to exhibit race conditions.
It makes working with NetVCs much safer as it helps you find bugs in you
On Mon, Dec 12, 2011 at 7:21 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Friday, December 9, 2011, 5:17:56 PM, you wrote:
>
> > NetHandler::mainNetEvent doesn't lock the VCs because it doesn't need to
> > until it wants to access the internal data at which time it locks it.
> > T
Clearly it should never be the case that the NetVC is deallocated while
still 'in use'.
NetHandler::mainNetEvent doesn't lock the VCs because it doesn't need to
until it wants to access the internal data at which time it locks it.
Therefore the internal data is protected by the NetVC mutex. Howe
RE: specific, could you tell me which bug numbers are addressed by your
changes?
Thanx,
john
On Fri, Dec 9, 2011 at 9:38 AM, John Plevyak wrote:
>
> Could you be more specific about the problem (e.g. big numbers)?
> VConnection locking works fine in all cases that I know of. There a
Could you be more specific about the problem (e.g. big numbers)?
VConnection locking works fine in all cases that I know of. There are
some issues with closing and deallocation with threading and the higher
layers, but these could be solved in a number of ways. Smart pointers is
one (and probabl
Just curious. What evidence do we have that that mutex us a problem?
On Dec 5, 2011 7:24 PM, "ming@gmail.com" wrote:
> we know that Vol locking is the most expensive lock in cache layer, will
> we bind Vol and CPU(or thread) a good idea?
>
>
> --
> zym, Zhao Yongming.
> aka: yonghao @ taobao
I am for git. It is more flexible and faster.
On Nov 25, 2011 12:15 PM, "Leif Hedstrom" wrote:
> Hi all,
>
> There has been a sometimes heated discussion at the ASF over Git vs
> Subversion. I'm not going to reiterate all that here. However, I'd like for
> us to start a discussion whether we wan
Personally, I like your solution. Generally, fewer mutexes are safer, and a
single mutex should be shared over as much of the connection as possible as
acquiring it gives access to all state that it covers. Normally plenty of
parallelism to go around.
john
2011/10/3 Uri Shachar
>
> Hi,
>
>
~10ms on an otherwise idle
> instance. It may also prevent some future "optimizer" from
> re-introducing the bug by removing the interval on the conditional
> wait.
>
> On Sun, Sep 11, 2011 at 4:35 PM, John Plevyak wrote:
> > I don't think so as this shou
I don't think so as this should be self correcting in a busy system
as Bart pointed out; the main concern is initialization or recovery.
I'll take care of this...
john
On Sun, Sep 11, 2011 at 1:59 PM, Leif Hedstrom wrote:
> On 09/10/2011 02:17 PM, John Plevyak wrote:
>
&
re. 10ms seems high.
> <<1ms for SSDs. Perhaps we should optimize for that instead?
>
> On Sat, Sep 10, 2011 at 3:13 PM, John Plevyak wrote:
> > You are right. My preference would be to change this to a
> > pthread_cond_timedwait
> > with a 10 msec timeout (or
You are right. My preference would be to change this to a
pthread_cond_timedwait
with a 10 msec timeout (or somesuch). The rational being that (hard) disk
latency
is in that range in any case and the chance of this happening is rare so
taking
a 10 msec hit would not be the end of the world.
The
I would agree. This "fix" is likely to be very expensive. Each thread is
managing 100s to 1000s of connections, and with
the current connection sharing model, many will be cross thread (a bad
thing). With this "fix" each of those is
going to knock the other thread off the poll loop which result
I am just grumbling ;). ats_ is the way to go. ink is just confusing after
all these years.
On Sep 2, 2011 6:13 PM, "Leif Hedstrom" wrote:
> On Sep 2, 2011, at 6:56 PM, John Plevyak wrote:
>
>> Sorry to chime in on this so late.
>>
>> If the APIs were not alrea
Sorry to chime in on this so late.
If the APIs were not already TSXXX I would have preferred to make the
external ones ats_
and the internal ts_, but now that we are already down the path I agree with
Leif that we should
change all the internal apis to ats_.
The downside is that* ink_ *can be don
Some unix systems will hard spin on a delay of less than 10msec. The result
for a cross thread scheduling couid be that the thread communicated 'to'
might
start immediately and hit the lock held by the 'from' thread before it past
posting
the event. If the 'from' thread didn't initialize some of
+1
verified and smoke tested on fc15
john
On Mon, Aug 22, 2011 at 1:58 PM, Bryan Call wrote:
> +1
>
> - Verified md5, sha1, and pgp signature
> - Built and installed
> - Passed Regression
> - Now running as my forward proxy at home
>
> -Bryan
>
>
> On 08/22/2011 08:15 AM, Leif Hedstrom wrote:
You can look at the VIA header or if use the debug tags : traffic_server
-T"http.*"
Either way, you want to know why ATS thinks it can't cache the docs.
If you use the debug tags, try just hitting it with a single request and
then
repeating it again after a pause as it will print out a trace for
+1
On Mon, Jul 18, 2011 at 5:59 AM, Jim Jagielski wrote:
> +1 (Fed14, OSX)
>
> On Jul 15, 2011, at 9:09 PM, Leif Hedstrom wrote:
>
> > On 07/15/2011 05:12 PM, Igor Galić wrote:
> >> Thanks to Bryan for pointing this out the blindingly obvious number
> >>
> >> I fixed that and rolled the tag.
> >
We need to add TS-833 to that STATUS file...
2011/7/14 Igor Galić
> Hi folks,
>
> with TS-833 and TS-834 fixed, I'd like to
> TR 3.0.1 tomorrow.
>
> Please have a look at the status file, and
> vote on the proposals
>
> http://svn.apache.org/repos/asf/trafficserver/traffic/branches/3.0.x/STATUS
Are you interested in seeking to points in files? That feature is new in
the cache
but not available yet via the API. If that is what you mean, file a bug
and
we will get it into the API.
Thanx,
john
On Tue, Jul 12, 2011 at 2:04 PM, Nelson Perez wrote:
> Hi there, my name is Nelson Pérez and
Do we have a 3.0.1 proposal and list of backports out?
john
On Tue, Jul 12, 2011 at 1:28 AM, ming@gmail.com wrote:
> hi, all
> recently we have identified and fixed 2 critical crashing issues in
> the trunk, these bugs should apply to the crashes on v3.0.0 stable
> release too, if you have
The cache plugin API was incomplete. Parts of it were moved to
proxy/api/ts/experimental and parts were removed or disabled if they
were too broken.
We do plan on having a new cache API, probably for 3.2.
john
2011/6/16 Igor Galić
>
>
> - Original Message -
> > Hi,
> > I was trying to
+1
On Sun, Jun 12, 2011 at 8:06 PM, Leif Hedstrom wrote:
> On 06/09/2011 03:50 PM, Leif Hedstrom wrote:
>
>> Hi all,
>>
>> I've prepared a package for a v3.0.0 release. Please take a look at the
>> artifacts, check the STATUS/README/CHANGES files, and do builds and tests.
>> After finishing your
+1 all round.
cheers,
john
On Wed, Jun 8, 2011 at 8:50 PM, ming@gmail.com wrote:
> cast my vote here:
>
> * Logs: Restore old log buffer size.
>Trunk patch: http://svn.apache.org/viewvc?rev=1131473&view=rev
>Jira: https://issues.apache.org/jira/browse/TS-820
>+1
>
> * SOCKS: As
MB we will remain over 1.25MB and we will write out as
much
as we can. In every case, writing at this point results in a fragment.
>
> On Sun, May 29, 2011 at 12:25 AM, John Plevyak wrote:
>
> > I assume that this is related to the SSD code handling multiple
> > fragments...
&g
I assume that this is related to the SSD code handling multiple fragments...
The default target fragment size is 1MB. This code says that if we have
between 1MB and 1.25MB then write only 1MB as we will be able to use
the fast non-fragmenting buffer freelist to hold the 1MB on read. Lower
than
ed, May 25, 2011 at 11:36 AM, aniket ray wrote:
> On Wed, May 25, 2011 at 8:12 PM, John Plevyak wrote:
> > There is no 64MB freelist unless you have created one yourself. The
> buffer
> > freelists max out at 2MB and unless you are caching files you should not
> see
> > t
There is no 64MB freelist unless you have created one yourself. The buffer
freelists max out at 2MB and unless you are caching files you should not see
them allocated.
john
On Wed, May 25, 2011 at 2:24 AM, aniket ray wrote:
> On Tue, May 24, 2011 at 9:52 PM, Leif Hedstrom wrote:
> > On 05/24/
I really need to generate some documentation on this.
The structure of the cache is a cyclone buffer (circular buffer).
Documents over 2MB are broken into fragments. The 'head'
(which for HTTP includes a vector of headers for the alternate versions
of documents (think encodings in your case) appe
The way the regex query works is that it scans the cache on disk. However,
it does not scan
the write aggregation buffer which is probably where you document is.
You might want to file that as a bug
In the meantime, if you do a Lookup instead of a regex scan it should find
it because tha
Wow, SunOS. That must be one old machine. As an BSD'er was pissed when
Sun
decided to go to Solaris, but I had to give that up a while back.
The best chance you would have would be if you moved to Solaris or Freebsd
on Sparc
and used gcc.
john
On Tue, May 3, 2011 at 3:50 PM, Leif Hedstrom wr
This code is an import from Bind-9.5.2-P2 merged with the old code from
Inktomi days
which was built to interface with an older version of the Bind code. Even
back then it
never had a real "owner", so I am sure that what you see as problems are
problems and
whatever fixes you come up with are most
2011/4/27 ChangCheng
>
> Hi:
> I have some query about mechanisms for save and remove data from cache
> No1:
> I believe there is a big hash table when the TS Running in memory, i would
> like to know when and how TS save this table into disk?
> Does ATS save it into disk when this table changed?
:1185: required file `proxy/config/ssd_storage.config.default.in'
not found
You might be missing a file...
john
On Thu, Apr 21, 2011 at 8:41 AM, 张练 wrote:
>John, i submitted my patch to
> https://issues.apache.org/jira/browse/TS-745, thank for your help.
>
> On Thu, Apr 21, 201
Looking at that web page, I can't see the code. If you post it I can
take a look. The problem is complicated by the fact that deletion
on sata is implicit to some extent because documents are lost
as the write pointer crosses over them. However because they
are scavenged from the directory, it
The Apache Software Foundation and the Apache Traffic Server project are
pleased to announce the release of Apache Traffic Server v2.1.7.
This is a developer release, and might not be 100% stable. However, we
encourage Traffic Server users to download and try our developer releases,
and file bugs
trafficserver-2.1.7-unstable is up on people.apache.org/~jplevyak:
2504699 Mar 17 18:39 trafficserver-2.1.7-unstable.tar.bz2
836 Mar 17 18:39 trafficserver-2.1.7-unstable.tar.bz2.asc
71 Mar 17 18:39 trafficserver-2.1.7-unstable.tar.bz2.md5
79 Mar 17 18:39 trafficserver-2.1.7-unstable.tar.bz2.sha1
#2 is a very viable option and could be implemented relatively easily.
Here is my proposal. Do not attempt to write full objects into the SSD,
instead use it like the RAM cache as a fragment cache. The semantics
of a fragment cache are much easier (i.e. just a simple hash table rather
than havin
esn't cause the writes
to fail. I'll change the error to a Warning, and we can add a reference
to the documentation at some point.
john
On Fri, Mar 11, 2011 at 8:16 PM, Igor Brezac wrote:
> On Fri, Mar 11, 2011 at 6:24 PM, Leif Hedstrom wrote:
> >
> > On 03/11/201
I will answer from the point of view of the cache and perhaps someone else
could answer the more detailed HTTP/1.1
questions which are outside of my expertise.
The cache get's a hash (MD5) (of the URL after some massage I suppose, don't
quote me on that).
It looks it up in a big hash table which g
Each bucket points to a linked list of directory entrys (Dir) which point
to "fragment"s which is a contiguous piece of an "object" or "document".
For performance reasons (to take advantage of the L1 cache) Dir entries
allocated for a bucket are taken first from the other 3 entries in the
bucket.
The largest hardware sector size that the cache supports is 8K.
It seems that Solaris is highly configurable this way and can have a
'hardware'
sector size up to 128k as a configuration option for the OS.
Is this with the new Solaris patch?
What sort of a storage.config and filesystem are you on
Personally I think stl::vector is a horribly designed mess. It pulls in
massive amounts
of garbage in the form of iterators. It has no simple way of doing
operations
like finding a matching element or inserting after an element without
using using
iterators. ::clear() doesn't release storag
+1
On 02/24/11 11:42, Leif Hedstrom wrote:
Hi all,
I'd like to propose a code freeze for v2.1.6 for Sunday, midnight, and
we'll prepare the v2.1.6 release candidate on Monday for vote. Things
not done by this deadline would get pushed out to v2.1.7.
Thoughts?
-- leif
2/22/11 14:27, Nelson Perez wrote:
On Tue, Feb 22, 2011 at 7:15 PM, John Plevyak wrote:
What do you want to do that the cache inspector can't do?
Just play the file. But I guess that Leif's hint would do, since I would be
retrieving the file from cache and then playing it and veri
What do you want to do that the cache inspector can't do?
john
On 02/22/11 11:14, Nelson Perez wrote:
Hi there. Since the last couple of weeks I've been playing around with
Traffic Server. I've compiled and installed the 2.1.5 unstable version and
started to learn more about it.
I'm more inte
+1
On 1/7/2011 5:50 PM, Leif Hedstrom wrote:
> Hi all,
>
> I've prepared a new package for a v2.1.5 release. Please take a look at the
> artifacts, check the STATUS/README/CHANGES files, and do builds and tests.
> After finishing your examination of the release candidate, please cast your
> ±
I agree with the can't fail exception. If the function would
return a constant TS_SUCCESS and it is reasonable that
the user would expect that it would, then it could return
something other than the enum.
If it was me, I would permit exceptions for silly things like
checking the type/non-null o
It has a consistent grammar and we can change it if there is a standard we
should be using.
On Dec 8, 2010 5:15 PM, "Andrew Hsu" wrote:
regression_tests:software_engineering_process::fiber:digestive_track
I found the output under the "compile_4" step of the build. Could we rename
this step to
Rip it out.
Stick with things that will be around for a while like
whitehouse.gov
coke.com
john
On 12/07/10 01:37, ming@gmail.com wrote:
Hi,
the codes have many reference to www.inktomi.com
( http://pastebin.com/wGsUSExZ ), even testing in the DNS module, that
may make some trouble
1 - 100 of 413 matches
Mail list logo
