You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@trafficserver.apache.org by James Peach <jp...@apache.org> on 2013/10/27 06:42:14 UTC

ProxyConfig regression tests

Hi all,

The problem with the failing tests in jeknins is the ProxyConfig_Set and ProxyConfig_Release tests. ProxyConfig_Set isn't failing but it exhibits the same behaviour as ProxyConfig_Release so it would be failing if it were more carefully written.

The root cause of the failure is that we make a sequence of eventProcessor.schedule_in() calls, but only the first couple of events appear to fire. For example, in ProxyConfig_Release, we call ConfigProcessor::set() 4 times, but only the first one or two events actually fire. I'd be surprised if this were a bug in the event system, so maybe I'm doing it wrong somehow?

J

Re: ProxyConfig regression tests

Posted by James Peach <jp...@apache.org>.

On Oct 26, 2013, at 10:42 PM, James Peach <jp...@apache.org> wrote:

> Hi all,
> 
> The problem with the failing tests in jeknins is the ProxyConfig_Set and ProxyConfig_Release tests. ProxyConfig_Set isn't failing but it exhibits the same behaviour as ProxyConfig_Release so it would be failing if it were more carefully written.
> 
> The root cause of the failure is that we make a sequence of eventProcessor.schedule_in() calls, but only the first couple of events appear to fire. For example, in ProxyConfig_Release, we call ConfigProcessor::set() 4 times, but only the first one or two events actually fire. I'd be surprised if this were a bug in the event system, so maybe I'm doing it wrong somehow?

Pretty sure that this happens when the host is a single-core. Probably need to refactor the tests to not hold down an event thread ...

J