date:20130620


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

James Peach commented on TS-1958:
-

I definitely think that this is a useful fix :) I don't think that your 
original patch is correct, because there are cases where repeating the 
vsnprintf is required. I believe that the patch I attached is correct. If you 
can confirm that it fixes your problem, I can propose it for the next 3.2.x 
release.

 admin interface regex lookup seg fault
 --

 Key: TS-1958
 URL: https://issues.apache.org/jira/browse/TS-1958
 Project: Traffic Server
  Issue Type: Bug
  Components: Web UI
Affects Versions: 3.2.4
Reporter: Rejean Bouchard
Assignee: James Peach
 Fix For: 3.3.5

 Attachments: show.h.patch, TS-1958-3.3.x.patch


 there is a possible seg fault (crashing the entire TS) when using a regex 
 lookup form twice to show all cache content.  To reproduce it, do a regex 
 lookup like http://.* twice with a cache containing at least 5000 objects.
 RB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1786) only enable -Werror for debug builds


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

James Peach reassigned TS-1786:
---

Assignee: James Peach

 only enable -Werror for debug builds
 

 Key: TS-1786
 URL: https://issues.apache.org/jira/browse/TS-1786
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.3.5


 It's very difficult to always build with -Werror on every platform we 
 support. -Werror is only valuable to developers, not so much for users. We 
 should consider only enabling -Werror if the build was configured with 
 --enable-debug. This probably involves adding autoconf macros to test whether 
 the compiler actually supports -Werror.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1786) only enable -Werror for debug builds


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

James Peach commented on TS-1786:
-

I have a patch for this.

 only enable -Werror for debug builds
 

 Key: TS-1786
 URL: https://issues.apache.org/jira/browse/TS-1786
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.3.5


 It's very difficult to always build with -Werror on every platform we 
 support. -Werror is only valuable to developers, not so much for users. We 
 should consider only enabling -Werror if the build was configured with 
 --enable-debug. This probably involves adding autoconf macros to test whether 
 the compiler actually supports -Werror.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-1962) keepalive post issues

2013-06-20 Thread Thomas Jackson (JIRA)

Thomas Jackson created TS-1962:
--

 Summary: keepalive post issues
 Key: TS-1962
 URL: https://issues.apache.org/jira/browse/TS-1962
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson


I've been running ATS at the edge with keepalive enabled. After some digging I 
found that ATS creates new connections (by default) for all post requests, 
instead of re-using a connection. The comment in the code looks like this was 
(is?) because of some race condition inside ATS. I noticed that there is a 
config option (proxy.config.http.keep_alive_ post_out) which enables the 
connection re-use for post requests, and it seems to work. Does anyone have any 
knowledge/experience with this configuration option? Or anything about this 
race condition?

In addition to the possible bug, if you leave it on the default (new connection 
per post) it returns the connection to the keep alive pool and I notice 10x 
latency on all post requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1962) keepalive post issues


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

Leif Hedstrom updated TS-1962:
--

Fix Version/s: 3.3.5

 keepalive post issues
 -

 Key: TS-1962
 URL: https://issues.apache.org/jira/browse/TS-1962
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson
 Fix For: 3.3.5


 I've been running ATS at the edge with keepalive enabled. After some digging 
 I found that ATS creates new connections (by default) for all post requests, 
 instead of re-using a connection. The comment in the code looks like this was 
 (is?) because of some race condition inside ATS. I noticed that there is a 
 config option (proxy.config.http.keep_alive_ post_out) which enables the 
 connection re-use for post requests, and it seems to work. Does anyone have 
 any knowledge/experience with this configuration option? Or anything about 
 this race condition?
 In addition to the possible bug, if you leave it on the default (new 
 connection per post) it returns the connection to the keep alive pool and I 
 notice 10x latency on all post requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1963) upgrade the version number for cache between 3.2.0 and 3.4.0


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

Bryan Call updated TS-1963:
---

