[jira] [Updated] (TS-867) PluginVC crashes with TSFetchURL
[
https://issues.apache.org/jira/browse/TS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-867:
--
Backport to Version: (was: 3.0.2)
Fix Version/s: 3.0.2
PluginVC crashes with TSFetchURL
Key: TS-867
URL: https://issues.apache.org/jira/browse/TS-867
Project: Traffic Server
Issue Type: Bug
Reporter: Naveen
Assignee: Igor Galić
Labels: api, plugin
Fix For: 3.1.0, 3.0.2
On TSFetchURL call, the call_event in PluginVC does not match with any of the
events(active_event,inactive_event,core_lock_retry_event,sm_lock_retry_event).
However, on trace analysis it actually matches with sm_lock_retry_event.
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7a1ae71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7a1e34e in abort () at abort.c:92
#3 0xb7fad9a4 in ink_die_die_die (retval=1) at ink_error.cc:43
#4 0xb7fada79 in ink_fatal_va (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`,
ap=0xb5767f38 ) at ink_error.cc:65
#5 0xb7fadabd in ink_fatal (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`)
at ink_error.cc:73
#6 0xb7fac684 in _ink_assert (a=0x8302b10 call_event ==
core_lock_retry_event, f=0x8302a2d PluginVC.cc, l=193) at ink_assert.cc:44
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
#8 0x0810bd47 in Continuation::handleEvent (this=0x896a7fc, event=1,
data=0x8999890) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x082f2a8a in EThread::process_event (this=0xb6577008, e=0x8999890,
calling_code=1) at UnixEThread.cc:140
#10 0x082f2f30 in EThread::execute (this=0xb6577008) at UnixEThread.cc:232
#11 0x082f1b75 in spawn_thread_internal (a=0x891a1e0) at Thread.cc:85
#12 0xb7f89e99 in start_thread (arg=0xb5768b70) at pthread_create.c:304
#13 0xb7ac073e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) f 7
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
193 ink_release_assert(call_event == core_lock_retry_event);
(gdb) print *this
$1 = {NetVConnection = {VConnection = {Continuation =
{force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x8303188}, handler = (
int (Continuation::*)(Continuation *, int, void *)) 0x813dc66
PluginVC::main_handler(int, void*),
handler_name = 0x8302a06 PluginVC::main_handler, mutex = {m_ptr =
0x8979c30}, link = {SLinkContinuation = {next = 0x0},
prev = 0x0}}, lerrno = 0}, options = {ip_proto =
NetVCOptions::USE_TCP, local_port = 0, port_binding = NetVCOptions::ANY_PORT,
local_addr = 0, addr_binding = NetVCOptions::ANY_ADDR, f_blocking =
false, f_blocking_connect = false, socks_support = 0 '\000',
socks_version = 0 '\000', socket_recv_bufsize = 0, socket_send_bufsize
= 0, sockopt_flags = 0, static SOCK_OPT_NO_DELAY = 1,
static SOCK_OPT_KEEP_ALIVE = 2, etype = 0}, socks_addr = {type = 0
'\000', addr = {ipv4 = \000\000\000, buf = 0x0}}, attributes = 0,
thread = 0xb6a7c008, local_addr = {ss_family = 0, __ss_align = 0,
__ss_padding = '\000' repeats 119 times}, remote_addr = {ss_family = 0,
__ss_align = 0, __ss_padding = '\000' repeats 119 times},
got_local_addr = 0, got_remote_addr = 0, is_internal_request = false,
is_transparent = 49, is_other_side_transparent = false}, magic =
2864434397, vc_type = PLUGIN_VC_ACTIVE, core_obj = 0x896a7e0,
other_side = 0x896a9fc, read_state = {vio = {_cont = 0x8970e30, nbytes =
9223372036854775807, ndone = 0, op = 1, buffer = {mbuf = 0x8995b40,
entry = 0x0, name = 0x0}, vc_server = 0x896a7fc, mutex = {m_ptr =
0x89b8a60}}, shutdown = false}, write_state = {vio = {
_cont = 0x8970e30, nbytes = 188, ndone = 0, op = 2, buffer = {mbuf =
0x8994d80, entry = 0x8994d94, name = 0x0}, vc_server = 0x896a7fc,
mutex = {m_ptr = 0x89b8a60}}, shutdown = false}, need_read_process =
true, need_write_process = true, closed = false,
sm_lock_retry_event = 0x8999890, core_lock_retry_event = 0x0, deletable =
false, reentrancy_count = 1, active_timeout = 0,
inactive_timeout = 0, active_event = 0x0, inactive_event = 0x0}
(gdb) print sm_lock_retry_event
$5 = (Event *) 0x8999890
(gdb) print call_event
$6 = (Event *) 0x8999890
(gdb) print this-write_state-vio-_cont-handler_name
$7 = 0x82fae82 FetchSM::fetch_handler
(gdb) print this-read_state-vio-_cont-handler_name
$8 = 0x82fae82 FetchSM::fetch_handler
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] [Resolved] (TS-867) PluginVC crashes with TSFetchURL
[
https://issues.apache.org/jira/browse/TS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić resolved TS-867.
---
Resolution: Fixed
PluginVC crashes with TSFetchURL
Key: TS-867
URL: https://issues.apache.org/jira/browse/TS-867
Project: Traffic Server
Issue Type: Bug
Reporter: Naveen
Assignee: Igor Galić
Labels: api, plugin
Fix For: 3.0.2, 3.1.0
On TSFetchURL call, the call_event in PluginVC does not match with any of the
events(active_event,inactive_event,core_lock_retry_event,sm_lock_retry_event).
However, on trace analysis it actually matches with sm_lock_retry_event.
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7a1ae71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7a1e34e in abort () at abort.c:92
#3 0xb7fad9a4 in ink_die_die_die (retval=1) at ink_error.cc:43
#4 0xb7fada79 in ink_fatal_va (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`,
ap=0xb5767f38 ) at ink_error.cc:65
#5 0xb7fadabd in ink_fatal (return_code=1, message_format=0xb5767f5c
PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`)
at ink_error.cc:73
#6 0xb7fac684 in _ink_assert (a=0x8302b10 call_event ==
core_lock_retry_event, f=0x8302a2d PluginVC.cc, l=193) at ink_assert.cc:44
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
#8 0x0810bd47 in Continuation::handleEvent (this=0x896a7fc, event=1,
data=0x8999890) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x082f2a8a in EThread::process_event (this=0xb6577008, e=0x8999890,
calling_code=1) at UnixEThread.cc:140
#10 0x082f2f30 in EThread::execute (this=0xb6577008) at UnixEThread.cc:232
#11 0x082f1b75 in spawn_thread_internal (a=0x891a1e0) at Thread.cc:85
#12 0xb7f89e99 in start_thread (arg=0xb5768b70) at pthread_create.c:304
#13 0xb7ac073e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) f 7
#7 0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1,
data=0x8999890) at PluginVC.cc:193
193 ink_release_assert(call_event == core_lock_retry_event);
(gdb) print *this
$1 = {NetVConnection = {VConnection = {Continuation =
{force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x8303188}, handler = (
int (Continuation::*)(Continuation *, int, void *)) 0x813dc66
PluginVC::main_handler(int, void*),
handler_name = 0x8302a06 PluginVC::main_handler, mutex = {m_ptr =
0x8979c30}, link = {SLinkContinuation = {next = 0x0},
prev = 0x0}}, lerrno = 0}, options = {ip_proto =
NetVCOptions::USE_TCP, local_port = 0, port_binding = NetVCOptions::ANY_PORT,
local_addr = 0, addr_binding = NetVCOptions::ANY_ADDR, f_blocking =
false, f_blocking_connect = false, socks_support = 0 '\000',
socks_version = 0 '\000', socket_recv_bufsize = 0, socket_send_bufsize
= 0, sockopt_flags = 0, static SOCK_OPT_NO_DELAY = 1,
static SOCK_OPT_KEEP_ALIVE = 2, etype = 0}, socks_addr = {type = 0
'\000', addr = {ipv4 = \000\000\000, buf = 0x0}}, attributes = 0,
thread = 0xb6a7c008, local_addr = {ss_family = 0, __ss_align = 0,
__ss_padding = '\000' repeats 119 times}, remote_addr = {ss_family = 0,
__ss_align = 0, __ss_padding = '\000' repeats 119 times},
got_local_addr = 0, got_remote_addr = 0, is_internal_request = false,
is_transparent = 49, is_other_side_transparent = false}, magic =
2864434397, vc_type = PLUGIN_VC_ACTIVE, core_obj = 0x896a7e0,
other_side = 0x896a9fc, read_state = {vio = {_cont = 0x8970e30, nbytes =
9223372036854775807, ndone = 0, op = 1, buffer = {mbuf = 0x8995b40,
entry = 0x0, name = 0x0}, vc_server = 0x896a7fc, mutex = {m_ptr =
0x89b8a60}}, shutdown = false}, write_state = {vio = {
_cont = 0x8970e30, nbytes = 188, ndone = 0, op = 2, buffer = {mbuf =
0x8994d80, entry = 0x8994d94, name = 0x0}, vc_server = 0x896a7fc,
mutex = {m_ptr = 0x89b8a60}}, shutdown = false}, need_read_process =
true, need_write_process = true, closed = false,
sm_lock_retry_event = 0x8999890, core_lock_retry_event = 0x0, deletable =
false, reentrancy_count = 1, active_timeout = 0,
inactive_timeout = 0, active_event = 0x0, inactive_event = 0x0}
(gdb) print sm_lock_retry_event
$5 = (Event *) 0x8999890
(gdb) print call_event
$6 = (Event *) 0x8999890
(gdb) print this-write_state-vio-_cont-handler_name
$7 = 0x82fae82 FetchSM::fetch_handler
(gdb) print this-read_state-vio-_cont-handler_name
$8 = 0x82fae82 FetchSM::fetch_handler
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on
[jira] [Updated] (TS-970) ts crash when use evacuate feature
[
https://issues.apache.org/jira/browse/TS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-970:
-
Fix Version/s: 3.1.1
ts crash when use evacuate feature
--
Key: TS-970
URL: https://issues.apache.org/jira/browse/TS-970
Project: Traffic Server
Issue Type: Bug
Environment: {noformat}
# uname -a
Linux cache170.cn63 2.6.32-131.4.1.tb204.el5.x86_64 #1 SMP Fri Jul 1 22:17:55
CST 2011 x86_64 x86_64 x86_64 GNU/Linux
{noformat}
Reporter: mohan_zl
Fix For: 3.1.1
Attachments: TS-970-1.patch
My config arguments:
start trafficserver in one machine 1
{code}
# traffic_line -s proxy.config.cache.hit_evacuate_percent -v 5 // by
default, the value is 0, means no evacuation
# cat storage.config //the size of storage file is 5G
/dev/sda1
{code}
My test method:
use http_load from another machine 2 to test machine 1
{code}
# http_load -parallel 500 -fetches 1000 -proxy xxx.xx.xx.xxx:8080
mohan_urls
# wc -l mohan_urls
40849490 mohan_urls
# sort mohan_urls | uniq -c mohan_urls_1; wc -l mohan_urls_1
14057051 mohan_urls_1
# ls -al
-rw-r--r-- 1 root root 3253681200 Sep 21 20:42 mohan_urls
-rw-r--r-- 1 root root 1305299567 Sep 21 21:27 mohan_urls_1
The total access urls' size is larger than the storage size
{code}
Crash result:
{code}
(gdb) bt
#0 0x003639c30265 in raise () from /lib64/libc.so.6
#1 0x003639c31d10 in abort () from /lib64/libc.so.6
#2 0x2aaaee6d86fa in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2aaaee6d8979 in ink_fatal_va (return_code=1,
message_format=0x424e6700 CacheWrite.cc:519: failed assert
`dir_pinned(dir)`,
ap=0x424e6600) at ink_error.cc:65
#4 0x2aaaee6d8b46 in ink_fatal (return_code=1, message_format=0x424e6700
CacheWrite.cc:519: failed assert `dir_pinned(dir)`)
at ink_error.cc:73
#5 0x2aaaee6d697a in _ink_assert (a=0x767108 dir_pinned(dir),
f=0x766a46 CacheWrite.cc, l=519) at ink_assert.cc:44
#6 0x006afaa2 in CacheVC::evacuateDocDone (this=0x2c371f80,
event=3900, e=0x0) at CacheWrite.cc:519
#7 0x004d3789 in Continuation::handleEvent (this=0x2c371f80,
event=3900, data=0x0) at I_Continuation.h:146
#8 0x006b0e7b in Vol::aggWrite (this=0x2e18a10, event=3900,
e=0x2e18ae0) at CacheWrite.cc:998
#9 0x006b1553 in Vol::evacuateWrite (this=0x2e18a10,
evacuator=0x2c371f80, event=3900, e=0x2e18ae0) at CacheWrite.cc:603
#10 0x006b2031 in Vol::evacuateDocReadDone (this=0x2e18a10,
event=3900, e=0x2e18ae0) at CacheWrite.cc:687
#11 0x004d3789 in Continuation::handleEvent (this=0x2e18a10,
event=3900, data=0x2e18ae0) at I_Continuation.h:146
#12 0x0068a532 in AIOCallbackInternal::io_complete (this=0x2e18ae0,
event=1, data=0x30687d0) at P_AIO.h:80
#13 0x004d3789 in Continuation::handleEvent (this=0x2e18ae0, event=1,
data=0x30687d0) at I_Continuation.h:146
#14 0x006f69b0 in EThread::process_event (this=0x2b22d010,
e=0x30687d0, calling_code=1) at UnixEThread.cc:142
#15 0x006f6cf2 in EThread::execute (this=0x2b22d010) at
UnixEThread.cc:219
#16 0x006f6337 in spawn_thread_internal (a=0x2d75190) at Thread.cc:88
#17 0x00363a8064a7 in start_thread () from /lib64/libpthread.so.0
#18 0x003639cd3c2d in clone () from /lib64/libc.so.6
{code}
{code}
(gdb) f 6
#6 0x006afaa2 in CacheVC::evacuateDocDone (this=0x2c371f80,
event=3900, e=0x0) at CacheWrite.cc:519
519 ink_assert(dir_pinned(dir));
(gdb) p cod-num_writers
$1 = 1
(gdb) p cod-max_writers
$2 = 5
(gdb) p cod-dont_update_directory
$3 = false
(gdb) p cod-move_resident_alt
$4 = false
(gdb) p cod-reading_vec
$5 = false
(gdb) p cod-writing_vec
$6 = true
(gdb) p cod-first_dir
$7 = {w = {61517, 5121, 14401, 59410, 0}}
(gdb) p cod-single_doc_dir
$8 = {w = {61517, 5121, 12585, 59410, 0}}
(gdb) p this-dir
$9 = {w = {10203, 5167, 14401, 59409, 0}}
(gdb) p this-overwrite_dir
$10 = {w = {20152, 5167, 10305, 59409, 0}}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything
[ https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-966: - Fix Version/s: 3.1.1 cache.config dest_domain= dest_hostname= dest_ip= do not match anything --- Key: TS-966 URL: https://issues.apache.org/jira/browse/TS-966 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Fix For: 3.1.1 Caching policies are not applied when using these options to match targets. It is also not very clear *what* dest_domain= vs dest_hostname= can match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-965: - Fix Version/s: 3.1.1 cache.config can't deal with both revalidate= and ttl-in-cache= specified - Key: TS-965 URL: https://issues.apache.org/jira/browse/TS-965 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Fix For: 3.1.1 If both of these options are specified (with the same time?), nothing is cached at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-971) Thread error in the cache evacuation feature
[
https://issues.apache.org/jira/browse/TS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-971:
-
Fix Version/s: 3.1.1
Thread error in the cache evacuation feature
Key: TS-971
URL: https://issues.apache.org/jira/browse/TS-971
Project: Traffic Server
Issue Type: Bug
Reporter: mohan_zl
Fix For: 3.1.1
Attachments: TS-evacuate-fix.patch
After fix the Bug TS-970, i go on testing the evacuate feature for the cache,
with the same environment and test methods, and this time, trafficserver
crash in another codes, somewhat strange.
{code}
(gdb) bt
#0 0x003639c30265 in raise () from /lib64/libc.so.6
#1 0x003639c31d10 in abort () from /lib64/libc.so.6
#2 0x2b9258e7e6fa in ink_die_die_die (retval=Could not find the frame
base for ink_die_die_die.
) at ink_error.cc:43
#3 0x2b9258e7e979 in ink_fatal_va (return_code=Could not find the frame
base for ink_fatal_va.
) at ink_error.cc:65
#4 0x2b9258e7eb46 in ink_fatal (return_code=Could not find the frame
base for ink_fatal.
) at ink_error.cc:73
#5 0x2b9258e7c97a in _ink_assert (a=Could not find the frame base for
_ink_assert.
) at ink_assert.cc:44
#6 0x004f45df in EThread::schedule (this=0x2be9c010,
e=0x2aaab4325e00, fast_signal=true)
at ../../iocore/eventsystem/P_UnixEThread.h:96
#7 0x006496db in EThread::schedule_imm_signal (this=0x2be9c010,
cont=0x302b948, callback_event=1, cookie=0x0)
at ../../iocore/eventsystem/P_UnixEThread.h:62
#8 0x006c4427 in aio_thread_main (arg=0x2c0d1820) at AIO.cc:528
#9 0x006c4afa in AIOThreadInfo::start (this=0x2c0d1820, event=1,
e=0x2a05650) at AIO.cc:188
#10 0x004d3789 in Continuation::handleEvent (this=0x2c0d1820,
event=1, data=0x2a05650) at I_Continuation.h:146
#11 0x006f705b in EThread::execute (this=0x2be9c010) at
UnixEThread.cc:289
#12 0x006f6307 in spawn_thread_internal (a=0x2c0d1870) at
Thread.cc:88
#13 0x00363a8064a7 in start_thread () from /lib64/libpthread.so.0
#14 0x003639cd3c2d in clone () from /lib64/libc.so.6
(gdb) f 8
#8 0x006c4427 in aio_thread_main (arg=0x2c0d1820) at AIO.cc:528
528 op-thread-schedule_imm_signal(op);
(gdb) p *op
$1 = {Continuation = {force_VFPT_to_top = {_vptr.force_VFPT_to_top =
0x760710},
handler = 0x68a4f6 AIOCallbackInternal::io_complete(int, void*),
handler_name = 0x75dfb0 AIOCallbackInternal::io_complete, mutex = {
m_ptr = 0x2c261f70}, link = {SLinkContinuation = {next = 0x0},
prev = 0x0}}, aiocb = {aio_fildes = 38, aio_buf = 0x2aabd80db000,
aio_nbytes = 3072, aio_offset = 3359854592, aio_reqprio = 0,
aio_lio_opcode = 1, aio_state = 0, aio__pad = {0}}, action = {_vptr.Action =
0x0,
continuation = 0x302b7c0, mutex = {m_ptr = 0x2c261f70}, cancelled =
0}, thread = 0x2be9c010, then = 0x0, aio_result = 3072}
(gdb) p ((CacheVC *)op-action-continuation)-io-aiocb
$1 = {aio_fildes = 38, aio_buf = 0x2aabd80db000, aio_nbytes = 3072,
aio_offset = 3359854592, aio_reqprio = 0, aio_lio_opcode = 1, aio_state = 0,
aio__pad = {0}}
(gdb) p ((CacheVC *)op-action-continuation)-handler_name
$2 = 0x75f372 CacheVC::handleReadDone
(gdb) p ((CacheVC *)op-action-continuation)-f.evacuator
$3 = 1
(gdb) p ((CacheVC *)op-action-continuation)-save_handler
$4 = 0x6afe9e CacheVC::evacuateReadHead(int, Event*)
(gdb) f 6
#6 0x004f45df in EThread::schedule (this=0x2be9c010,
e=0x2aaab4325e00, fast_signal=true)
at ../../iocore/eventsystem/P_UnixEThread.h:96
96ink_assert(tt == REGULAR);
(gdb) p tt
$2 = DEDICATED
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-964) No 64bit integer plugin APIs for HTTP headers
[ https://issues.apache.org/jira/browse/TS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-964: - Fix Version/s: 3.1.1 No 64bit integer plugin APIs for HTTP headers - Key: TS-964 URL: https://issues.apache.org/jira/browse/TS-964 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: William Bardwell Priority: Minor Fix For: 3.1.1 There are APIs for unsigned int, but stuff like content-length should be done as 64-bit values, so we should add TSMimeHdrFieldValueUint64Get(), TSMimeHdrFieldValueUint64Set(), TSMimeHdrFieldValueUint64Insert() or Int64 versions of those APIs (since the mime_* stuff seems to have unsigned int, int and int64, but no uint64). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
