Re: Question about ATS garbage collector

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

Re: Question about ATS garbage collector

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 <

Re: Question about ATS garbage collector

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

Sorry about the empty merge commits. Figured out the workflow after a break.

Re: 答复: Question about the implementation of CLFUS

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 zhouhao...@huawei.com wrote: Hi， That's exactly what i thought. But even if using = instead of =, there still seems to be some inconsistency with the comment

Re: [RFC] coding style for member variable access

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 bri...@apache.org wrote: I think this- is incredibly ugly an unnecessary, what does it really get us? It will be become

Re: [VOTE] Release v4.0.0

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

Re: [VOTE] Release v4.0.0

The fix was to run ldconfig after installing ATS. john On Sat, Aug 24, 2013 at 10:25 AM, John Plevyak jplev...@gmail.com 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 Also just running

Re: Nuking TS_MICRO

Nuke it. On Mon, Jul 29, 2013 at 3:13 PM, Leif Hedstrom zw...@apache.org 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

Re: [1/3] git commit: Fix bug with 128 bit compare and swap.

: 4a0908314acb301f1e9eb691bbcd8d956e86c321 Parents: 57ffdf5 Author: jplev...@apache.org jplev...@apache.org Authored: Thu Mar 21 10:10:16 2013 -0700 Committer: John Plevyak jplev...@acm.org Committed: Thu Mar 21 10:10:16 2013 -0700

Re: 128bit compare and swap

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)

Re: 128bit compare and swap

))) head_p; Thanks. Brian On Tue, Mar 19, 2013 at 3:47 PM, John Plevyak jplev...@acm.org 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..20fbf9a 100644 --- a/lib/ts/ink_queue.h +++ b/lib/ts

Re: [RESULT] [VOTE] Release v3.3.1

Works fine for me on a smoke test +1 On Thu, Mar 14, 2013 at 2:30 PM, Leif Hedstrom zw...@apache.org 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?

Re: [PROPOSAL] Roadmap toward v3.4.0 release

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 ming@gmail.com wrote: we have three big

Re: TS-1742: Freelists: using 64bit versions w/ double word compare and swap

+1 On Mar 8, 2013 6:39 AM, Leif Hedstrom zw...@apache.org 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

Re: TS-1742: Freelists: using 64bit versions w/ double word compare and swap

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 briangef...@gmail.com wrote: My only concern with concurrencykit is the use of hazard pointers, it's my understanding

Re: TS-1742: Freelists: using 64bit versions w/ double word compare and swap

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 bri...@apache.org 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

Re: Question about RamCacheLRU

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

Re: Question about RamCacheLRU

