[jira] [Commented] (TS-848) Crash Report: ShowNet::showConnectionsOnThread -> ShowCont::show
[
https://issues.apache.org/jira/browse/TS-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070292#comment-13070292
]
John Plevyak commented on TS-848:
-
I think this is fixed in 1150526, give it a try.
> Crash Report: ShowNet::showConnectionsOnThread -> ShowCont::show
>
>
> Key: TS-848
> URL: https://issues.apache.org/jira/browse/TS-848
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
> Labels: http_ui, network
> Fix For: 3.1.1
>
>
> when we use the {net} http_ui network interface, it crashed with the
> following information
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /usr/bin/traffic_server[0x51ba3e]
> /lib64/libpthread.so.0[0x3f89c0e7c0]
> [0x7fffd20544f8]
> /lib64/libc.so.6(vsnprintf+0x9a)[0x3f8906988a]
> /usr/bin/traffic_server(ShowCont::show(char const*, ...)+0x262)[0x638184]
> /usr/bin/traffic_server(ShowNet::showConnectionsOnThread(int,
> Event*)+0x481)[0x6ec7bf]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6f)[0x4d302f]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x6f9978]
> /usr/bin/traffic_server(EThread::execute()+0x94)[0x6f9b6a]
> /usr/bin/traffic_server(main+0x10c7)[0x4ff74d]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3f8901d994]
> /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4b2149]
> /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4b2149]
> [New process 31182]
> #0 0x003f890796d0 in strlen () from /lib64/libc.so.6
> (gdb) bt
> #0 0x003f890796d0 in strlen () from /lib64/libc.so.6
> #1 0x003f89046b69 in vfprintf () from /lib64/libc.so.6
> #2 0x003f8906988a in vsnprintf () from /lib64/libc.so.6
> #3 0x00638184 in ShowCont::show (this=0x2aaab44af600,
> s=0x7732b8
> "%d%s%d%d%s%d%d
> secs
> ago%d%d%d%d%d%d%d%d
> secs%d secs<"...) at ../../proxy/Show.h:62
> #4 0x006ec7bf in ShowNet::showConnectionsOnThread
> (this=0x2aaab44af600, event=1, e=0x2aaab5cc2080) at UnixNetPages.cc:75
> #5 0x004d302f in Continuation::handleEvent (this=0x2aaab44af600,
> event=1, data=0x2aaab5cc2080) at I_Continuation.h:146
> #6 0x006f9978 in EThread::process_event (this=0x2ae29010,
> e=0x2aaab5cc2080, calling_code=1) at UnixEThread.cc:140
> #7 0x006f9b6a in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:189
> #8 0x004ff74d in main (argc=3, argv=0x7fffd2054d88) at Main.cc:1958
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-887) Code cleanup
[ https://issues.apache.org/jira/browse/TS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-887: Attachment: code_cleanup3.patch I don't know why current codes is implemented like this, in linux, kernel 2.6.38, i think i can cut down the codes, not changing current logic. > Code cleanup > > > Key: TS-887 > URL: https://issues.apache.org/jira/browse/TS-887 > Project: Traffic Server > Issue Type: Bug >Reporter: mohan_zl > Attachments: code_cleanup1.patch, code_cleanup2.patch, > code_cleanup3.patch > > > Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-887) Code cleanup
[ https://issues.apache.org/jira/browse/TS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-887: Attachment: code_cleanup2.patch I think the enum structure is not used, so nuke it. > Code cleanup > > > Key: TS-887 > URL: https://issues.apache.org/jira/browse/TS-887 > Project: Traffic Server > Issue Type: Bug >Reporter: mohan_zl > Attachments: code_cleanup1.patch, code_cleanup2.patch > > > Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-887) Code cleanup
[ https://issues.apache.org/jira/browse/TS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-887: Attachment: code_cleanup1.patch Correct the code format > Code cleanup > > > Key: TS-887 > URL: https://issues.apache.org/jira/browse/TS-887 > Project: Traffic Server > Issue Type: Bug >Reporter: mohan_zl > Attachments: code_cleanup1.patch, code_cleanup2.patch > > > Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-887) Code cleanup
Code cleanup Key: TS-887 URL: https://issues.apache.org/jira/browse/TS-887 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Try to nuke some unused codes, not changing current logic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-886) Grace mode supported, very useful for slow origins
Grace mode supported, very useful for slow origins -- Key: TS-886 URL: https://issues.apache.org/jira/browse/TS-886 Project: Traffic Server Issue Type: New Feature Components: Cache, Core, HTTP Environment: N/A Reporter: Ricky Chan Priority: Minor Varnish has long supported a mode called "grace mode" see https://www.varnish-cache.org/docs/trunk/tutorial/handling_misbehaving_servers.html. This is useful in cases where the origin server is slow at generating data, and you can configure it to serve stale content while a backend job is fetching the object. I would suggest this feature be enhanced to include support for. * url regex match to apply grace to. * override must-revalidate so that grace can be used (I know this violates the RFC, but a cache admin can optionally do this on a per origin/url basis). For example I have some origins which take between 5 to 20 seconds to generate content and this is handy in these known cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-848) Crash Report: ShowNet::showConnectionsOnThread -> ShowCont::show
[
https://issues.apache.org/jira/browse/TS-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070236#comment-13070236
]
John Plevyak commented on TS-848:
-
Gack, many of those values (e.g. nbytes) are now 64-bit %lld.
> Crash Report: ShowNet::showConnectionsOnThread -> ShowCont::show
>
>
> Key: TS-848
> URL: https://issues.apache.org/jira/browse/TS-848
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
> Labels: http_ui, network
> Fix For: 3.1.1
>
>
> when we use the {net} http_ui network interface, it crashed with the
> following information
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /usr/bin/traffic_server[0x51ba3e]
> /lib64/libpthread.so.0[0x3f89c0e7c0]
> [0x7fffd20544f8]
> /lib64/libc.so.6(vsnprintf+0x9a)[0x3f8906988a]
> /usr/bin/traffic_server(ShowCont::show(char const*, ...)+0x262)[0x638184]
> /usr/bin/traffic_server(ShowNet::showConnectionsOnThread(int,
> Event*)+0x481)[0x6ec7bf]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6f)[0x4d302f]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x6f9978]
> /usr/bin/traffic_server(EThread::execute()+0x94)[0x6f9b6a]
> /usr/bin/traffic_server(main+0x10c7)[0x4ff74d]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3f8901d994]
> /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4b2149]
> /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4b2149]
> [New process 31182]
> #0 0x003f890796d0 in strlen () from /lib64/libc.so.6
> (gdb) bt
> #0 0x003f890796d0 in strlen () from /lib64/libc.so.6
> #1 0x003f89046b69 in vfprintf () from /lib64/libc.so.6
> #2 0x003f8906988a in vsnprintf () from /lib64/libc.so.6
> #3 0x00638184 in ShowCont::show (this=0x2aaab44af600,
> s=0x7732b8
> "%d%s%d%d%s%d%d
> secs
> ago%d%d%d%d%d%d%d%d
> secs%d secs<"...) at ../../proxy/Show.h:62
> #4 0x006ec7bf in ShowNet::showConnectionsOnThread
> (this=0x2aaab44af600, event=1, e=0x2aaab5cc2080) at UnixNetPages.cc:75
> #5 0x004d302f in Continuation::handleEvent (this=0x2aaab44af600,
> event=1, data=0x2aaab5cc2080) at I_Continuation.h:146
> #6 0x006f9978 in EThread::process_event (this=0x2ae29010,
> e=0x2aaab5cc2080, calling_code=1) at UnixEThread.cc:140
> #7 0x006f9b6a in EThread::execute (this=0x2ae29010) at
> UnixEThread.cc:189
> #8 0x004ff74d in main (argc=3, argv=0x7fffd2054d88) at Main.cc:1958
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070234#comment-13070234 ] John Plevyak edited comment on TS-866 at 7/24/11 7:25 PM: -- Sorry for the delay. I am looking at this patch. It needs a little bit of work: 1) it should be built on remove instead of read (it can still share internal states with read using the stack mechanism) 2) it should interlock writes from the aggregation buffer if they would overlap these writes 3) it needs to support clustering These are not huge changes, but they will require a bit of work. There are other features which need to touch this code as well, so I'll poke around. was (Author: jplevyak): Sorry for the delay. I am looking at this patch. It needs a little bit of work: 1) it should be built on remove instead of read (it can still share internal states with using the stack mechanism) 2) it should interlock writes from the aggregation buffer if they would overlap these writes 3) it needs to support clustering These are not huge changes, but they will require a bit of work. There are other features which need to touch this code as well, so I'll poke around. > Need way to clear contents of a cache entry > --- > > Key: TS-866 > URL: https://issues.apache.org/jira/browse/TS-866 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Affects Versions: 3.0.0 >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.0 > > Attachments: cache_erase.diff > > > I needed a way to clear a cache entry off of disk, not just forget about it. > The worry was about if you got content on a server that was illegal or a > privacy violation of some sort, we wanted a way to be able to tell customers > that after this step there was no way that TS could serve the content again. > The normal cache remove just clears the directory entry, but theoretically a > bug could allow that data out in some way. This was not intended to prevent > forensic analysis of the hardware being able to recover the data. And bugs > in low level drivers or the kernel could theoretically allow data to survive > due to block remapping or mis-management of disk caches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070234#comment-13070234 ] John Plevyak commented on TS-866: - Sorry for the delay. I am looking at this patch. It needs a little bit of work: 1) it should be built on remove instead of read (it can still share internal states with using the stack mechanism) 2) it should interlock writes from the aggregation buffer if they would overlap these writes 3) it needs to support clustering These are not huge changes, but they will require a bit of work. There are other features which need to touch this code as well, so I'll poke around. > Need way to clear contents of a cache entry > --- > > Key: TS-866 > URL: https://issues.apache.org/jira/browse/TS-866 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Affects Versions: 3.0.0 >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.0 > > Attachments: cache_erase.diff > > > I needed a way to clear a cache entry off of disk, not just forget about it. > The worry was about if you got content on a server that was illegal or a > privacy violation of some sort, we wanted a way to be able to tell customers > that after this step there was no way that TS could serve the content again. > The normal cache remove just clears the directory entry, but theoretically a > bug could allow that data out in some way. This was not intended to prevent > forensic analysis of the hardware being able to recover the data. And bugs > in low level drivers or the kernel could theoretically allow data to survive > due to block remapping or mis-management of disk caches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