Affects Version/s: 3.3.4

 upgrade the version number for cache between 3.2.0 and 3.4.0
 

 Key: TS-1963
 URL: https://issues.apache.org/jira/browse/TS-1963
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Affects Versions: 3.3.4
Reporter: Bryan Call

 If you don't remove the cache between versions I have seen weird behavior on 
 trying to get locks for reading from cache:
 perf top output:
 {code}
 Samples: 379K of event 'cycles', Event count (approx.): 159277054084
  20.54%  libpthread-2.12.so[.] pthread_mutex_trylock
  10.59%  traffic_server[.] CacheVC::openReadStartHead(int, Event*)
   5.49%  traffic_server[.] 
 MutexTryLock::MutexTryLock(ProxyMutex*, EThread*)
   3.39%  libtsutil.so.3[.] ink_freelist_new
   3.17%  traffic_server[.] EThread::process_event(Event*, int)
   3.06%  [kernel]  [k] _spin_lock_bh
   2.56%  libtsutil.so.3[.] ink_freelist_free
   1.48%  [kernel]  [k] _spin_lock
   1.46%  traffic_server[.] EThread::execute()
   1.44%  libpthread-2.12.so[.] pthread_mutex_unlock
   1.33%  [kernel]  [k] copy_user_generic_string
   1.22%  traffic_server[.] PtrProxyMutex::operator=(ProxyMutex*)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-1963) upgrade the version number for cache between 3.2.0 and 3.4.0

Bryan Call created TS-1963:
--

 Summary: upgrade the version number for cache between 3.2.0 and 
3.4.0
 Key: TS-1963
 URL: https://issues.apache.org/jira/browse/TS-1963
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Reporter: Bryan Call


If you don't remove the cache between versions I have seen weird behavior on 
trying to get locks for reading from cache:

perf top output:
{code}
Samples: 379K of event 'cycles', Event count (approx.): 159277054084
 20.54%  libpthread-2.12.so[.] pthread_mutex_trylock
 10.59%  traffic_server[.] CacheVC::openReadStartHead(int, Event*)
  5.49%  traffic_server[.] MutexTryLock::MutexTryLock(ProxyMutex*, 
EThread*)
  3.39%  libtsutil.so.3[.] ink_freelist_new
  3.17%  traffic_server[.] EThread::process_event(Event*, int)
  3.06%  [kernel]  [k] _spin_lock_bh
  2.56%  libtsutil.so.3[.] ink_freelist_free
  1.48%  [kernel]  [k] _spin_lock
  1.46%  traffic_server[.] EThread::execute()
  1.44%  libpthread-2.12.so[.] pthread_mutex_unlock
  1.33%  [kernel]  [k] copy_user_generic_string
  1.22%  traffic_server[.] PtrProxyMutex::operator=(ProxyMutex*)
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1963) upgrade the version number for cache between 3.2.0 and 3.4.0


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

Bryan Call updated TS-1963:
---

Fix Version/s: 3.3.5

 upgrade the version number for cache between 3.2.0 and 3.4.0
 

 Key: TS-1963
 URL: https://issues.apache.org/jira/browse/TS-1963
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Affects Versions: 3.3.4
Reporter: Bryan Call
 Fix For: 3.3.5


 If you don't remove the cache between versions I have seen weird behavior on 
 trying to get locks for reading from cache:
 perf top output:
 {code}
 Samples: 379K of event 'cycles', Event count (approx.): 159277054084
  20.54%  libpthread-2.12.so[.] pthread_mutex_trylock
  10.59%  traffic_server[.] CacheVC::openReadStartHead(int, Event*)
   5.49%  traffic_server[.] 
 MutexTryLock::MutexTryLock(ProxyMutex*, EThread*)
   3.39%  libtsutil.so.3[.] ink_freelist_new
   3.17%  traffic_server[.] EThread::process_event(Event*, int)
   3.06%  [kernel]  [k] _spin_lock_bh
   2.56%  libtsutil.so.3[.] ink_freelist_free
   1.48%  [kernel]  [k] _spin_lock
   1.46%  traffic_server[.] EThread::execute()
   1.44%  libpthread-2.12.so[.] pthread_mutex_unlock
   1.33%  [kernel]  [k] copy_user_generic_string
   1.22%  traffic_server[.] PtrProxyMutex::operator=(ProxyMutex*)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1963) upgrade the version number for cache between 3.2.x and 3.4.x


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

Bryan Call updated TS-1963:
---

Summary: upgrade the version number for cache between 3.2.x and 3.4.x  
(was: upgrade the version number for cache between 3.2.0 and 3.4.0)

 upgrade the version number for cache between 3.2.x and 3.4.x
 

 Key: TS-1963
 URL: https://issues.apache.org/jira/browse/TS-1963
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Affects Versions: 3.3.4
Reporter: Bryan Call
 Fix For: 3.3.5


 If you don't remove the cache between versions I have seen weird behavior on 
 trying to get locks for reading from cache:
 perf top output:
 {code}
 Samples: 379K of event 'cycles', Event count (approx.): 159277054084
  20.54%  libpthread-2.12.so[.] pthread_mutex_trylock
  10.59%  traffic_server[.] CacheVC::openReadStartHead(int, Event*)
   5.49%  traffic_server[.] 
 MutexTryLock::MutexTryLock(ProxyMutex*, EThread*)
   3.39%  libtsutil.so.3[.] ink_freelist_new
   3.17%  traffic_server[.] EThread::process_event(Event*, int)
   3.06%  [kernel]  [k] _spin_lock_bh
   2.56%  libtsutil.so.3[.] ink_freelist_free
   1.48%  [kernel]  [k] _spin_lock
   1.46%  traffic_server[.] EThread::execute()
   1.44%  libpthread-2.12.so[.] pthread_mutex_unlock
   1.33%  [kernel]  [k] copy_user_generic_string
   1.22%  traffic_server[.] PtrProxyMutex::operator=(ProxyMutex*)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1958) admin interface regex lookup seg fault

2013-06-20 Thread Rejean Bouchard (JIRA)

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

Rejean Bouchard commented on TS-1958:
-

Which Git version did you use. I want to have the same one to test it.

Thank you!.
RBouchard

-Message d'origine-
De : James Peach (JIRA) [mailto:j...@apache.org]
Envoyé : 20 juin 2013 11:39
À : rbouch...@nexweb.ca
Objet : [jira] [Commented] (TS-1958) admin interface regex lookup seg fault

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

James Peach commented on TS-1958:
-

I definitely think that this is a useful fix :) I don't think that your
original patch is correct, because there are cases where repeating the
vsnprintf is required. I believe that the patch I attached is correct. If you
can confirm that it fixes your problem, I can propose it for the next 3.2.x
release.

admin interface regex lookup seg fault
--

Attachments: show.h.patch, TS-1958-3.3.x.patch

[jira] [Commented] (TS-1958) admin interface regex lookup seg fault


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

James Peach commented on TS-1958:
-



The patch is against the 3.2.x branch, commit 
9f8195f443e1e16862cbb7abc0497ec64dafd025.

J


 admin interface regex lookup seg fault
 --

 Key: TS-1958
 URL: https://issues.apache.org/jira/browse/TS-1958
 Project: Traffic Server
  Issue Type: Bug
  Components: Web UI
Affects Versions: 3.2.4
Reporter: Rejean Bouchard
Assignee: James Peach
 Fix For: 3.3.5

 Attachments: show.h.patch, TS-1958-3.3.x.patch


 there is a possible seg fault (crashing the entire TS) when using a regex 
 lookup form twice to show all cache content.  To reproduce it, do a regex 
 lookup like http://.* twice with a cache containing at least 5000 objects.
 RB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1695) test_certlookup fails on FreeBSD 10


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

James Peach updated TS-1695:


Summary: test_certlookup fails on FreeBSD 10  (was: test_certlookup fails 
on FreeBSD)

 test_certlookup fails on FreeBSD 10
 ---

 Key: TS-1695
 URL: https://issues.apache.org/jira/browse/TS-1695
 Project: Traffic Server
  Issue Type: Bug
  Components: Portability
 Environment: FreeBSD 10, amd64