...@gmail.com wrote: On Sun, Dec 30, 2012 at 1:57 AM, John Plevyak jplev...@acm.org 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) { RamCacheLRUEntry

Re: How disk storage is implemented

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

Re: How disk storage is implemented

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 binary.bo...@live.com wrote: Hi all, Is there a document/notes available describing

Re: Comparison of ATS 3.1.3 and 3.1.4

Very interesting. Any idea as to the cause? john On Tue, Jun 19, 2012 at 2:15 PM, Bryan Call bc...@yahoo-inc.com 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

Re: [PROPOSAL] 3.3.x release processes

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

Re: Lets wrap up 3.1.4

Do we have a list of show stoppers? On May 12, 2012 4:31 PM, Leif Hedstrom l...@ogre.com 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

Re: Lets wrap up 3.1.4

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 zw...@apache.org 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

Re: ATS performance

I didn't get an attachment. Did anyone else? john On Fri, Apr 27, 2012 at 11:07 AM, taorui weilogs...@126.com 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

Re: clfus vs lru testing

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 bc...@yahoo-inc.com wrote: I wanted to know if

Re: Cleaning up ink_gethostbyname_r and ink_gethostbyaddr_r

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 is

Re: Cleaning up ink_gethostbyname_r and ink_gethostbyaddr_r

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.

Re: TS-857 and finer grained locking

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

Re: TS-857 and finer grained locking

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

Re: TS-857 and finer grained locking

: IOBufferReader * ua_buffer_reader; On Sat, Mar 17, 2012 at 10:34 PM, John Plevyak jplev...@acm.org 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 PM, ming@gmail.com

Re: TS-857 and finer grained locking

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

Re: TS-857 and finer grained locking

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

Re: TS-857 and finer grained locking

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't be a thread A and a thread B. I'd love to know

Re: TS-857 and finer grained locking

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 only in the close case is the lock itself

Re: Fast Accept

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

Re: Fast Accept

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.

Re: TS-857, TS-934, TS-1031

10:28 AM, John Plevyak wrote: The old locking system was based on TryLocks which could not be taken forceably. Moreover it depended on very subtle knowledge of which bits of the various data structures where protected by which locks. This is clearly not sustainable, nor is it necessary any

Re: TS-857, TS-934, TS-1031

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

Re: TS-857, TS-934, TS-1031

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

Re: TS-857, TS-934, TS-1031

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 jplev...@acm.org wrote: Could you be more specific about the problem (e.g. big numbers)? VConnection locking works fine in all cases that I know

Re: Vol - CPU hash mapping, good or bad idea?

Just curious. What evidence do we have that that mutex us a problem? On Dec 5, 2011 7:24 PM, ming@gmail.com 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:

Re: SVN vs Git

I am for git. It is more flexible and faster. On Nov 25, 2011 12:15 PM, Leif Hedstrom zw...@apache.org 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

Re: TSContSched on continuations that are called by HttpSM hooks can lead to crashes/odd behavior

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

Re: AIO race condition

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 jplev...@acm.org wrote: I don't think so as this should be self correcting in a busy system as Bart pointed out; the main concern

Re: AIO race condition

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 zw...@apache.org wrote: On 09/10/2011 02:17 PM, John Plevyak wrote

Re: benchmarking 3.1.0 and 3.0.1

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 results

Re: AIO race condition

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

Re: AIO race condition

anymore. 10ms seems high. 1ms for SSDs. Perhaps we should optimize for that instead? On Sat, Sep 10, 2011 at 3:13 PM, John Plevyak jplev...@acm.org wrote: You are right. My preference would be to change this to a pthread_cond_timedwait with a 10 msec timeout (or somesuch). The rational

Re: ink_* - ats_* in the core code

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 zw...@apache.org wrote: On Sep 2, 2011, at 6:56 PM, John Plevyak jplev...@acm.org wrote: Sorry to chime in on this so late. If the APIs were not already TSXXX I

Re: ink_* - ats_* in the core code

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

Re: SEGFAULT on MUTEX_TRY_LOCK_FOR

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

Re: Random access in cached files

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 bilt...@gmail.com wrote: Hi there, my name is

Re: [VOTE] Release Apache Traffic Server v3.0.0

+1 On Sun, Jun 12, 2011 at 8:06 PM, Leif Hedstrom zw...@apache.org 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

Re: [REVIEWS] Four proposed patches for 3.0.0 remaining in queue

+1 all round. cheers, john On Wed, Jun 8, 2011 at 8:50 PM, ming@gmail.com ming@gmail.comwrote: cast my vote here: * Logs: Restore old log buffer size. Trunk patch: http://svn.apache.org/viewvc?rev=1131473view=rev Jira: https://issues.apache.org/jira/browse/TS-820 +1 *

Re: multi-frag in cache

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 jplev...@acm.org wrote: I assume that this is related to the SSD code handling multiple fragments... The default target fragment size is 1MB

Re: multi-frag in cache

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

Re: Is ink_freelist_new thread safe?

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 aniket@gmail.com wrote: On Tue, May 24, 2011 at 9:52 PM, Leif Hedstrom

Re: Is ink_freelist_new thread safe?

, 2011 at 11:36 AM, aniket ray aniket@gmail.com wrote: On Wed, May 25, 2011 at 8:12 PM, John Plevyak jplev...@acm.org 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 them

Re: TS Cache details

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)

Re: a simple plugin that writes to the cache

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

Re: How can TS save and remove object from cache?

2011/4/27 ChangCheng ccai...@msn.com 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

Re: SSD support

/ssd_storage.config.default.in' not found You might be missing a file... john On Thu, Apr 21, 2011 at 8:41 AM, 张练 wahu0315...@gmail.com wrote: John, i submitted my patch to https://issues.apache.org/jira/browse/TS-745, thank for your help. On Thu, Apr 21, 2011 at 5:29 AM, John Plevyak jplev...@acm.org

[ANNOUNCE] Apache Traffic Server 2.1.7-unstable released

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

trafficserver-2.1.7-unstable up on people.apache.org/~jplevyak

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

Re: SSD support

#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

Re: Solaris cache warning / error

, John Plevyak wrote: 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

Re: Solaris cache warning / error

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

Re: The logic structure of class Part in iocore/cache/P_CachePart.h

Each bucket points to a linked list of directory entrys (Dir) which point to fragments 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.

Re: v2.1.6 release

+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

Re: Accessing files stored in cache.db

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

RAM Only Cache was: Re: Accessing files stored in cache.db

Several people have been talking about a RAM-only cache, and I would like to collect those use cases. There is an outstanding issue: https://issues.apache.org/jira/browse/TS-119 If folks with an interest in RAM-only caching could please put there use cases there it would help ensure that

Re: [VOTE] Release Apache Traffic Server v2.1.5

+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 ±/0

Re: [DISCUSS] Change SDK return values?

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

Re: Regression tests

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 andrew...@apache.org wrote: regression_tests:software_engineering_process::fiber:digestive_track I found the output under the compile_4 step of the build. Could we

Re: should we replace www.inktomi.com reference in code?

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

Re: [VOTE] Bylaws proposal

I have a couple concerns. Primarily with Consensus definition. I think we need to say that if you don't respond within a particular time (1 week) then you obtain. I wouldn't want to have folks who have vanished hold up a consensus. Secondly, I am wondering if Majority is the correct way to do

Re: [VOTE] Bylaws proposal

On Mon, Nov 8, 2010 at 1:55 PM, Leif Hedstrom zw...@apache.org wrote: On 11/08/2010 02:27 PM, John Plevyak wrote: I have a couple concerns. Primarily with Consensus definition. I think we need to say that if you don't respond within a particular time (1 week) then you obtain. I

Re: [VOTE] Bylaws proposal

I agree that it could be a problem to have a single veto. Perhaps lazy consensus falling back to 2/3 majority? john On Mon, Nov 8, 2010 at 1:50 PM, Leif Hedstrom zw...@apache.org wrote: Secondly, I am wondering if Majority is the correct way to do a release. Seems to me a release is a

Re: [VOTE] Bylaws proposal

Sounds good to me. john On Mon, Nov 8, 2010 at 3:34 PM, Leif Hedstrom zw...@apache.org wrote: On 11/08/2010 03:41 PM, John Plevyak wrote: I agree that it could be a problem to have a single veto. Perhaps lazy consensus falling back to 2/3 majority? Sounds too complicated IMO. :) We

Re: Bypassing non-HTTP connections

Since ATS supports CONNECT, the codepath should exist for doing the bit proxy, so the trick would be to fall back to it on a mal-formed request john On 11/3/2010 1:17 PM, Alan M. Carroll wrote: I suspect that won't work well. We are concerned about pre-existing network applications

Re: [VOTE] Next stable release version number

[X] Next stable release should be v3.0. +1 I'd like to get the API in order.

Re: Bypassing non-HTTP connections

That is what CONNECT does. Do mean transparently? Maybe fallback on request parse error to bit proxy. On Nov 2, 2010 12:17 PM, Alan M. Carroll a...@network-geographics.com wrote: One issue that has come up for us is tolerating network applications that use port 80 for non-HTTP traffic. What is

Fwd: TS 2.0.1 and 2.1.3-unstable not for production environments?

Can anyone repro the 2.1.3 problem? Leif, is this similar to another problem you have seen? I tried to repro and can't, though to be honest I am not entirely sure I understand the IE 8 scenario. I tried save as... on some largish files... john Original Message Subject: TS

PRELIMINARY trafficserver-2.1.3-unstable bits up on people.apache.org/~jplevyak

Preliminary trafficserver-2.1.3-unstable bit are up on: http://people.apache.org/~jplevyak/ Please take a look/comment/vote. john

UPDATED trafficserver-2.1.3-unstable bits at http://people.apache.org/~jplevyak/

UPDATED trafficserver-2.1.3-unstable bits are up on: http://people.apache.org/~jplevyak/ These fix a configuration issue which caused an assert. Please take a look/comment/vote. john

UPDATED trafficserver-2.1.3-unstable bits at http://people.apache.org/~jplevyak/

