[jira] [Assigned] (TS-698) LogFilter should support an actual IP type and matching rules

2011-10-14 Thread Alan M. Carroll (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan M. Carroll reassigned TS-698:
--

Assignee: Alan M. Carroll

 LogFilter should support an actual IP type and matching rules
 -

 Key: TS-698
 URL: https://issues.apache.org/jira/browse/TS-698
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Affects Versions: 2.1.6
 Environment: N/A
Reporter: Eric Connell
Assignee: Alan M. Carroll
Priority: Minor
 Fix For: 3.3.0


 The LogFilter configuration in logs_xml.config should support a native IPv4 
 and IPv6 filtering.  For example, it would be handy to be able to filter out 
 log lines from a specific server or netblock.  For example, the following 
 config would reject log lines for all hosts in the 10/8 network:
 {code}
 LogFilter
 Name = local_net/
 Condition = chi MATCH 10.0.0.0/8/
 Action = REJECT/
 /LogFilter 
   
 LogFormat
   Name = access_log/
   Format = %shi/
 /LogFormat 
 LogObject 
   Format = access_log/
   Filename = access_log/
   Filters = local_net/
 /LogObject 
 {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-928) Compile problem in TsErrataUtil on FreeBSD 8

2011-10-14 Thread Alan M. Carroll (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan M. Carroll updated TS-928:
---

Fix Version/s: (was: 3.1.1)
   3.1.2

 Compile problem in TsErrataUtil on FreeBSD 8
 

 Key: TS-928
 URL: https://issues.apache.org/jira/browse/TS-928
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Affects Versions: 3.0.1
 Environment: FreeBSD 8.2, 32-bit, gcc (GCC) 4.2.1 20070719 
Reporter: Radim Kolar
Assignee: Alan M. Carroll
  Labels: build-failure, freebsd, wccp
 Fix For: 3.1.2


 TF with --enable-wccp do not compile on FreeBSD. I have gnu sed, flex and 
 bison updated to their latest versions.
 /bin/sh ../../libtool --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I. 
 -I../../lib/ts  -I../../lib -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 
 -D_GNU_SOURCE -D_REENTRANT -Dfreebsd -I/usr/local/include 
 -I/usr/local/include/tcl8.5  -O2 -pipe -march=prescott -fno-strict-aliasing 
 -march=i586 -g -Wall -Werror -O3 -feliminate-unused-debug-symbols 
 -Wno-invalid-offsetof -MT TsErrataUtil.lo -MD -MP -MF .deps/TsErrataUtil.Tpo 
 -c -o TsErrataUtil.lo TsErrataUtil.cc
 libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib 
 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT 
 -Dfreebsd -I/usr/local/include -I/usr/local/include/tcl8.5 -O2 -pipe 
 -march=prescott -fno-strict-aliasing -march=i586 -g -Wall -Werror -O3 
 -feliminate-unused-debug-symbols -Wno-invalid-offsetof -MT TsErrataUtil.lo 
 -MD -MP -MF .deps/TsErrataUtil.Tpo -c TsErrataUtil.cc  -fPIC -DPIC -o 
 .libs/TsErrataUtil.o
 cc1plus: warnings being treated as errors
 TsErrataUtil.cc: In function 'ts::Errata ts::msg::vlogf_errno(ts::Errata, 
 ts::NumericTypeunsigned int, ts::MsgIdTag, ts::NumericTypeunsigned int, 
 ts::CodeTag, const char*, char*)':
 TsErrataUtil.cc:143: warning: format '%s' expects type 'char*', but argument 
 5 has type 'int'
 TsErrataUtil.cc:143: warning: format '%s' expects type 'char*', but argument 
 5 has type 'int'
 gmake[3]: *** [TsErrataUtil.lo] Error 1
 gmake[3]: Leaving directory 
 `/home/hsn/ports/trafficserver/work/trafficserver-3.0.1/lib/tsconfig'
 gmake[2]: *** [all] Error 2
 gmake[2]: Leaving directory 
 `/home/hsn/ports/trafficserver/work/trafficserver-3.0.1/lib/tsconfig'
 gmake[1]: *** [all-recursive] Error 1
 gmake[1]: Leaving directory 
 `/home/hsn/ports/trafficserver/work/trafficserver-3.0.1/lib'
 gmake: *** [all-recursive] Error 1
 *** Error code 1
 Stop in /home/hsn/ports/trafficserver.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable

2011-10-14 Thread weijin (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128043#comment-13128043
 ] 

weijin commented on TS-980:
---

http_sm can be callback by different threads even use share sessions in thread 
mode. in most cases, the callbacks happends in one thread, there may come up an 
exception when http_sms(different threads) do the dns query in the same time. 
Through the sources, I found HostDBContinuation::remove_trigger_pending_dns can 
callsback http_sm which was created by other threads. This is an extreme 
condition and have little effect on performance. I also give a patch on this 
ticket because it takes me 3 days to figure out the reason. 

 change client_session schedule from global  to thread local, and reduce the 
 try_locks in UnixNetVConnection::reenable
 -

 Key: TS-980
 URL: https://issues.apache.org/jira/browse/TS-980
 Project: Traffic Server
  Issue Type: Improvement
  Components: Network, Performance
Affects Versions: 3.1.0, 3.0.0
 Environment: all
Reporter: weijin
Assignee: weijin
 Fix For: 3.1.2


 I did some performance test on ats last days(disable cache, set share_server 
 session 2, pure proxy mode), I did see significant improvement on low load, 
 but it dropped rapidly when load is high. meanwhile, some stability problems 
 happened. Through gdb, I found the client_session`s mutex can be acquired by 
 two or more threads, I believe some schedules happened during the sm 
 life_time. May be we need do some work to find these eventProcessor.schedules 
 and change them to thread schedules.
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list
 } else {
MUTEX_TRY_LOCK(lock, nh-mutex, t);
if (!lock) {
  // put into enable_list;
} else {
  // put into ready_list;
}
 }
 remove UnixNetVConnection::reenable try_lock operations, 3 reasons
 1. try_lock operation means obj allocation and deallocation operation. 
 frequently
 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule 
 by as soon as possible)
 3. try_lock should not acquire the net-handler`s mutex. That may lead more 
 net io latency if it is an epoll event need to be processed in other threads. 
 If it is not an epoll event(time event), I don`t think putting vc in 
 ready_list has any advantage than in enable_list.
 may be we can change reenale function like this:
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list;
 } else {
   // put into enable_list;
 }
 my buddies, any advice?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira