[jira] [Updated] (TS-1256) Streamline usage of PATH_NAME_MAX
[
https://issues.apache.org/jira/browse/TS-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Shachar updated TS-1256:
Description:
There are right now two different usages of the constant {{PATH_NAME_MAX}} in
variable declarations:
{code}
char foo[PATH_NAME_MAX];
{code}
and
{code}
char bar[PATH_NAME_MAX + 1];
{code}
Since we define what {{PATH_NAME_MAX}} is ourselves, we should streamline our
code to only use the first kind of declaration.
was:
There are right now two different usages of the constant {{PATH_NAME_MAX}} in
variable declarations:
{code:c}
char foo[PATH_NAME_MAX];
{code}
and
{code:c}
char bar[PATH_NAME_MAX + 1];
{code}
Since we define what {{PATH_NAME_MAX}} is ourselves, we should streamline our
code to only use the first kind of declaration.
> Streamline usage of PATH_NAME_MAX
> -
>
> Key: TS-1256
> URL: https://issues.apache.org/jira/browse/TS-1256
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
>Reporter: Igor Galić
> Fix For: 3.5.0
>
>
> There are right now two different usages of the constant {{PATH_NAME_MAX}} in
> variable declarations:
> {code}
> char foo[PATH_NAME_MAX];
> {code}
> and
> {code}
> char bar[PATH_NAME_MAX + 1];
> {code}
> Since we define what {{PATH_NAME_MAX}} is ourselves, we should streamline our
> code to only use the first kind of declaration.
--
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-1748) add jtest to the build
[ https://issues.apache.org/jira/browse/TS-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603988#comment-13603988 ] ASF subversion and git services commented on TS-1748: - Commit 70f224da68b0d9f6f5d44ede156198d6d34e6c83 in branch refs/heads/master from James Peach [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=70f224d ] TS-1748: fix jtest build warnings > add jtest to the build > -- > > Key: TS-1748 > URL: https://issues.apache.org/jira/browse/TS-1748 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > jtest is a useful test tool. Add it to the build so that it's always > available. -- 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-1633) add new stat sync type: TS_STAT_SYNC_MAX
[ https://issues.apache.org/jira/browse/TS-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-1633: --- Assignee: Uri Shachar > add new stat sync type: TS_STAT_SYNC_MAX > > > Key: TS-1633 > URL: https://issues.apache.org/jira/browse/TS-1633 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Reporter: Yakov Kopel >Assignee: Uri Shachar > Fix For: 3.3.4 > > Attachments: stat_max_ver_1.diff > > > Adding a new stat sync type - max. > This is a good type of stat to find peaks in the stats. > It can be very useful with the stat clear api (after the fix - TS-1631). -- 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-1746) Crash report: UnixNetVConnection::reenable > ink_atomiclist_push > ink_atomic_cas
[
https://issues.apache.org/jira/browse/TS-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603828#comment-13603828
]
Brian Geffon commented on TS-1746:
--
Ok, I might need to enlist your help with figuring this out. I suspect it
should be as straight forward as changing mallocs to memaligns, but I'm not
entirely sure.
> Crash report: UnixNetVConnection::reenable > ink_atomiclist_push >
> ink_atomic_cas
> --
>
> Key: TS-1746
> URL: https://issues.apache.org/jira/browse/TS-1746
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Zhao Yongming
>Assignee: Brian Geffon
>
> I think the recent changes cause this crash, and here is the stack trace:
> {code}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x72492700 (LWP 23610)]
> 0x77bb30a5 in ink_atomic_cas<__int128> (mem=0x73cae288,
> prev=0x0001,
> next=0x7fffd4014501)
> at ink_atomic.h:153
> 153 return __sync_bool_compare_and_swap(mem, prev, next);
> (gdb) bt
> #0 0x77bb30a5 in ink_atomic_cas<__int128> (mem=0x73cae288,
> prev=0x0001,
> next=0x7fffd4014501)
> at ink_atomic.h:153
> #1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
> item=0x7fffd4014500) at ink_queue.cc:481
> #2 0x006d8961 in AtomicSLL UnixNetVConnection::Link_read_enable_link>::push (this=0x73cae288,
> c=0x7fffd4014500)
> at ../../lib/ts/List.h:477
> #3 0x006d6767 in UnixNetVConnection::reenable (this=0x7fffd4014500,
> vio=0x7fffd4014610) at UnixNetVConnection.cc:721
> #4 0x005195d5 in VIO::reenable (this=0x7fffd4014610) at
> ../iocore/eventsystem/P_VIO.h:124
> #5 0x005c73b1 in HttpTunnel::consumer_handler (this=0x7fffdbefb888,
> event=101, c=0x7fffdbefb8c8) at HttpTunnel.cc:1237
> #6 0x005c7c1f in HttpTunnel::main_handler (this=0x7fffdbefb888,
> event=101, data=0x7fffc4008870) at HttpTunnel.cc:1481
> #7 0x004f8aa6 in Continuation::handleEvent (this=0x7fffdbefb888,
> event=101, data=0x7fffc4008870) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0050a612 in TSContCall (contp=0x7fffdbefb888,
> event=TS_EVENT_VCONN_WRITE_READY, edata=0x7fffc4008870) at InkAPI.cc:4400
> #9 0x0055f302 in handle_transform (contp=0x7fffc40087c0) at
> InkAPITest.cc:6435
> #10 0x0055f4be in transformtest_transform (contp=0x7fffc40087c0,
> event=TS_EVENT_IMMEDIATE, edata=0x1166920) at InkAPITest.cc:6501
> #11 0x00501922 in INKVConnInternal::handle_event
> (this=0x7fffc40087c0, event=1, edata=0x1166920) at InkAPI.cc:1045
> #12 0x004f8aa6 in Continuation::handleEvent (this=0x7fffc40087c0,
> event=1, data=0x1166920) at ../iocore/eventsystem/I_Continuation.h:146
> #13 0x006f823d in EThread::process_event (this=0x73aa9010,
> e=0x1166920, calling_code=1) at UnixEThread.cc:142
> #14 0x006f8491 in EThread::execute (this=0x73aa9010) at
> UnixEThread.cc:193
> #15 0x006f744c in spawn_thread_internal (a=0x1090810) at Thread.cc:88
> #16 0x7793dea7 in start_thread () from /lib64/libpthread.so.0
> #17 0x751c114d in clone () from /lib64/libc.so.6
> (gdb) l
> 148 // ink_atomic_cas(mem, prev, next)
> 149 // Atomically store the value @next into the pointer @mem, but only
> if the current value at @mem is @prev.
> 150 // Returns true if @next was successfully stored.
> 151 template static inline bool
> 152 ink_atomic_cas(volatile T * mem, T prev, T next) {
> 153 return __sync_bool_compare_and_swap(mem, prev, next);
> 154 }
> 155
> 156 // ink_atomic_increment(ptr, count)
> 157 // Increment @ptr by @count, returning the previous value.
> (gdb) f 1
> #1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
> item=0x7fffd4014500) at ink_queue.cc:481
> 481result = ink_atomic_cas((__int128_t*) & l->head, head.data,
> item_pair.data);
> (gdb) p head.data
> $1 = 0x0001
> (gdb) p head
> $2 = {s = {pointer = 0x1, version = 0}, data =
> 0x0001}
> (gdb)
> {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-1746) Crash report: UnixNetVConnection::reenable > ink_atomiclist_push > ink_atomic_cas
[
https://issues.apache.org/jira/browse/TS-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603820#comment-13603820
]
James Peach commented on TS-1746:
-
No, but let's prioritize this and make sure that the code is doing the right
thing.
> Crash report: UnixNetVConnection::reenable > ink_atomiclist_push >
> ink_atomic_cas
> --
>
> Key: TS-1746
> URL: https://issues.apache.org/jira/browse/TS-1746
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Zhao Yongming
>Assignee: Brian Geffon
>
> I think the recent changes cause this crash, and here is the stack trace:
> {code}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x72492700 (LWP 23610)]
> 0x77bb30a5 in ink_atomic_cas<__int128> (mem=0x73cae288,
> prev=0x0001,
> next=0x7fffd4014501)
> at ink_atomic.h:153
> 153 return __sync_bool_compare_and_swap(mem, prev, next);
> (gdb) bt
> #0 0x77bb30a5 in ink_atomic_cas<__int128> (mem=0x73cae288,
> prev=0x0001,
> next=0x7fffd4014501)
> at ink_atomic.h:153
> #1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
> item=0x7fffd4014500) at ink_queue.cc:481
> #2 0x006d8961 in AtomicSLL UnixNetVConnection::Link_read_enable_link>::push (this=0x73cae288,
> c=0x7fffd4014500)
> at ../../lib/ts/List.h:477
> #3 0x006d6767 in UnixNetVConnection::reenable (this=0x7fffd4014500,
> vio=0x7fffd4014610) at UnixNetVConnection.cc:721
> #4 0x005195d5 in VIO::reenable (this=0x7fffd4014610) at
> ../iocore/eventsystem/P_VIO.h:124
> #5 0x005c73b1 in HttpTunnel::consumer_handler (this=0x7fffdbefb888,
> event=101, c=0x7fffdbefb8c8) at HttpTunnel.cc:1237
> #6 0x005c7c1f in HttpTunnel::main_handler (this=0x7fffdbefb888,
> event=101, data=0x7fffc4008870) at HttpTunnel.cc:1481
> #7 0x004f8aa6 in Continuation::handleEvent (this=0x7fffdbefb888,
> event=101, data=0x7fffc4008870) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0050a612 in TSContCall (contp=0x7fffdbefb888,
> event=TS_EVENT_VCONN_WRITE_READY, edata=0x7fffc4008870) at InkAPI.cc:4400
> #9 0x0055f302 in handle_transform (contp=0x7fffc40087c0) at
> InkAPITest.cc:6435
> #10 0x0055f4be in transformtest_transform (contp=0x7fffc40087c0,
> event=TS_EVENT_IMMEDIATE, edata=0x1166920) at InkAPITest.cc:6501
> #11 0x00501922 in INKVConnInternal::handle_event
> (this=0x7fffc40087c0, event=1, edata=0x1166920) at InkAPI.cc:1045
> #12 0x004f8aa6 in Continuation::handleEvent (this=0x7fffc40087c0,
> event=1, data=0x1166920) at ../iocore/eventsystem/I_Continuation.h:146
> #13 0x006f823d in EThread::process_event (this=0x73aa9010,
> e=0x1166920, calling_code=1) at UnixEThread.cc:142
> #14 0x006f8491 in EThread::execute (this=0x73aa9010) at
> UnixEThread.cc:193
> #15 0x006f744c in spawn_thread_internal (a=0x1090810) at Thread.cc:88
> #16 0x7793dea7 in start_thread () from /lib64/libpthread.so.0
> #17 0x751c114d in clone () from /lib64/libc.so.6
> (gdb) l
> 148 // ink_atomic_cas(mem, prev, next)
> 149 // Atomically store the value @next into the pointer @mem, but only
> if the current value at @mem is @prev.
> 150 // Returns true if @next was successfully stored.
> 151 template static inline bool
> 152 ink_atomic_cas(volatile T * mem, T prev, T next) {
> 153 return __sync_bool_compare_and_swap(mem, prev, next);
> 154 }
> 155
> 156 // ink_atomic_increment(ptr, count)
> 157 // Increment @ptr by @count, returning the previous value.
> (gdb) f 1
> #1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
> item=0x7fffd4014500) at ink_queue.cc:481
> 481result = ink_atomic_cas((__int128_t*) & l->head, head.data,
> item_pair.data);
> (gdb) p head.data
> $1 = 0x0001
> (gdb) p head
> $2 = {s = {pointer = 0x1, version = 0}, data =
> 0x0001}
> (gdb)
> {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] [Comment Edited] (TS-1712) Double Free Issue with Basic Auth Type Plugin
[
https://issues.apache.org/jira/browse/TS-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603764#comment-13603764
]
Valerie Thompson edited comment on TS-1712 at 3/15/13 7:54 PM:
---
I know jpeach looked at this issue. Here is environment information about the
boxes I'm using to run this code.
Uname information:
Linux 2.6.32-279.19.1.el6.x86_64 #1 SMP Tue Dec 18 17:22:54 CST 2012 x86_64
x86_64 x86_64 GNU/Linux
{noformat}
# gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)
{noformat}
Let me know if there is any other environment specific info you need.
was (Author: xianthe):
I know jpeach looked at this issue. Here is environment information about
the boxes I'm using to run this code.
Uname information:
Linux 2.6.32-279.19.1.el6.x86_64 #1 SMP Tue Dec 18 17:22:54 CST 2012 x86_64
x86_64 x86_64 GNU/Linux
# gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)
Let me know if there is any other environment specific info you need.
> Double Free Issue with Basic Auth Type Plugin
> -
>
> Key: TS-1712
> URL: https://issues.apache.org/jira/browse/TS-1712
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Valerie Thompson
>
> I am creating a new plugin based off of basic-auth.c example from 3.0.5
> version of ATS. When I load the plugin and start running traffic through it I
> am getting memory issues and eventually crashes.
> I plan on having a username and password for my plugin, and as I add more
> features, the more unstable everything becomes. Today I stripped everything
> down to the bare minimum and ran it as and here is an example of memory
> issues, below. Let me know if you need further information.
> uname info for the type of box I'm running on:
> 2.6.32-279.5.1.el6.x86_64 #1 SMP Tue Aug 14 16:11:42 CDT 2012 x86_64 x86_64
> x86_64 GNU/Linux
> {quote}
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x030c4ab0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3197275916]
> /lib64/libc.so.6[0x3197278443]
> /usr/lib64/trafficserver/plugins/ena-auth.so(+0x16a0)[0x2b051fc026a0]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52d3e5]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x35a)[0x5222fa]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xac3)[0x537753]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x280)[0x52e760]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
> /usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x202)[0x510d22]
> /usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+
[jira] [Commented] (TS-1712) Double Free Issue with Basic Auth Type Plugin
[
https://issues.apache.org/jira/browse/TS-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603764#comment-13603764
]
Valerie Thompson commented on TS-1712:
--
I know jpeach looked at this issue. Here is environment information about the
boxes I'm using to run this code.
Uname information:
Linux 2.6.32-279.19.1.el6.x86_64 #1 SMP Tue Dec 18 17:22:54 CST 2012 x86_64
x86_64 x86_64 GNU/Linux
# gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)
Let me know if there is any other environment specific info you need.
> Double Free Issue with Basic Auth Type Plugin
> -
>
> Key: TS-1712
> URL: https://issues.apache.org/jira/browse/TS-1712
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Valerie Thompson
>
> I am creating a new plugin based off of basic-auth.c example from 3.0.5
> version of ATS. When I load the plugin and start running traffic through it I
> am getting memory issues and eventually crashes.
> I plan on having a username and password for my plugin, and as I add more
> features, the more unstable everything becomes. Today I stripped everything
> down to the bare minimum and ran it as and here is an example of memory
> issues, below. Let me know if you need further information.
> uname info for the type of box I'm running on:
> 2.6.32-279.5.1.el6.x86_64 #1 SMP Tue Aug 14 16:11:42 CDT 2012 x86_64 x86_64
> x86_64 GNU/Linux
> {quote}
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x030c4ab0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3197275916]
> /lib64/libc.so.6[0x3197278443]
> /usr/lib64/trafficserver/plugins/ena-auth.so(+0x16a0)[0x2b051fc026a0]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52d3e5]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x35a)[0x5222fa]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xac3)[0x537753]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x280)[0x52e760]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
> /usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x202)[0x510d22]
> /usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x4be)[0x65a41e]
> /usr/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x170)[0x638910]
> /usr/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x84)[0x510674]
> /usr/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0x151)[0x521ab1]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6f3)[0x537383]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7fd)[0x53748d]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+
[jira] [Updated] (TS-1256) Streamline usage of PATH_NAME_MAX
[
https://issues.apache.org/jira/browse/TS-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1256:
--
Fix Version/s: (was: 3.3.3)
3.5.0
Moving out.
> Streamline usage of PATH_NAME_MAX
> -
>
> Key: TS-1256
> URL: https://issues.apache.org/jira/browse/TS-1256
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
>Reporter: Igor Galić
> Fix For: 3.5.0
>
>
> There are right now two different usages of the constant {{PATH_NAME_MAX}} in
> variable declarations:
> {code:c}
> char foo[PATH_NAME_MAX];
> {code}
> and
> {code:c}
> char bar[PATH_NAME_MAX + 1];
> {code}
> Since we define what {{PATH_NAME_MAX}} is ourselves, we should streamline our
> code to only use the first kind of declaration.
--
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-1228) Support new X-Forwarded-For standards
[ https://issues.apache.org/jira/browse/TS-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1228: -- Fix Version/s: (was: 3.3.3) 3.5.0 > Support new X-Forwarded-For standards > - > > Key: TS-1228 > URL: https://issues.apache.org/jira/browse/TS-1228 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.5.0 > > > We should consider supporting this new IETF draf standard: > http://tools.ietf.org/html/draft-petersson-forwarded-for-02 -- 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] [Resolved] (TS-1505) traffic server crash
[
https://issues.apache.org/jira/browse/TS-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-1505.
-
Resolution: Not A Problem
Fix Version/s: (was: 3.3.4)
Closing as a configuration issue as per Uri's analysis.
> traffic server crash
>
>
> Key: TS-1505
> URL: https://issues.apache.org/jira/browse/TS-1505
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4
> Environment: os: centos 6.2 x64
>Reporter: lingjie.zhou
>Priority: Critical
>
> I have 12's ats server has run 3 month is very well, but in the past week 2
> ats server have been crashd, crash reason log is:
> [Sep 26 21:32:49.846] Manager {139893959927776} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '10'
> [Sep 26 21:32:49.846] Manager {139893959927776} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Sep 26 21:32:50.859] {47599477855840} STATUS: opened
> /usr/local/ats/var/log/trafficserver/diags.log
> [Sep 26 21:32:50.859] {47599477855840} NOTE: updated diags config
> [Sep 26 21:32:50.861] Server {47599477855840} NOTE: cache clustering disabled
> [Sep 26 21:32:50.879] Server {47599477855840} NOTE: cache clustering disabled
> [Sep 26 21:32:50.908] Server {47599477855840} NOTE: logging initialized[7],
> logging_mode = 3
> [Sep 26 21:32:50.909] Server {47599477855840} ERROR: Cannot insert duplicate!
> [Sep 26 21:32:50.909] Server {47599477855840} ERROR: Couldn't insert into
> trie!
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: Could not insert new
> mapping
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: Could not add rule at
> line #8; Aborting!
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: [ReverseProxy] Unable
> to add mapping rule to lookup table at line 8
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: something failed
> during BuildTable() -- check your remap plugins!
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: Can not load the remap
> table, exiting out!
> [Sep 26 21:32:50.916] Manager {139893959927776} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Sep 26 21:32:50.916] Manager {139893959927776} ERROR: (last system error 2:
> No such file or directory)
> [TrafficManager] ==> Cleaning up and reissuing signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: [TrafficManager] ==>
> Cleaning up and reissuing signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: (last system error 2:
> No such file or directory)
> [TrafficManager] ==> signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: [TrafficManager] ==>
> signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: (last system error 2:
> No such file or directory)
--
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-1566) dynamic update for string vars does not work
[
https://issues.apache.org/jira/browse/TS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1566:
Fix Version/s: (was: 3.3.4)
3.5.0
> dynamic update for string vars does not work
>
>
> Key: TS-1566
> URL: https://issues.apache.org/jira/browse/TS-1566
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 3.2.0
>Reporter: Aidan McGurn
>Priority: Critical
> Fix For: 3.5.0
>
>
> i noticed that when i try to do a dynamic update of the scheme in congestion
> control it doesn't appear to work:
> registerd callback: CongestionControlDefaultSchemeChanged
> this function gets called back correctly when the var:
> CONFIG proxy.config.http.congestion_control.default.congestion_scheme STRING
> per_host
> is updated and 'traffic_line -x' is called..
> however the var returned via r->data (record data) or
> DEFAULT_congestion_scheme_str has not been updated unlike for its integer
> config counterparts -
> Th r->data has been overwritten with rubbish - in fact tracing it back i see
> P_RecCore.i calls
> for (cur_callback = r->config_meta.update_cb_list; cur_callback;
> cur_callback = cur_callback->next) {
> (*(cur_callback->update_cb)) (r->name, r->data_type, r->data,
> cur_callback->update_cookie);
> this then calls before the callback function (r->data is correct at this
> point) a function called 'link_string_alloc' which has been registered via
> this function for all strings in general:
> CC_EstablishStaticConfigStringAlloc(DEFAULT_congestion_scheme_str,
> "proxy.config.http.congestion_control.default.congestion_scheme");
> The link_string_alloc overwrites the string with the passed in cookie var
> which has rubbish - this function looks completely wrong -
> i have commented it out updated string in r->data doesn't get overwritten and
> so is passed through ok -
> ***could anyone explain what link_string alloc is actually needed for and
> does removing this lead to a memory leak?
--
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-1566) dynamic update for string vars does not work
[
https://issues.apache.org/jira/browse/TS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603638#comment-13603638
]
James Peach commented on TS-1566:
-
Aidan, if you attach your change as a patch file and mark this ticket as "with
patch", I will commit it.
> dynamic update for string vars does not work
>
>
> Key: TS-1566
> URL: https://issues.apache.org/jira/browse/TS-1566
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 3.2.0
>Reporter: Aidan McGurn
>Priority: Critical
> Fix For: 3.3.4
>
>
> i noticed that when i try to do a dynamic update of the scheme in congestion
> control it doesn't appear to work:
> registerd callback: CongestionControlDefaultSchemeChanged
> this function gets called back correctly when the var:
> CONFIG proxy.config.http.congestion_control.default.congestion_scheme STRING
> per_host
> is updated and 'traffic_line -x' is called..
> however the var returned via r->data (record data) or
> DEFAULT_congestion_scheme_str has not been updated unlike for its integer
> config counterparts -
> Th r->data has been overwritten with rubbish - in fact tracing it back i see
> P_RecCore.i calls
> for (cur_callback = r->config_meta.update_cb_list; cur_callback;
> cur_callback = cur_callback->next) {
> (*(cur_callback->update_cb)) (r->name, r->data_type, r->data,
> cur_callback->update_cookie);
> this then calls before the callback function (r->data is correct at this
> point) a function called 'link_string_alloc' which has been registered via
> this function for all strings in general:
> CC_EstablishStaticConfigStringAlloc(DEFAULT_congestion_scheme_str,
> "proxy.config.http.congestion_control.default.congestion_scheme");
> The link_string_alloc overwrites the string with the passed in cookie var
> which has rubbish - this function looks completely wrong -
> i have commented it out updated string in r->data doesn't get overwritten and
> so is passed through ok -
> ***could anyone explain what link_string alloc is actually needed for and
> does removing this lead to a memory leak?
--
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-1434) limited max bandwidth
[ https://issues.apache.org/jira/browse/TS-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1434: Priority: Major (was: Blocker) > limited max bandwidth > - > > Key: TS-1434 > URL: https://issues.apache.org/jira/browse/TS-1434 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.2.0, 3.0.5 >Reporter: samahee > Fix For: sometime > > > I'm using 3.2.0. bonding 2G > cached large file(2GB) and then downloaded full speed on some servers. > but bandwidth limited 800M bit/sec > please check it. -- 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-1434) limited max bandwidth
[ https://issues.apache.org/jira/browse/TS-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1434: Fix Version/s: (was: 3.3.4) sometime > limited max bandwidth > - > > Key: TS-1434 > URL: https://issues.apache.org/jira/browse/TS-1434 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.2.0, 3.0.5 >Reporter: samahee >Priority: Blocker > Fix For: sometime > > > I'm using 3.2.0. bonding 2G > cached large file(2GB) and then downloaded full speed on some servers. > but bandwidth limited 800M bit/sec > please check it. -- 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-1244) Crash report: cores in Arena::reset
[
https://issues.apache.org/jira/browse/TS-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603634#comment-13603634
]
Leif Hedstrom commented on TS-1244:
---
Manjesh, any updates on this? You have a fix ? :)
> Crash report: cores in Arena::reset
>
>
> Key: TS-1244
> URL: https://issues.apache.org/jira/browse/TS-1244
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Manjesh Nilange
> Fix For: 3.3.3
>
>
> I have two slightly different stack traces, but both involving Arena::reset
> #0 0x003736032a45 in raise () from /lib64/libc.so.6
> #1 0x003736034225 in abort () from /lib64/libc.so.6
> #2 0x00373606fdfb in __libc_message () from /lib64/libc.so.6
> #3 0x003736075716 in malloc_printerr () from /lib64/libc.so.6
> #4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
> #5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
> #6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
> #7 0x0050e3e3 in destroy (this=0x2b8c2c1b6b40) at HttpTransact.h:1235
> #8 HttpSM::cleanup (this=0x2b8c2c1b6b40) at HttpSM.cc:346
> #9 0x0050e719 in HttpSM::destroy (this=0x2b8c2c1b6b40) at
> HttpSM.cc:368
> #10 0x00515a56 in HttpSM::kill_this (this=0x2b8c2c1b6b40) at
> HttpSM.cc:6023
> #11 0x00515e08 in HttpSM::main_handler (this=0x2b8c2c1b6b40,
> event=2301, data=0x2b8c2c1b8828)
> at HttpSM.cc:2452
> ...
> (gdb) f 4
> #4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
> 89ink_free(mem);
> (gdb) p mem
> $1 =
> (gdb) f 5
> #5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
> 69xfree(blk);
> (gdb) p blk
> $2 =
> (gdb) f 6
> #6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
> 156 blk_free(m_blocks);
> (gdb) p m_blocks
> $3 = (ArenaBlock *) 0x2b8b9822b870
> (gdb) p *m_blocks
> $4 = {next = 0x3b323531322e3630, m_heap_end = 0x2554454e2e303225 0x2554454e2e303225 out of bounds>,
> m_water_level = 0x303225524c433032 bounds>, data = "3.5.3072"}
> (gdb) p *m_blocks->next
> Cannot access memory at address 0x3b323531322e3630
> It looks m_blocks is corrupted.
> and the other stack trace
> #3 0x004d03aa in signal_handler (sig=11) at signals.cc:225
> #4
> #5 blk_free (this=0x2afc58072f88) at Arena.cc:65
> #6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
> #7 0x0050e3e3 in destroy (this=0x2afc58072f10) at HttpTransact.h:1235
> #8 HttpSM::cleanup (this=0x2afc58072f10) at HttpSM.cc:346
> #9 0x0050e719 in HttpSM::destroy (this=0x2afc58072f10) at
> HttpSM.cc:368
> #10 0x00515a56 in HttpSM::kill_this (this=0x2afc58072f10) at
> HttpSM.cc:6023
> #11 0x00515e08 in HttpSM::main_handler (this=0x2afc58072f10,
> event=2301, data=0x2afc58074bf8)
> at HttpSM.cc:2452
> ...
> (gdb) f 5
> #5 blk_free (this=0x2afc58072f88) at Arena.cc:65
> 65 size = blk->m_heap_end - &blk->data[0];
> (gdb) p blk
> $1 =
> (gdb) f 6
> #6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
> 156 blk_free(m_blocks);
> (gdb) p m_blocks
> $2 = (ArenaBlock *) 0x373439333634
> (gdb) p *m_blocks
> Cannot access memory at address 0x373439333634
> Our environment:
> $ uname -a
> Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
> x86_64 x86_64 x86_64 GNU/Linux
> $ file /usr/bin/traffic_server
> /usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
--
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-1257) Replace Tcl_Hash* with lib/ts/Map
[
https://issues.apache.org/jira/browse/TS-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1257:
--
Fix Version/s: (was: 3.3.3)
3.5.0
> Replace Tcl_Hash* with lib/ts/Map
> -
>
> Key: TS-1257
> URL: https://issues.apache.org/jira/browse/TS-1257
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup, Core
>Reporter: Igor Galić
> Fix For: 3.5.0
>
>
> We have our own implementation of maps that we use in most new code. We have
> already discussed looking into removing the old Tcl cruft by replacing it
> with {{Map}}, but have neither followed up on the ML nor Jira - or in the
> code ;)
> This ticket is a reminder that this task exists and wants to be done!
> As to whether we simply replace the Tcl Implementation underneath, or visibly
> to all developers, replace {{InkHashTable}} with {{Map}}, remains to be
> discussed/decided/evaluated.
--
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-1253) Vmap or Virtual IP Address Configuration is broken
[
https://issues.apache.org/jira/browse/TS-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603630#comment-13603630
]
Leif Hedstrom commented on TS-1253:
---
How does this related to TS-1734 ?
> Vmap or Virtual IP Address Configuration is broken
> --
>
> Key: TS-1253
> URL: https://issues.apache.org/jira/browse/TS-1253
> Project: Traffic Server
> Issue Type: Bug
> Components: Management
>Affects Versions: 3.1.4
>Reporter: Zhao Yongming
> Fix For: 3.3.3
>
>
> Virtual IP Address Configuration, config file vaddrs.config is known to be
> broken:
> missing vip_config, which is designed to be a dedicated binary to config
> Virtual IPs
> {code}
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::Vmap] Added
> cluster interface 'em1' real ip: '115.238.23.57' to known interfaces
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::Vmap] Added
> interface 'lo' real ip: '127.0.0.1' to known interfaces
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::VMap] Already
> added interface 'em1'. Not adding for real IP '115.238.23.57'
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
> Adding virtual address '192.168.0.199' interface: 'lo' sub-interface-id '0'
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
> Interface 'lo' marked as having potential virtual ips
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
> Adding virtual address '192.168.0.99' interface: 'lo' sub-interface-id '1'
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::downAddr]
> Bringing down addr: '192.168.0.199'
> [May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::downAddr]
> Bringing down addr: '192.168.0.99'
> {code}
> confusing:
> 1, I think in most case we do need Virtual IP, do we need to management in TS
> manager?
> 2, do we need to write a dedicate vip_config file? maybe we need to script it?
> 3, we need more cleanup in the codes, IE: remove the windows mess :D
--
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-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-346: - Fix Version/s: (was: 3.3.3) 3.5.0 > ATS does not verify server certificate > -- > > Key: TS-346 > URL: https://issues.apache.org/jira/browse/TS-346 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: vijaya bhaskar mamidi >Assignee: Igor Galić >Priority: Critical > Fix For: 3.5.0 > > > ATS does not verify the certificates correctly. -- 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-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-346: Assignee: (was: Igor Galić) > ATS does not verify server certificate > -- > > Key: TS-346 > URL: https://issues.apache.org/jira/browse/TS-346 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: vijaya bhaskar mamidi >Priority: Critical > Fix For: 3.5.0 > > > ATS does not verify the certificates correctly. -- 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] [Resolved] (TS-58) Logging: Unified logging
[ https://issues.apache.org/jira/browse/TS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-58. --- Resolution: Won't Fix Fix Version/s: (was: 3.3.4) We don't have resources to do this. > Logging: Unified logging > > > Key: TS-58 > URL: https://issues.apache.org/jira/browse/TS-58 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.0a > Environment: All platforms >Reporter: George Paul >Priority: Minor > > There is a request to unify the logging in Traffic Server system. This would > entail modifying the Diagnostic logging system to use the internal > transaction logging system which uses non-locking buffers and a separate > thread. The changes would affect both the Traffic Server and Traffic Manager > which use the Diagnostic logging for event logging similar to syslog(). > -George -- 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-799) Have AdminClient.pm created from .in file
[ https://issues.apache.org/jira/browse/TS-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-799: --- Fix Version/s: (was: 3.3.4) sometime > Have AdminClient.pm created from .in file > - > > Key: TS-799 > URL: https://issues.apache.org/jira/browse/TS-799 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Igor Galić >Priority: Trivial > Fix For: sometime > > > AdminClient.pm should be created from an .in file. > @sockets_def = should be extended with @localstatedir@ on top. -- 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
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603626#comment-13603626
]
Otto van der Schaaf commented on TS-1666:
-
I'm not sure, I couldn't reproduce it myself. I'll see if I can ping ibrezac
about it, he was subject to this issue
> gzip plugin crash report
>
>
> Key: TS-1666
> URL: https://issues.apache.org/jira/browse/TS-1666
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Otto van der Schaaf
>Assignee: Otto van der Schaaf
>
> 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] [Resolved] (TS-1410) build error
[ https://issues.apache.org/jira/browse/TS-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1410. - Resolution: Cannot Reproduce Fix Version/s: (was: 3.3.4) No response from originator. Closing. > build error > --- > > Key: TS-1410 > URL: https://issues.apache.org/jira/browse/TS-1410 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 3.3.3 > Environment: centos 6 x86_64 from git >Reporter: bettydramit > Labels: esi > > ３.３.3 from git > when i run ./configure --prefix=/usr/local/ts --enable-experimental-plugins > and make > i got error: > make[2]: Entering directory `/data/new/plugins/experimental/lua' > CXXremap.lo > CXXplugin.lo > CXXlapi.lo > CXXlutil.lo > CXXlconfig.lo > CXXhook.lo > CXXLD lua.la > make[2]: Leaving directory `/data/new/plugins/experimental/lua' > Making all in experimental/esi > make[2]: Entering directory `/data/new/plugins/experimental/esi' > CXXHttpDataFetcherImpl.lo > 在包含自 > /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/ext/hash_map：60 > 的文件中， > 从 ./lib/StringHash.h：29， > 从 fetcher/HttpDataFetcherImpl.h：32， > 从 fetcher/HttpDataFetcherImpl.cc：24: > /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/backward/backward_warning.h:28:2: > 错误：#warning This file includes at least one deprecated or antiquated header > which may be removed without further notice at a future date. Please use a > non-deprecated interface with equivalent functionality instead. For a listing > of replacement headers and interfaces, consult the file backward_warning.h. > To disable this warning use -Wno-deprecated. > make[2]: *** [HttpDataFetcherImpl.lo] 错误 1 > make[2]: Leaving directory `/data/new/plugins/experimental/esi' > make[1]: *** [all-recursive] 错误 1 > make[1]: Leaving directory `/data/new/plugins' > make: *** [all-recursive] 错误 1 -- 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-823) Build fails with --enable-standalone-iocore
[
https://issues.apache.org/jira/browse/TS-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-823:
---
Fix Version/s: (was: 3.3.4)
sometime
> Build fails with --enable-standalone-iocore
> ---
>
> Key: TS-823
> URL: https://issues.apache.org/jira/browse/TS-823
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.1.0, 2.1.8
>Reporter: Igor Galić
> Fix For: sometime
>
>
> When enabling ./configuring the build with --enable-standalone-iocore the
> build fails with:
> {noformat}
> igalic@bawnb976 ~/Projects/asf/trafficserver/iocore/dns (svn)-[trunk:1132769]
> % make
> g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
> -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
> -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
> -I../../iocore/dns -I../../lib/records -D_LARGEFILE64_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux
> -I/usr/include/tcl8.4 -march=native -mtune=native -march=i586 -g -pipe -Wall
> -Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -MT DNS.o -MD -MP -MF .deps/DNS.Tpo -c -o DNS.o DNS.cc
> DNS.cc: In member function 'virtual int DNSProcessor::start(int)':
> DNS.cc:132:7: error: 'SplitDNSConfig' has not been declared
> DNS.cc:134:5: error: 'SplitDNSConfig' has not been declared
> DNS.cc: In member function 'void DNSEntry::init(const char*, int, int,
> Continuation*, DNSHandler*, int)':
> DNS.cc:261:19: error: 'INK_NOWARN' was not declared in this scope
> make: *** [DNS.o] Error 1
> {noformat}
> This is due to missing dependencies in Makefile.am: Even though we include
> "P_DNS.h", which includes "libts.h", which in turn includes "ink_config.h"
> the compiler doesn't seem to be able to resolve "SPLIT_DNS".
--
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
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603613#comment-13603613
]
Leif Hedstrom commented on TS-1666:
---
Is this an issue still?
> gzip plugin crash report
>
>
> Key: TS-1666
> URL: https://issues.apache.org/jira/browse/TS-1666
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Otto van der Schaaf
>Assignee: Otto van der Schaaf
>
> 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] [Updated] (TS-341) Update Contrib Scripts
[ https://issues.apache.org/jira/browse/TS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-341: --- Fix Version/s: (was: 3.3.4) sometime > Update Contrib Scripts > -- > > Key: TS-341 > URL: https://issues.apache.org/jira/browse/TS-341 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 2.0.0 > Environment: EC2 >Reporter: Jason Giedymin >Assignee: Jason Giedymin >Priority: Minor > Labels: Contrib, EC2, Scripts > Fix For: sometime > > > - The EC2 images i created last month had updates to the contrib scripts > which need to be synced with the source repo. > - Need to udpate the scripts to point to the source repo -- 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-340) EC2 Updates/Testing/Building
[ https://issues.apache.org/jira/browse/TS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-340: --- Fix Version/s: (was: 3.3.4) sometime > EC2 Updates/Testing/Building > > > Key: TS-340 > URL: https://issues.apache.org/jira/browse/TS-340 > Project: Traffic Server > Issue Type: Bug > Components: Build, Portability >Affects Versions: 3.0.0, 2.0.0a > Environment: EC2 >Reporter: Jason Giedymin >Assignee: Jason Giedymin >Priority: Minor > Labels: AMI, EC2, Fedora, Ubuntu > Fix For: sometime > > > 1.) More Lucid Testing > 2.) Rebuild with latest ATS Release > 3.) Seed to West, EU, Asia datacenters (20 Images in total, > Fedora/Ubuntu9/Ubuntu10/32/64) -- 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-1728) Need a way to assign storage entries to volumes
[ https://issues.apache.org/jira/browse/TS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1728: -- Fix Version/s: 3.3.2 > Need a way to assign storage entries to volumes > --- > > Key: TS-1728 > URL: https://issues.apache.org/jira/browse/TS-1728 > Project: Traffic Server > Issue Type: Wish > Components: Cache >Reporter: Jan van Doorn >Assignee: Phil Sorber >Priority: Minor > Fix For: 3.3.2 > > Attachments: vol.patch > > > See http://www.knutsel.com/vol/compare/ for a write up and some test results > on this. We are proposing a simple way to hard link storage.config entries to > volume.config and thus hosting.config entries. -- 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-1571) Steal^Wborrow httpd's mod_cache idea of X-Cache-Detail headers
[ https://issues.apache.org/jira/browse/TS-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1571: -- Fix Version/s: 3.5.0 Moving this out to v3.5.0 for now. > Steal^Wborrow httpd's mod_cache idea of X-Cache-Detail headers > -- > > Key: TS-1571 > URL: https://issues.apache.org/jira/browse/TS-1571 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Igor Galić > Fix For: 3.5.0 > > > Starting v2.3.9 httpd's mod_cache implements a feature enabled by > [CacheDetailHeader|http://httpd.apache.org/docs/trunk/mod/mod_cache.html#cachedetailheader] > - which in nature is very similar to our Via header feature but is easier to > read and understand by spelling out why something was > cached/missed/revalidated/etc.. in words - so it doesn't need a decoder ring. > Given that we already have Via headers feature it should be fairly easy to > implement a logic for producing a very similar header our selves. -- 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-1603) crash at ClusterHandler::mainClusterEvent
[
https://issues.apache.org/jira/browse/TS-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603602#comment-13603602
]
Leif Hedstrom commented on TS-1603:
---
Anyone working on this ?
> crash at ClusterHandler::mainClusterEvent
> -
>
> Key: TS-1603
> URL: https://issues.apache.org/jira/browse/TS-1603
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: Bin Chen
>
> {code}
> #0 0x006556c4 in ClusterHandler::mainClusterEvent
> (this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
> /usr/src/debug/trafficserver-3.2.0/iocore/cluster/ClusterHandler.cc:2469:81142:beg:0x6556c4
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 0x006556c4 in ClusterHandler::mainClusterEvent
> (this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
> #1 0x0065d6a3 in ClusterHandler::protoZombieEvent
> (this=0x2ab444c1e4e0, event=1, e=0x0)
> at ClusterHandlerBase.cc:1219
> #2 0x004e6fae in Continuation::handleEvent (this=0x2ab444c1e4e0,
> event=1, data=0x0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #3 0x0065b081 in ClusterState::IOComplete (this=0x2ab444c1e840) at
> ClusterHandlerBase.cc:584
> #4 0x0065ae1a in ClusterState::doIO_read_event (this=0x2ab444c1e840,
> event=104, d=0x2ab3613601d8)
> at ClusterHandlerBase.cc:496
> #5 0x004e6fae in Continuation::handleEvent (this=0x2ab444c1e840,
> event=104, data=0x2ab3613601d8)
> at ../iocore/eventsystem/I_Continuation.h:146
> #6 0x006b806c in read_signal_and_update (event=104,
> vc=0x2ab3613600d0) at UnixNetVConnection.cc:129
> #7 0x006b81bd in read_signal_done (event=104, nh=0x2ab35f1211e8,
> vc=0x2ab3613600d0) at UnixNetVConnection.cc:159
> #8 0x006b8707 in read_from_net (nh=0x2ab35f1211e8,
> vc=0x2ab3613600d0, thread=0x2ab35f11e010)
> at UnixNetVConnection.cc:282
> #9 0x006ba351 in UnixNetVConnection::net_read_io
> (this=0x2ab3613600d0, nh=0x2ab35f1211e8, lthread=0x2ab35f11e010)
> at UnixNetVConnection.cc:802
> #10 0x006b5064 in NetHandler::mainNetEvent (this=0x2ab35f1211e8,
> event=5, e=0x2ab33c536dd0) at UnixNet.cc:337
> #11 0x004e6fae in Continuation::handleEvent (this=0x2ab35f1211e8,
> event=5, data=0x2ab33c536dd0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #12 0x006d99b8 in EThread::process_event (this=0x2ab35f11e010,
> e=0x2ab33c536dd0, calling_code=5)
> at UnixEThread.cc:189
> #13 0x006d9e55 in EThread::execute (this=0x2ab35f11e010) at
> UnixEThread.cc:301
> #14 0x006d89e7 in spawn_thread_internal (a=0x2ab344334f20) at
> Thread.cc:88
> #15 0x0037a14077f1 in start_thread () from /lib64/libpthread.so.0
> #16 0x0037a10e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x006556c4 in ClusterHandler::mainClusterEvent
> (this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
> /usr/src/debug/trafficserver-3.2.0/iocore/cluster/ClusterHandler.cc:2469:81142:beg:0x6556c4
> (gdb) l
> 2464 thread = (EThread *) e;
> 2465} else {
> 2466 if (io_callback) {
> 2467thread = this_ethread();
> 2468 } else {
> 2469thread = e->ethread;
> 2470 }
> 2471}
> 2472
> 2473int io_activity = 1;
> (gdb) p e
> $1 = (Event *) 0x0
> {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-1669) evaluate SipHash as a replacement for MD5
[ https://issues.apache.org/jira/browse/TS-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1669: -- Fix Version/s: sometime > evaluate SipHash as a replacement for MD5 > - > > Key: TS-1669 > URL: https://issues.apache.org/jira/browse/TS-1669 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Performance >Reporter: James Peach > Fix For: sometime > > Attachments: siphash.pdf > > > SipHash is claimed to have the stability of MD5 but the performance of a > non-crypto hash function. Let's take a look and see whether there's any > benefit to that. -- 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-1622) Add an API to query if a response header would be cacheable
[ https://issues.apache.org/jira/browse/TS-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1622: -- Fix Version/s: 3.5.0 > Add an API to query if a response header would be cacheable > --- > > Key: TS-1622 > URL: https://issues.apache.org/jira/browse/TS-1622 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom > Fix For: 3.5.0 > > > It would be useful for a plugin to be able to take e.g. a response header (a > Hdr object) and ask the HttpSM if this response would be cacheable or not. It > should use the same logic (and configs) as the core does normally. -- 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-1653) Crash report: HostDBContinuation::probeEvent MutexTryLock
[
https://issues.apache.org/jira/browse/TS-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1653:
--
Fix Version/s: 3.3.2
Assignee: weijin (was: Alan M. Carroll)
weijin: There's a commit on this one, please close this if it's been fixed.
> Crash report: HostDBContinuation::probeEvent MutexTryLock
> -
>
> Key: TS-1653
> URL: https://issues.apache.org/jira/browse/TS-1653
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 3.3.2
>
>
> {code}
> Core was generated by `/usr/bin/traffic_server -M --httpport 8080:fd=7'.
> Program terminated with signal 11, Segmentation fault.
> #0 Mutex_trylock (this=0x2b994a800ce0, am=0x0, t=0x2b9948fea010) at
> ../iocore/eventsystem/I_Lock.h:170
> 170 if (m->thread_holding != t) {
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-11.el6_2.x86_64 glibc-2.12-1.47.el6_2.9.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> openssl-1.0.0-20.el6_2.4.x86_64 pcre-7.8-3.1.el6.x86_64
> tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
> zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 Mutex_trylock (this=0x2b994a800ce0, am=0x0, t=0x2b9948fea010) at
> ../iocore/eventsystem/I_Lock.h:170
> #1 MutexTryLock::MutexTryLock (this=0x2b994a800ce0, am=0x0,
> t=0x2b9948fea010) at ../iocore/eventsystem/I_Lock.h:385
> #2 0x005b38dc in HostDBContinuation::probeEvent
> (this=0x2b997329df10, event=, e=0x2b99b8050030) at
> HostDB.cc:1762
> #3 0x0065a1b4 in handleEvent (this=0x2b9948fea010, e=0x2b99b8050030,
> calling_code=2) at I_Continuation.h:146
> #4 EThread::process_event (this=0x2b9948fea010, e=0x2b99b8050030,
> calling_code=2) at UnixEThread.cc:142
> #5 0x0065ad83 in EThread::execute (this=0x2b9948fea010) at
> UnixEThread.cc:221
> #6 0x006594d2 in spawn_thread_internal (a=0x2fb8350) at Thread.cc:88
> #7 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #8 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> (gdb) f 2
> #2 0x005b38dc in HostDBContinuation::probeEvent
> (this=0x2b997329df10, event=, e=0x2b99b8050030) at
> HostDB.cc:1762
> 1762MUTEX_TRY_LOCK_FOR(lock, action.mutex, t, action.continuation);
> (gdb) p action.mutex
> $1 = {m_ptr = 0x0}
> (gdb) p t
> $2 =
> (gdb) p action
> $3 = {_vptr.Action = 0x6601d0, continuation = 0x0, mutex = {m_ptr = 0x0},
> cancelled = 1}
> (gdb)
> {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-1655) 3.2.x - wccp does not build out of tree
[
https://issues.apache.org/jira/browse/TS-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1655:
Fix Version/s: (was: 3.3.3)
3.2.5
> 3.2.x - wccp does not build out of tree
> ---
>
> Key: TS-1655
> URL: https://issues.apache.org/jira/browse/TS-1655
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.2.5
>
>
> {noformat}
> make[2]: Entering directory
> `/home/igalic/src/asf/trafficserver/BUILD-3.2.x/lib/tsconfig'
> YACC TsConfigGrammar.c
> updating TsConfigGrammar.h
> /usr/bin/sed -f BisonHeaderToC++.sed TsConfigGrammar.h > TsConfigGrammar.hpp
> /usr/bin/sed: couldn't open file BisonHeaderToC++.sed: No such file or
> directory
> make[2]: *** [TsConfigGrammar.hpp] Error 4
> {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] [Updated] (TS-1193) Traffic Server building on OpenBSD
[ https://issues.apache.org/jira/browse/TS-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1193: Fix Version/s: (was: 3.3.3) sometime > Traffic Server building on OpenBSD > -- > > Key: TS-1193 > URL: https://issues.apache.org/jira/browse/TS-1193 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 3.1.3 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: sometime > > > This is a parent issue for the task of getting traffic server building on > OpenBSD. -- 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-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1648:
--
Fix Version/s: 3.3.2
weijin: What should we do with this bug? I'm marking it for v3.3.2 for now.
> Segmentation fault in dir_clear_range()
> ---
>
> Key: TS-1648
> URL: https://issues.apache.org/jira/browse/TS-1648
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.3.0, 3.2.0
> Environment: reverse proxy
>Reporter: Tomasz Kuzemko
>Assignee: weijin
> Fix For: 3.3.2
>
> Attachments:
> 0001-Fix-for-TS-1648-Segmentation-fault-in-dir_clear_rang.patch
>
>
> I use ATS as a reverse proxy. I have a fairly large disk cache consisting of
> 2x 10TB raw disks. I do not use cache compression. After a few days of
> running (this is a dev machine - not handling any traffic) ATS begins to
> crash with a segfault shortly after start:
> [Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage
> snap 1357917060690487000
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x720ad700 (LWP 17292)]
> 0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
> at CacheDir.cc:382
> 382 CacheDir.cc: No such file or directory.
> in CacheDir.cc
> (gdb) p i
> $1 = 214748365
> (gdb) l
> 377 in CacheDir.cc
> (gdb) p dir_index(vol, i)
> $2 = (Dir *) 0x7ff997a04002
> (gdb) p dir_index(vol, i-1)
> $3 = (Dir *) 0x7ffa97a03ff8
> (gdb) p *dir_index(vol, i-1)
> $4 = {w = {0, 0, 0, 0, 0}}
> (gdb) p *dir_index(vol, i-2)
> $5 = {w = {0, 0, 52431, 52423, 0}}
> (gdb) p *dir_index(vol, i)
> Cannot access memory at address 0x7ff997a04002
> (gdb) p *dir_index(vol, i+2)
> Cannot access memory at address 0x7ff997a04016
> (gdb) p *dir_index(vol, i+1)
> Cannot access memory at address 0x7ff997a0400c
> (gdb) p vol->buckets * DIR_DEPTH * vol->segments
> $6 = 1246953472
> (gdb) bt
> #0 0x00696a71 in dir_clear_range (start=640, end=17024,
> vol=0x16057d0) at CacheDir.cc:382
> #1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
> event=3900, data=0x16058a0) at Cache.cc:1384
> #2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
> event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
> #3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
> event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
> #4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
> data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
> #5 0x00700fec in EThread::process_event (this=0x736c4010,
> e=0x135afc0, calling_code=1) at UnixEThread.cc:142
> #6 0x007011ff in EThread::execute (this=0x736c4010) at
> UnixEThread.cc:191
> #7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
> #8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
> #9 0x755c6b6d in clone () from /lib/libc.so.6
> #10 0x in ?? ()
> This is fixed by running "traffic_server -Kk" to clear the cache. But after a
> few days the issue reappears.
> I will keep the current faulty setup as-is in case you need me to provide
> more data. I tried to make a core dump but it took a couple of GB even after
> gzip (I can however provide it on request).
> *Edit*
> OS is Debian GNU/Linux 6.0.6 with custom built kernel
> 3.2.13-grsec--grs-ipv6-64
--
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-1662) Remove "register" keyword from code
[
https://issues.apache.org/jira/browse/TS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1662:
--
Fix Version/s: 3.3.2
> Remove "register" keyword from code
>
>
> Key: TS-1662
> URL: https://issues.apache.org/jira/browse/TS-1662
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
>Reporter: Igor Galić
> Fix For: 3.3.2
>
>
> Here's a quick grep over the code (with some false positives) that contain
> the register keyword
> {noformat}
> mgmt/cli/cliParseArg.cc:401: register cli_ArgvInfo *infoPtr;
> mgmt/BaseManager.cc:78: * Function to register callback's for various
> management events, such
> mgmt/api/EventCallback.cc:178: *event_name - the event to store the
> callback for (if NULL, register for all events)
> mgmt/api/EventCallback.cc:247: *event_name - the event to store the
> callback for (if NULL, register for all events)
> mgmt/api/include/mgmtapi.h:1241: * Input: event_name - the name of event to
> register callback for;
> mgmt/api/remote/APITestCliRemote.cc:74: * register: registers a generic
> callback (=eventCallbackFn) which
> mgmt/api/remote/APITestCliRemote.cc:2400:} else if (strncmp(buf,
> "register", 8) == 0) {
> mgmt/api/EventControlMain.cc:452: * purpose: handles request to register a
> callback for a specific event (or all events)
> lib/tsconfig/TsConfigSyntax.c:744:register yy_state_type yy_current_state;
> lib/tsconfig/TsConfigSyntax.c:745:register char *yy_cp, *yy_bp;
> lib/tsconfig/TsConfigSyntax.c:746:register int yy_act;
> lib/tsconfig/TsConfigSyntax.c:799:register YY_CHAR yy_c =
> yy_ec[YY_SC_TO_UI(*yy_cp)];
> lib/tsconfig/TsConfigSyntax.c:1102: register char *dest =
> YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
> lib/tsconfig/TsConfigSyntax.c:1103: register char *source = yyg->yytext_ptr;
> lib/tsconfig/TsConfigSyntax.c:1104: register int number_to_move, i;
> lib/tsconfig/TsConfigSyntax.c:1236: register yy_state_type yy_current_state;
> lib/tsconfig/TsConfigSyntax.c:1237: register char *yy_cp;
> lib/tsconfig/TsConfigSyntax.c:1245: register YY_CHAR yy_c = (*yy_cp
> ? yy_ec[YY_SC_TO_UI(*yy_cp)] : 1);
> lib/tsconfig/TsConfigSyntax.c:1270: register int yy_is_jam;
> lib/tsconfig/TsConfigSyntax.c:1272: register char *yy_cp = yyg->yy_c_buf_p;
> lib/tsconfig/TsConfigSyntax.c:1274: register YY_CHAR yy_c = 1;
> lib/tsconfig/TsConfigSyntax.c:2046: register int i;
> lib/tsconfig/TsConfigSyntax.c:2055: register int n;
> lib/records/RecCore.cc:740:ink_debug_assert(!"Can't register record!");
> lib/ts/ink_res_init.cc:305: register FILE *fp;
> lib/ts/ink_res_init.cc:306: register char *cp, **pp;
> lib/ts/ink_res_init.cc:307: register int n;
> lib/ts/ink_resolver.h:205:register const u_char *t_cp = (const u_char
> *)(cp); \
> lib/ts/ink_resolver.h:215:register const u_char *t_cp = (const u_char
> *)(cp); \
> lib/ts/ink_resolver.h:227:register u_int16_t t_s = (u_int16_t)(s); \
> lib/ts/ink_resolver.h:228:register u_char *t_cp = (u_char *)(cp); \
> lib/ts/ink_resolver.h:237:register u_int32_t t_l = (u_int32_t)(l); \
> lib/ts/ink_resolver.h:238:register u_char *t_cp = (u_char *)(cp); \
> lib/ts/ink_res_mkquery.cc:103:register HEADER *hp;
> lib/ts/ink_res_mkquery.cc:104:register u_char *cp, *ep;
> lib/ts/ink_res_mkquery.cc:105:register int n;
> lib/ts/ink_string.cc:106: register char *s, *d;
> lib/ts/ink_string.cc:141: register char *s, *d;
> lib/ts/ink_string.h:154: register char *s, *d;
> lib/ts/ink_string.h:181:ink_string_concatenate_two_strings(char *dest,
> register char *s1, register char *s2)
> lib/ts/ink_string.h:183: register char *d;
> CLANG/lib/tsconfig/TsConfigSyntax.c:744: register yy_state_type
> yy_current_state;
> CLANG/lib/tsconfig/TsConfigSyntax.c:745: register char *yy_cp, *yy_bp;
> CLANG/lib/tsconfig/TsConfigSyntax.c:746: register int yy_act;
> CLANG/lib/tsconfig/TsConfigSyntax.c:799: register
> YY_CHAR yy_c = yy_ec[YY_SC_TO_UI(*yy_cp)];
> CLANG/lib/tsconfig/TsConfigSyntax.c:1102: register char *dest =
> YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1103: register char *source =
> yyg->yytext_ptr;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1104: register int number_to_move, i;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1236: register yy_state_type
> yy_current_state;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1237: register char *yy_cp;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1245: register YY_CHAR yy_c =
> (*yy_cp ? yy_ec[YY_SC_TO_UI(*yy_cp)] : 1);
> CLANG/lib/tsconfig/TsConfigSyntax.c:1270: register int yy_is_jam;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1272: register char *yy_cp =
>
[jira] [Assigned] (TS-1662) Remove "register" keyword from code
[
https://issues.apache.org/jira/browse/TS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1662:
-
Assignee: Leif Hedstrom
> Remove "register" keyword from code
>
>
> Key: TS-1662
> URL: https://issues.apache.org/jira/browse/TS-1662
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
>
> Here's a quick grep over the code (with some false positives) that contain
> the register keyword
> {noformat}
> mgmt/cli/cliParseArg.cc:401: register cli_ArgvInfo *infoPtr;
> mgmt/BaseManager.cc:78: * Function to register callback's for various
> management events, such
> mgmt/api/EventCallback.cc:178: *event_name - the event to store the
> callback for (if NULL, register for all events)
> mgmt/api/EventCallback.cc:247: *event_name - the event to store the
> callback for (if NULL, register for all events)
> mgmt/api/include/mgmtapi.h:1241: * Input: event_name - the name of event to
> register callback for;
> mgmt/api/remote/APITestCliRemote.cc:74: * register: registers a generic
> callback (=eventCallbackFn) which
> mgmt/api/remote/APITestCliRemote.cc:2400:} else if (strncmp(buf,
> "register", 8) == 0) {
> mgmt/api/EventControlMain.cc:452: * purpose: handles request to register a
> callback for a specific event (or all events)
> lib/tsconfig/TsConfigSyntax.c:744:register yy_state_type yy_current_state;
> lib/tsconfig/TsConfigSyntax.c:745:register char *yy_cp, *yy_bp;
> lib/tsconfig/TsConfigSyntax.c:746:register int yy_act;
> lib/tsconfig/TsConfigSyntax.c:799:register YY_CHAR yy_c =
> yy_ec[YY_SC_TO_UI(*yy_cp)];
> lib/tsconfig/TsConfigSyntax.c:1102: register char *dest =
> YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
> lib/tsconfig/TsConfigSyntax.c:1103: register char *source = yyg->yytext_ptr;
> lib/tsconfig/TsConfigSyntax.c:1104: register int number_to_move, i;
> lib/tsconfig/TsConfigSyntax.c:1236: register yy_state_type yy_current_state;
> lib/tsconfig/TsConfigSyntax.c:1237: register char *yy_cp;
> lib/tsconfig/TsConfigSyntax.c:1245: register YY_CHAR yy_c = (*yy_cp
> ? yy_ec[YY_SC_TO_UI(*yy_cp)] : 1);
> lib/tsconfig/TsConfigSyntax.c:1270: register int yy_is_jam;
> lib/tsconfig/TsConfigSyntax.c:1272: register char *yy_cp = yyg->yy_c_buf_p;
> lib/tsconfig/TsConfigSyntax.c:1274: register YY_CHAR yy_c = 1;
> lib/tsconfig/TsConfigSyntax.c:2046: register int i;
> lib/tsconfig/TsConfigSyntax.c:2055: register int n;
> lib/records/RecCore.cc:740:ink_debug_assert(!"Can't register record!");
> lib/ts/ink_res_init.cc:305: register FILE *fp;
> lib/ts/ink_res_init.cc:306: register char *cp, **pp;
> lib/ts/ink_res_init.cc:307: register int n;
> lib/ts/ink_resolver.h:205:register const u_char *t_cp = (const u_char
> *)(cp); \
> lib/ts/ink_resolver.h:215:register const u_char *t_cp = (const u_char
> *)(cp); \
> lib/ts/ink_resolver.h:227:register u_int16_t t_s = (u_int16_t)(s); \
> lib/ts/ink_resolver.h:228:register u_char *t_cp = (u_char *)(cp); \
> lib/ts/ink_resolver.h:237:register u_int32_t t_l = (u_int32_t)(l); \
> lib/ts/ink_resolver.h:238:register u_char *t_cp = (u_char *)(cp); \
> lib/ts/ink_res_mkquery.cc:103:register HEADER *hp;
> lib/ts/ink_res_mkquery.cc:104:register u_char *cp, *ep;
> lib/ts/ink_res_mkquery.cc:105:register int n;
> lib/ts/ink_string.cc:106: register char *s, *d;
> lib/ts/ink_string.cc:141: register char *s, *d;
> lib/ts/ink_string.h:154: register char *s, *d;
> lib/ts/ink_string.h:181:ink_string_concatenate_two_strings(char *dest,
> register char *s1, register char *s2)
> lib/ts/ink_string.h:183: register char *d;
> CLANG/lib/tsconfig/TsConfigSyntax.c:744: register yy_state_type
> yy_current_state;
> CLANG/lib/tsconfig/TsConfigSyntax.c:745: register char *yy_cp, *yy_bp;
> CLANG/lib/tsconfig/TsConfigSyntax.c:746: register int yy_act;
> CLANG/lib/tsconfig/TsConfigSyntax.c:799: register
> YY_CHAR yy_c = yy_ec[YY_SC_TO_UI(*yy_cp)];
> CLANG/lib/tsconfig/TsConfigSyntax.c:1102: register char *dest =
> YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1103: register char *source =
> yyg->yytext_ptr;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1104: register int number_to_move, i;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1236: register yy_state_type
> yy_current_state;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1237: register char *yy_cp;
> CLANG/lib/tsconfig/TsConfigSyntax.c:1245: register YY_CHAR yy_c =
> (*yy_cp ? yy_ec[YY_SC_TO_UI(*yy_cp)] : 1);
> CLANG/lib/tsconfig/TsConfigSyntax.c:1270: register int yy_is_jam;
> CLANG/lib/tsconfig/TsConf
[jira] [Resolved] (TS-1555) Lua Plugin doesn't work
[ https://issues.apache.org/jira/browse/TS-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1555. - Resolution: Cannot Reproduce Fix Version/s: (was: 3.3.4) Assignee: James Peach I could not reproduce this. > Lua Plugin doesn't work > --- > > Key: TS-1555 > URL: https://issues.apache.org/jira/browse/TS-1555 > Project: Traffic Server > Issue Type: Bug > Environment: Fedora 17 >Reporter: Luca Rea >Assignee: James Peach > > To compile correctly lua support I needed to create the following symbolic > link: > cd /usr/lib64 > ln -s liblua-5.1.so liblua5.1.so > After that I've tried to use "hooks.lua" in plugin.config but ATS returns the > following error: > "failed to load Lua file /usr/local/libexec/trafficserver/lua.so: > /usr/local/libexec/trafficserver/lua.so:1: unexpected symbol near 'char(127)' -- 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-1460) 3.0.x - make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1460: Fix Version/s: (was: 3.3.0) 3.2.5 > 3.0.x - make install should work as non-root user > - > > Key: TS-1460 > URL: https://issues.apache.org/jira/browse/TS-1460 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Jan-Frode Myklebust >Assignee: Leif Hedstrom >Priority: Trivial > Fix For: 3.2.5 > > Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff > > > "make install" should work as non-root user. Requirng root is bad practice > and causes problems for the fedora build system. -- 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-1470) 3.2.x - Large cache (> 16TB) not working?
[
https://issues.apache.org/jira/browse/TS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1470:
Fix Version/s: (was: 3.2.4)
3.2.5
> 3.2.x - Large cache (> 16TB) not working?
> -
>
> Key: TS-1470
> URL: https://issues.apache.org/jira/browse/TS-1470
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.2.0
> Environment: Centos 6.1
>Reporter: Jan van Doorn
>Assignee: Igor Galić
> Fix For: 3.2.5
>
> Attachments: 3.2.4.patch_for16tb_cache.diff, p1.txt
>
>
> Is there a maximum disk cache size in ATS 3.20? I seem to be getting this
> WARNING/Error:
> --
> [TrafficServer] using root directory '/opt/trafficserver'
> [Jun 21 21:57:10.038] {0x7f4d67aa67e0} STATUS: opened
> /opt/trafficserver/var/log/trafficserver/diags.log
> [Jun 21 21:57:10.038] {0x7f4d67aa67e0} NOTE: updated diags config
> [Jun 21 21:57:10.042] Server {0x7f4d67aa67e0} NOTE: cache clustering disabled
> [Jun 21 21:57:10.083] Server {0x7f4d67aa67e0} NOTE: cache clustering disabled
> [Jun 21 21:57:10.182] Server {0x7f4d67aa67e0} NOTE: logging initialized[11],
> logging_mode = 3
> [Jun 21 21:57:10.183] Server {0x7f4d67aa67e0} NOTE: loading plugin
> '/opt/trafficserver/libexec/trafficserver/stats_over_http.so'
> [Jun 21 21:57:10.185] Server {0x7f4d67aa67e0} NOTE: traffic server running
> [Jun 21 21:57:10.189] Server {0x7f4d63799700} WARNING: not enough space to
> increase volume: [1] to size: [20585472]
> [Jun 21 21:57:10.189] Server {0x7f4d63799700} NOTE: edit the volume.config
> file and restart traffic_server
> [Jun 21 21:57:10.189] Server {0x7f4d63799700} NOTE: cache disabled
> --
> When I try to use more than a certain amount (16TB?) of cache, and the "cache
> disabled" message doesn't seem good.
> I have a system with 24 600GB drives that works well, but a system with 24
> 900GB drives will have the above error, unless I disable at least 5 drives in
> storage.config.
> I tried splitting the cache up in to 2 volumes, each 50% in volume.config,
> but I still get the same error.
--
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-727) Do we need support for "streams" partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-727: --- Fix Version/s: (was: 2.0.0) sometime > Do we need support for "streams" partitions? > > > Key: TS-727 > URL: https://issues.apache.org/jira/browse/TS-727 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom > Fix For: sometime > > > There's code in the cache related to MIXT streams volumes (caches). Since we > don't support streams, I'm thinking this code could be removed? Or > alternatively, we should expose APIs so that someone writing a plugin and > wish to store a different protocol (e.g. QT) can register this media type > with the API and core. The idea being that the core only contains protocols > that are in the core, but expose the cache core so that plugins can take > advantage of it. -- 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] [Resolved] (TS-154) Review of fast-path code paths in code base
[ https://issues.apache.org/jira/browse/TS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-154. Resolution: Cannot Reproduce Fix Version/s: (was: sometime) I looked in ink_memory.cc and there are no issues there. It's not clear what else is being referred to here. Let's file new bugs if there's anything left. > Review of fast-path code paths in code base > --- > > Key: TS-154 > URL: https://issues.apache.org/jira/browse/TS-154 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0a > Environment: All >Reporter: George Paul >Priority: Minor > > During cleanup in 3.0 it would be good to re-evaluate the fast-path code > paths in the code base (e.g. 'ink_memory.cc',etc) and determine through > benchmarks and testing as to their current applicability. > -George -- 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] [Resolved] (TS-666) Evil catch-all bug
[ https://issues.apache.org/jira/browse/TS-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-666. Resolution: Not A Problem Fix Version/s: (was: sometime) Assignee: Leif Hedstrom no more evil > Evil catch-all bug > -- > > Key: TS-666 > URL: https://issues.apache.org/jira/browse/TS-666 > Project: Traffic Server > Issue Type: Bug >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > -- 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] [Resolved] (TS-201) Should we "borrow" HTTPDs release and roll tools?
[ https://issues.apache.org/jira/browse/TS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-201. Resolution: Won't Fix Fix Version/s: (was: sometime) Closing as per Igor's last comment. > Should we "borrow" HTTPDs release and roll tools? > - > > Key: TS-201 > URL: https://issues.apache.org/jira/browse/TS-201 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Igor Galić > > For more information, check out these scripts: > https://svn.apache.org/repos/asf/httpd/site/trunk/tools/release.sh > https://svn.apache.org/repos/asf/httpd/site/trunk/tools/roll.sh -- 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-199) Startup script should fail on "multiple" invocations of "start" (or "stop")
[ https://issues.apache.org/jira/browse/TS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-199: - Fix Version/s: (was: 3.3.1) > Startup script should fail on "multiple" invocations of "start" (or "stop") > --- > > Key: TS-199 > URL: https://issues.apache.org/jira/browse/TS-199 > Project: Traffic Server > Issue Type: Improvement > Components: Packaging >Reporter: Leif Hedstrom >Priority: Minor > Attachments: TS-199__trafficserver.in__JasonGiedymin.patch > > > If I do > # /etc/init.d/trafficserver start > # /etc/init.d/trafficserver start > I'd expect the second invocation to give an error, [NO]. Same thing with > stop, if I run stop multiple times, if there are no process(es) to stop, each > invocation ought to generate errors as well, e.g. > root@loki 507/0 # ./local/bin/trafficserver stop > Stopping : [ OK ] > Stopping : [ OK ] > Stopping : [ OK ] > root@loki 508/0 # ./local/bin/trafficserver stop > Stopping : [ NOT ] > Stopping : [ NOT ] > Stopping : [ NOT ] -- 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-1569) Client connections not closing correctly in Trunk
[ https://issues.apache.org/jira/browse/TS-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1569: -- Fix Version/s: (was: 3.3.1) > Client connections not closing correctly in Trunk > - > > Key: TS-1569 > URL: https://issues.apache.org/jira/browse/TS-1569 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.1 > Environment: Ubuntu 10.04 >Reporter: Kingsley Foreman > > The current trunk isn't closing connections to the client correctly. This has > caused many 10's of thousands of open connections until the system runs out > of FD's > /usr/bin/traffic_line -r proxy.node.current_client_connections && > /usr/bin/traffic_line -r proxy.node.current_server_connections > 407 > 5 > /usr/bin/traffic_line -r proxy.node.current_client_connections && > /usr/bin/traffic_line -r proxy.node.current_server_connections > 937 > 8 > These servers had only been up for a couple of hours. -- 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-1263) owner of mgmtapisocket can change if not compiling with libcap
[ https://issues.apache.org/jira/browse/TS-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1263: Fix Version/s: (was: sometime) 3.3.2 > owner of mgmtapisocket can change if not compiling with libcap > -- > > Key: TS-1263 > URL: https://issues.apache.org/jira/browse/TS-1263 > Project: Traffic Server > Issue Type: Bug > Components: Management >Affects Versions: 3.1.3 >Reporter: Bryan Call > Fix For: 3.3.2 > > > Sometimes the ownership of mgmtapisocket is nobody and sometimes it is root. > This is only seen if you don't link with libcap. > The thread that creates the unix-socket (mgmtapisocket) is created before ATS > binds its ports. There is a race between seteuid() called from > restoreRootPriv() before we bind() the sockets and the creation of the > unix-socket in the "web agent thread". > If ATS binds the ports before the thread is created that creates > mgmtapisocket then the proper ownership of mgmtapisocket happens (owned by > nobody). -- 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-1529) transaction_no_activity_timeout_out do not work correct
[ https://issues.apache.org/jira/browse/TS-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1529: -- Fix Version/s: (was: 3.3.1) > transaction_no_activity_timeout_out do not work correct > > > Key: TS-1529 > URL: https://issues.apache.org/jira/browse/TS-1529 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: timeout.patch > > -- 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-1746) Crash report: UnixNetVConnection::reenable > ink_atomiclist_push > ink_atomic_cas
[
https://issues.apache.org/jira/browse/TS-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603510#comment-13603510
]
Brian Geffon commented on TS-1746:
--
Do you guys think we should revert TS-1742?
> Crash report: UnixNetVConnection::reenable > ink_atomiclist_push >
> ink_atomic_cas
> --
>
> Key: TS-1746
> URL: https://issues.apache.org/jira/browse/TS-1746
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Zhao Yongming
>Assignee: Brian Geffon
>
> I think the recent changes cause this crash, and here is the stack trace:
> {code}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x72492700 (LWP 23610)]
> 0x77bb30a5 in ink_atomic_cas<__int128> (mem=0x73cae288,
> prev=0x0001,
> next=0x7fffd4014501)
> at ink_atomic.h:153
> 153 return __sync_bool_compare_and_swap(mem, prev, next);
> (gdb) bt
> #0 0x77bb30a5 in ink_atomic_cas<__int128> (mem=0x73cae288,
> prev=0x0001,
> next=0x7fffd4014501)
> at ink_atomic.h:153
> #1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
> item=0x7fffd4014500) at ink_queue.cc:481
> #2 0x006d8961 in AtomicSLL UnixNetVConnection::Link_read_enable_link>::push (this=0x73cae288,
> c=0x7fffd4014500)
> at ../../lib/ts/List.h:477
> #3 0x006d6767 in UnixNetVConnection::reenable (this=0x7fffd4014500,
> vio=0x7fffd4014610) at UnixNetVConnection.cc:721
> #4 0x005195d5 in VIO::reenable (this=0x7fffd4014610) at
> ../iocore/eventsystem/P_VIO.h:124
> #5 0x005c73b1 in HttpTunnel::consumer_handler (this=0x7fffdbefb888,
> event=101, c=0x7fffdbefb8c8) at HttpTunnel.cc:1237
> #6 0x005c7c1f in HttpTunnel::main_handler (this=0x7fffdbefb888,
> event=101, data=0x7fffc4008870) at HttpTunnel.cc:1481
> #7 0x004f8aa6 in Continuation::handleEvent (this=0x7fffdbefb888,
> event=101, data=0x7fffc4008870) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0050a612 in TSContCall (contp=0x7fffdbefb888,
> event=TS_EVENT_VCONN_WRITE_READY, edata=0x7fffc4008870) at InkAPI.cc:4400
> #9 0x0055f302 in handle_transform (contp=0x7fffc40087c0) at
> InkAPITest.cc:6435
> #10 0x0055f4be in transformtest_transform (contp=0x7fffc40087c0,
> event=TS_EVENT_IMMEDIATE, edata=0x1166920) at InkAPITest.cc:6501
> #11 0x00501922 in INKVConnInternal::handle_event
> (this=0x7fffc40087c0, event=1, edata=0x1166920) at InkAPI.cc:1045
> #12 0x004f8aa6 in Continuation::handleEvent (this=0x7fffc40087c0,
> event=1, data=0x1166920) at ../iocore/eventsystem/I_Continuation.h:146
> #13 0x006f823d in EThread::process_event (this=0x73aa9010,
> e=0x1166920, calling_code=1) at UnixEThread.cc:142
> #14 0x006f8491 in EThread::execute (this=0x73aa9010) at
> UnixEThread.cc:193
> #15 0x006f744c in spawn_thread_internal (a=0x1090810) at Thread.cc:88
> #16 0x7793dea7 in start_thread () from /lib64/libpthread.so.0
> #17 0x751c114d in clone () from /lib64/libc.so.6
> (gdb) l
> 148 // ink_atomic_cas(mem, prev, next)
> 149 // Atomically store the value @next into the pointer @mem, but only
> if the current value at @mem is @prev.
> 150 // Returns true if @next was successfully stored.
> 151 template static inline bool
> 152 ink_atomic_cas(volatile T * mem, T prev, T next) {
> 153 return __sync_bool_compare_and_swap(mem, prev, next);
> 154 }
> 155
> 156 // ink_atomic_increment(ptr, count)
> 157 // Increment @ptr by @count, returning the previous value.
> (gdb) f 1
> #1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
> item=0x7fffd4014500) at ink_queue.cc:481
> 481result = ink_atomic_cas((__int128_t*) & l->head, head.data,
> item_pair.data);
> (gdb) p head.data
> $1 = 0x0001
> (gdb) p head
> $2 = {s = {pointer = 0x1, version = 0}, data =
> 0x0001}
> (gdb)
> {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] [Resolved] (TS-1131) fails to build on RHEL6 ppc64
[ https://issues.apache.org/jira/browse/TS-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1131. - Resolution: Won't Fix Fix Version/s: (was: sometime) Assignee: James Peach We don't have any plans to support PPC. > fails to build on RHEL6 ppc64 > - > > Key: TS-1131 > URL: https://issues.apache.org/jira/browse/TS-1131 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 3.0.3 > Environment: RHEL6 ppc64 >Reporter: Jan-Frode Myklebust >Assignee: James Peach > > I fail to build ats 3.0.3 on RHEL6/ppc64. It fails with the message: > #error "unsupported processor" > from lib/ts/ink_queue.h:119. > Ref: > http://koji.fedoraproject.org/koji/getfile?taskID=3884843&name=build.log -- 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-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-998: - Fix Version/s: (was: 3.3.1) > Broken ClientReq in TSAPI > - > > Key: TS-998 > URL: https://issues.apache.org/jira/browse/TS-998 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.1 > Environment: any >Reporter: Nick Kew >Assignee: Nick Kew > > Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request > line. > Expected behaviour: In a PRE_REMAP hook it should return the client request > line and headers, ideally verbatim. > Observed behaviour: "http://"; is prepended to the request URL: > GET /path/ HTTP/1.1 > becomes > GET http:///path/ HTTP/1.1 > (yes, that's three slashes) > Pseudo-code to reproduce from a PRE_REMAP hook: > TSHttpTxnClientReqGet(txnp, &buf, &hdr); > TSHttpHdrPrint(buf, hdr, iobuf); > reader = TSIOBufferReaderAlloc(iobuf); > block = TSIOBufferReaderStart(reader); > len = TSIOBufferBlockReadAvail(block, reader); > data = TSIOBufferBlockReadStart(block, reader, &len); > Now examine the contents of data. > Assigned to AMC as suggested yesterday on-list. -- 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-942) Assert in HttpTransact::HandleCacheOpenReadMiss
[
https://issues.apache.org/jira/browse/TS-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-942:
-
Fix Version/s: (was: 3.3.1)
> Assert in HttpTransact::HandleCacheOpenReadMiss
> ---
>
> Key: TS-942
> URL: https://issues.apache.org/jira/browse/TS-942
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.1
>Reporter: Leif Hedstrom
>Priority: Critical
>
> I'm seeing a crasher (see below), and it happens in code like this:
> {code}
> if (s->current.server->ip == 0) {
> ink_release_assert(s->current.request_to == PARENT_PROXY ||
> s->http_config_param->no_dns_forward_to_parent != 0);
> if (s->current.request_to == PARENT_PROXY) {
> {code}
> What happens is that .server->ip is indeed 0, but current.request_to is !=
> PARENT_PROXY (it is instead ORIGIN_SERVER). I've not seen this before, and it
> reproduces rarely, so wondering if it could be IPv6 related.
> Crasher:
> {code}
> (gdb) bt
> #0 0x003f2de327f5 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x003f2de33fd5 in abort () at abort.c:92
> #2 0x006407a1 in ink_die_die_die (return_code=,
> message_format=, ap=0x2b0756137600) at ink_error.cc:43
> #3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
> (return_code=, message_format=,
> ap=0x2b0756137600) at ink_error.cc:65
> #4 0x006408d6 in ink_fatal (return_code=,
> message_format=) at ink_error.cc:73
> #5 0x0063f761 in _ink_assert (a=0x668400 "s->current.request_to ==
> PARENT_PROXY || s->http_config_param->no_dns_forward_to_parent != 0",
> f=, l=2952) at ink_assert.cc:44
> #6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
> (s=0x2b0763638018) at HttpTransact.cc:2952
> #7 0x004f08e2 in HttpSM::call_transact_and_set_next_state
> (this=0x2b0763637fb0, f=) at HttpSM.cc:6339
> #8 0x004fffda in HttpSM::handle_api_return (this=0x2b0763637fb0) at
> HttpSM.cc:1520
> #9 0x004f2d42 in HttpSM::state_hostdb_lookup (this= out>, event=, data=) at
> HttpSM.cc:2064
> #10 0x00503de0 in HttpSM::main_handler (this=0x2b0763637fb0,
> event=500, data=0x2b0760231860) at HttpSM.cc:2454
> #11 0x0058d07b in handleEvent (cont=0x2b0763637fb0,
> ar=0x2b0760231860) at ../../iocore/eventsystem/I_Continuation.h:146
> #12 reply_to_cont (cont=0x2b0763637fb0, ar=0x2b0760231860) at HostDB.cc:552
> #13 0x0058e939 in HostDBContinuation::dnsEvent (this= out>, event=, e=) at HostDB.cc:1504
> #14 0x0059d281 in handleEvent (this=0x2a1c340, event= out>, e=) at
> ../../iocore/eventsystem/I_Continuation.h:146
> #15 DNSEntry::postEvent (this=0x2a1c340, event=,
> e=) at DNS.cc:1265
> #16 0x00638204 in handleEvent (this=0x2b0755e36010, e=0x2a61090,
> calling_code=1) at I_Continuation.h:146
> #17 EThread::process_event (this=0x2b0755e36010, e=0x2a61090, calling_code=1)
> at UnixEThread.cc:140
> #18 0x00638c7b in EThread::execute (this=0x2b0755e36010) at
> UnixEThread.cc:189
> #19 0x00637052 in spawn_thread_internal (a=0x1b206b0) at Thread.cc:88
> #20 0x003f2e6068e0 in start_thread (arg=0x2b0756138710) at
> pthread_create.c:297
> #21 0x003f2dee0c9d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #22 0x in ?? ()
> (gdb) frame 6
> #6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
> (s=0x2b0763638018) at HttpTransact.cc:2952
> 2952s->http_config_param->no_dns_forward_to_parent != 0);
> (gdb) print s->current.request_to
> $1 = ORIGIN_SERVER
> (gdb) print s->current.server->ip
> $2 = 0
> {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-1324) inactivitycop performance may need to improve
[ https://issues.apache.org/jira/browse/TS-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1324: -- Fix Version/s: (was: 3.3.1) > inactivitycop performance may need to improve > - > > Key: TS-1324 > URL: https://issues.apache.org/jira/browse/TS-1324 > Project: Traffic Server > Issue Type: Sub-task > Components: Network >Affects Versions: 3.3.0 >Reporter: Zhao Yongming > > inactivitycop is a scheduled on each net thread, for every 1s it will check > all the connections status, how can we manage millions of connections? -- 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-208) OSX: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-208: - Fix Version/s: (was: 3.3.1) > OSX: Add raw disk support for the cache > --- > > Key: TS-208 > URL: https://issues.apache.org/jira/browse/TS-208 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 2.1.0 > Environment: OSX(10.5,10.6) >Reporter: George Paul >Assignee: Dan Mercer > > Currently only a file cache is supported on OSX. It would be nice to have Raw > Disk support before 2.1 release. > -George -- 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-1353) request for do remap in forwarding proxy
[ https://issues.apache.org/jira/browse/TS-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1353: -- Fix Version/s: (was: 3.3.1) > request for do remap in forwarding proxy > > > Key: TS-1353 > URL: https://issues.apache.org/jira/browse/TS-1353 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Affects Versions: 3.3.1 >Reporter: Zhao Yongming > > in forwarding proxy, there is noway to do remap while doing forwarding, we > need a way to work around some custom remap ie: > map http://www.google.com/ http://ipv6.google.com/ > please consider of implement it in forward parts -- 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-1749) Stats cluster values among nodes are not consistent
[
https://issues.apache.org/jira/browse/TS-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-1749:
-
Description:
In my testing, I setup a cluster consist of two nodes: test62/test63.
And then, using jtest to do some requests for node test62.
Finally, I stopped jtest, and picked up some stats value shown as below from
these two ndoes:
{code}
Node test62:
---
[root@test62 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=271218334
proxy.node.http.origin_server_total_request_bytes=271218334
proxy.cluster.http.origin_server_total_request_bytes=271218334
Node test63:
---
[root@test63 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=0
proxy.node.http.origin_server_total_request_bytes=0
proxy.cluster.http.origin_server_total_request_bytes=23973809347
{code}
Obviously, the stats cluster value:
*proxy.cluster.http.origin_server_total_request_bytes* is not consistent among
two nodes.
was:
In my testing, I setup a cluster consist of two nodes: test62/test63.
And then, using jtest to do some requests for node test62.
Finally, I stopped jtest, and picked up some stats value shown as below from
these two ndoes:
{code}
Node test62:
---
[root@test62 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=271218334
proxy.node.http.origin_server_total_request_bytes=271218334
proxy.cluster.http.origin_server_total_request_bytes=271218334
Node B:
---
[root@test63 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=0
proxy.node.http.origin_server_total_request_bytes=0
proxy.cluster.http.origin_server_total_request_bytes=23973809347
{code}
Obviously, the stats cluster value:
*proxy.cluster.http.origin_server_total_request_bytes* is not consistent among
two nodes.
> Stats cluster values among nodes are not consistent
> ---
>
> Key: TS-1749
> URL: https://issues.apache.org/jira/browse/TS-1749
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>
> In my testing, I setup a cluster consist of two nodes: test62/test63.
> And then, using jtest to do some requests for node test62.
> Finally, I stopped jtest, and picked up some stats value shown as below from
> these two ndoes:
> {code}
> Node test62:
> ---
> [root@test62 ~]# list-cluster.sh
> proxy.process.http.origin_server_request_document_total_size=0
> proxy.process.http.origin_server_request_header_total_size=271218334
> proxy.node.http.origin_server_total_request_bytes=271218334
> proxy.cluster.http.origin_server_total_request_bytes=271218334
> Node test63:
> ---
> [root@test63 ~]# list-cluster.sh
> proxy.process.http.origin_server_request_document_total_size=0
> proxy.process.http.origin_server_request_header_total_size=0
> proxy.node.http.origin_server_total_request_bytes=0
> proxy.cluster.http.origin_server_total_request_bytes=23973809347
> {code}
> Obviously, the stats cluster value:
> *proxy.cluster.http.origin_server_total_request_bytes* is not consistent
> among two 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-1749) Stats cluster values among nodes are not consistent
Yunkai Zhang created TS-1749:
Summary: Stats cluster values among nodes are not consistent
Key: TS-1749
URL: https://issues.apache.org/jira/browse/TS-1749
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Yunkai Zhang
In my testing, I setup a cluster consist of two nodes: {test62, test63}.
And then, using jtest to do some requests for node test62.
Finally, I stopped jtest, and picked up some stats value shown as below from
these two ndoes:
{code}
Node test62:
---
[root@test62 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=271218334
proxy.node.http.origin_server_total_request_bytes=271218334
proxy.cluster.http.origin_server_total_request_bytes=271218334
Node B:
---
[root@test63 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=0
proxy.node.http.origin_server_total_request_bytes=0
proxy.cluster.http.origin_server_total_request_bytes=23973809347
{code}
Obviously, the stats cluster value:
*proxy.cluster.http.origin_server_total_request_bytes* is not consistent among
two 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] [Updated] (TS-1749) Stats cluster values among nodes are not consistent
[
https://issues.apache.org/jira/browse/TS-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-1749:
-
Description:
In my testing, I setup a cluster consist of two nodes: test62/test63.
And then, using jtest to do some requests for node test62.
Finally, I stopped jtest, and picked up some stats value shown as below from
these two ndoes:
{code}
Node test62:
---
[root@test62 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=271218334
proxy.node.http.origin_server_total_request_bytes=271218334
proxy.cluster.http.origin_server_total_request_bytes=271218334
Node B:
---
[root@test63 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=0
proxy.node.http.origin_server_total_request_bytes=0
proxy.cluster.http.origin_server_total_request_bytes=23973809347
{code}
Obviously, the stats cluster value:
*proxy.cluster.http.origin_server_total_request_bytes* is not consistent among
two nodes.
was:
In my testing, I setup a cluster consist of two nodes: {test62, test63}.
And then, using jtest to do some requests for node test62.
Finally, I stopped jtest, and picked up some stats value shown as below from
these two ndoes:
{code}
Node test62:
---
[root@test62 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=271218334
proxy.node.http.origin_server_total_request_bytes=271218334
proxy.cluster.http.origin_server_total_request_bytes=271218334
Node B:
---
[root@test63 ~]# list-cluster.sh
proxy.process.http.origin_server_request_document_total_size=0
proxy.process.http.origin_server_request_header_total_size=0
proxy.node.http.origin_server_total_request_bytes=0
proxy.cluster.http.origin_server_total_request_bytes=23973809347
{code}
Obviously, the stats cluster value:
*proxy.cluster.http.origin_server_total_request_bytes* is not consistent among
two nodes.
> Stats cluster values among nodes are not consistent
> ---
>
> Key: TS-1749
> URL: https://issues.apache.org/jira/browse/TS-1749
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>
> In my testing, I setup a cluster consist of two nodes: test62/test63.
> And then, using jtest to do some requests for node test62.
> Finally, I stopped jtest, and picked up some stats value shown as below from
> these two ndoes:
> {code}
> Node test62:
> ---
> [root@test62 ~]# list-cluster.sh
> proxy.process.http.origin_server_request_document_total_size=0
> proxy.process.http.origin_server_request_header_total_size=271218334
> proxy.node.http.origin_server_total_request_bytes=271218334
> proxy.cluster.http.origin_server_total_request_bytes=271218334
> Node B:
> ---
> [root@test63 ~]# list-cluster.sh
> proxy.process.http.origin_server_request_document_total_size=0
> proxy.process.http.origin_server_request_header_total_size=0
> proxy.node.http.origin_server_total_request_bytes=0
> proxy.cluster.http.origin_server_total_request_bytes=23973809347
> {code}
> Obviously, the stats cluster value:
> *proxy.cluster.http.origin_server_total_request_bytes* is not consistent
> among two 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