UPDATED trafficserver-2.1.3-unstable bits are up on: http://people.apache.org/~jplevyak/ These fix a configuration issue which caused an assert. Please take a look/comment/vote. john

NEW NEW trafficserver-2.1.3-unstable bits at http://people.apache.org/~jplevyak/

NEW NEW trafficserver-2.1.3-unstable bits are up on: http://people.apache.org/~jplevyak/ Regress configuration changes. Please take a look/comment/vote. john

Traffic Server 2.1.3-unstable will be tagged tomorrow morning

Traffic Server 2.1.3-unstable will be tagged tomorrow morning if there are no objections. Please take a look at the release and the CHANGES file. This release is an unstable release and is pressing because of a cache corruption bug in 2.1.2. john

Re: errors and shutdown message in 2.1.2 under load (TS-441)

On 9/20/2010 9:45 PM, Pranav Desai wrote: This is with 2.1.2. Maybe I will try the latest SVN. If you could that would be useful as the disk layout changed a bit when support for 4096 sector size drives was added. Also note that I am testing it with a file based cache. Do you think there

2.1.2 is BROKEN, 2.1.3 will be release this week, in the meantime please use SVN

The subject says it all. 2.1.2 has a cache corruption issue. 2.1.3 will be released as soon as we have cleaned up the buglist, but in the meantime please use the svn version: % svn co https://svn.apache.org/repos/asf/trafficserver/traffic/trunk remember for the svn version you need to do: %

Re: [VOTE] Release candidate for ATS v2.1.2

+1 for 2.0.1 +1 for 2.1.2 john On 8/30/2010 1:00 PM, Eric Balsa wrote: +1 for 2.0.1 +1 for 2.1.2 --Eric On Mon, Aug 30, 2010 at 12:57 PM, Leif Hedstrom zw...@apache.org wrote: On 08/26/2010 10:25 PM, Leif Hedstrom wrote: Hi all, I've prepared a new package for a v2.0.1 release.

Re: ts 2.0.0 failed assert `FATAL: CacheDir.cc:693

OK, this tells me what I need to know. The problem is that the cache is not assuming that you will dump more than 250K or so into a buffer before you call into the cache. The cache can handle long documents, but it assumes that you will hand them over piecemeal in smaller chunks. I am going to

Re: ts 2.0.0 failed assert `FATAL: CacheDir.cc:693

I have created a bug: https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12471346 There is a patch attached. See if that fixes your problem. john On 8/11/2010 11:09 AM, Patrick McManus wrote: On Wed, 2010-08-11 at 13:53 -0400, Patrick McManus wrote: John, thanks for the

Re: Use of STL in ATS

We should add a note to the style guide. I think that the STL/TR1 is fine for non-critical path, but I wouldn't go so far as to rewrite currently working code. The STL tends to hide costs and tends to use algorithms with relatively high constant but low asymptotic costs by default which makes

Re: cache-scan plugin

Just did a checkin on mainline for 64-bit issues which gets the rest of the data to show up. john On 7/9/2010 2:48 AM, Szymon Francuzik wrote: Hi, I tried to use the cache_scan plugin and it seems to not work correctly. When I send a request to /show_cache I receive only first part of

Re: svn commit: r948673 - /trafficserver/traffic/trunk/librecords/RecMessage.cc

Actually (5 + 7) ~7 = 8 So this is 8 byte aligned. john On 5/26/2010 10:19 PM, mt...@apache.org wrote: Author: mturk Date: Thu May 27 05:19:42 2010 New Revision: 948673 URL: http://svn.apache.org/viewvc?rev=948673view=rev Log: TS-376: Fix another wrong alignment calculation.

Re: stdint.h

language... except for all the others. john On 5/18/2010 10:23 PM, Mladen Turk wrote: On 05/19/2010 07:02 AM, John Plevyak wrote: I would say that if we can't find a system which doesn't support the standard %lld for 64-bit numbers then we should just go with the standard. It is simpler

Re: stdint.h please vote

the only standard and universally compatible way to read/write a 64-bit number 4) int64 is similar but not the same as ink64_t and it scans well 5) I tried it and it works! john On 5/19/2010 7:06 AM, Leif Hedstrom wrote: On 05/19/2010 04:17 AM, Mladen Turk wrote: On 05/19/2010 08:25 AM, John Plevyak

  1   2   3   >