Reporter: Igor Galić
Assignee: James Peach
  Labels: freebsd
 Fix For: 3.3.6


 {noformat}
 Reading symbols from 
 /tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
 [New process 100244]
 [New Thread 803806400 (LWP 100244)]
 Core was generated by `test_certlookup'.
 Program terminated with signal 10, Bus error.
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 (gdb) bt
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 #1  0x000802cc8c74 in free () from /lib/libc.so.7
 #2  0x00405ca6 in TrieSSLContextStorage::SSLEntry::Clear 
 (this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
 #3  0x00405d21 in TrieSSLContextStorage::SSLEntry::~Trie 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
 #4  0x00403c11 in SSLContextStorage::~SSLContextStorage 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
 #5  0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0, 
 __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
 #6  0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0 
 regressionTest_SSLCertificateLookup, atype=0, pstatus=0x60dab8 
 regressionTest_SSLCertificateLookup+24)
 at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
 #7  0x00080085eff6 in start_test (t=0x60daa0 
 regressionTest_SSLCertificateLookup) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
 #8  0x00080085f404 in RegressionTest::run (atest=0x0) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
 #9  0x00402ce0 in main (argc=1, argv=0x7fffd470) at 
 /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
 (gdb)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1666) gzip plugin crash report

2013-06-20 Thread Zhao Yongming (JIRA)


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

Zhao Yongming commented on TS-1666:
---

please try with  proxy.config.http.share_server_sessions=1

 gzip plugin crash report
 

 Key: TS-1666
 URL: https://issues.apache.org/jira/browse/TS-1666
 Project: Traffic Server
  Issue Type: Bug
  Components: MIME, Plugins
Reporter: Otto van der Schaaf
Assignee: Otto van der Schaaf
  Labels: crash
 Fix For: sometime


 ibrezac dumped this trace on irc:
 [Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15], 
 logging_mode = 3
 [Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin 
 '/usr/lib/trafficserver/modules/gzip.so'
 [Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
 [Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/bin/traffic_server - STACK TRACE: 
 /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
 /usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
 /usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
 /usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
 /usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
 /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
 /usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
 /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
 /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
 /usr/bin/traffic_server(main+0x160f)[0x48022f]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
 /usr/bin/traffic_server[0x4855fd]
 [Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR: 
 [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
 11: Segmentation fault
 [Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR:  (last system error 2: 
 No such file or directory)
 [Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm] 
 Server Process was reset
 [Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR:  (last system error 2: 
 No such file or directory)
 [Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE: 
 [LocalManager::startProxy] Launching ts process
 [TrafficServer] using root directory '/usr'
 configuration used:
 cache true
 enabled true
 remove-accept-encoding false
 compressible-content-type text/*
 compressible-content-type *javascript*
 === misc info
 TS Version 3.2.4
 Running at around 50 qps
 crashes every 10 seconds
 == c++filt stack trace
 /usr/bin/traffic_server - STACK TRACE: 
 /lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
 /usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int) 
 0x152)[0x5c27f2]
 /usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
  0xe1)[0x545571]
 /usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
  0x122)[0x553112]
 /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
 (*)(HttpTransact::State*)) 0x28)[0x526df8]
 /usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int, 
 void*) 0xed)[0x52ba2d]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
 /usr/bin/traffic_server(TransformTerminus::handle_event(int, void*) 
 0x272)[0x4e7402]
 /usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
 /usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
 /usr/bin/traffic_server(main 0x160f)[0x48022f]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-1964) Make Accept threads NUMA aware

Leif Hedstrom created TS-1964:
-

 Summary: Make Accept threads NUMA aware
 Key: TS-1964
 URL: https://issues.apache.org/jira/browse/TS-1964
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Leif Hedstrom


To work efficiently, we should have one (or several) accept threads per NUMA 
node. In addition, it should schedule the VCs on ET_NET threads that are 
assigned to the same NUMA node. This assures that memory allocated for the VC 
stays on the same NUMA node.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1964) Make Accept threads NUMA aware


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

Leif Hedstrom updated TS-1964:
--

Fix Version/s: 3.5.0
   Labels: NUMA  (was: )

 Make Accept threads NUMA aware
 --

 Key: TS-1964
 URL: https://issues.apache.org/jira/browse/TS-1964
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Leif Hedstrom
  Labels: NUMA
 Fix For: 3.5.0


 To work efficiently, we should have one (or several) accept threads per NUMA 
 node. In addition, it should schedule the VCs on ET_NET threads that are 
 assigned to the same NUMA node. This assures that memory allocated for the VC 
 stays on the same NUMA node.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1965) Make IO threads NUMA aware


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

Leif Hedstrom updated TS-1965:
--

Fix Version/s: 3.5.0
   Labels: NUMA  (was: )

 Make IO threads NUMA aware
 --

 Key: TS-1965
 URL: https://issues.apache.org/jira/browse/TS-1965
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Leif Hedstrom
  Labels: NUMA
 Fix For: 3.5.0


 To avoid cross QPI communications on systems with multiple NUMA nodes, it 
 might make sense to have AIO threads assigned to NUMA nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-1965) Make IO threads NUMA aware

Leif Hedstrom created TS-1965:
-

 Summary: Make IO threads NUMA aware
 Key: TS-1965
 URL: https://issues.apache.org/jira/browse/TS-1965
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Leif Hedstrom


To avoid cross QPI communications on systems with multiple NUMA nodes, it might 
make sense to have AIO threads assigned to NUMA nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-1966) Make ProxyAllocator slot size configurable