You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Miles Libbey (JIRA)" <ji...@apache.org> on 2010/04/19 23:02:50 UTC

[jira] Commented: (TS-32) Fix ICP

    [ https://issues.apache.org/jira/browse/TS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858681#action_12858681 ] 

Miles Libbey commented on TS-32:
--------------------------------

(was yahoo bug 1999704 and 3140708)

-----Original Message-----
From: Ethan Lai 
Sent: Friday, June 13, 2008 4:41 AM
Subject: [Cannot enable ICP on YTS 1.17.x

Hi TS,

We're trying to build a TS cluster serving for same small contents.
While running TS 1.16.[2|4], it works fine if we set icp.enabled INT 2 
and have some icp Sibling in icp.config.
But it core dumps while starting up TS 1.17.[0|7] with same 
configuration files.

Here is some info:
    icp.config:

    p1.cover.wretch.tp2.yahoo.net::2:80:3130:0:0.0.0.0:1:
    p2.cover.wretch.tp2.yahoo.net::2:80:3130:0:0.0.0.0:1:

    traffic.out:

    [Jun 13 19:14:59.569] {4157241024} STATUS: opened
    /home/y/logs/yts/diags.log
    Inside Connection::bind_connect in UnixNet.cc
    Inside Connection::bind_connect in UnixNet.cc
    NOTE: Traffic Server received Sig 11: Segmentation fault
    bin/traffic_server STACK TRACE:
    0xFFFFE500::__kernel_sigreturn
    0x08326B5B:bin/traffic_server:_ZN15UDPNetProcessor11recvfrom_reEP12ContinuationPviP8sockaddrPiP13IOBufferBlockibi
    0xA53F8000:[0xa53f8000]
    0x080E3C4C:bin/traffic_server:_ZN15ICPPeerReadCont16ICPPeerReadEventEiP5Event
    0x080E44E5:bin/traffic_server:_ZN14ICPHandlerCont13PeriodicEventEiP5Event
    0x08338CB2:bin/traffic_server:_ZN7EThread13process_eventEP5Eventi
    0x0833954E:bin/traffic_server:_ZN7EThread7executeEv
    0x08137903:bin/traffic_server:main
    0x006B5DE3:/lib/tls/libc.so.6:__libc_start_main
    0x080D4B61:bin/traffic_server:__gxx_personality_v0
    0x080D4B61:bin/traffic_server:__gxx_personality_v0
    0x080D4B61:bin/traffic_server:__gxx_personality_v0
    0x080D4B61:bin/traffic_server:__gxx_personality_v0

    gdb output:

    #0  0x08326b5b in UDPNetProcessor::recvfrom_re (this=0x853d488,
    cont=0x9dbb07c8, token=0x9dbb07c8, fd=31,
        fromaddr=0xa5cb0cb4, fromaddrlen=0xa5cb0cc4, buf=0x9dbb8ff8,
    len=16347, useReadCont=true, timeout=0)
        at ../../../iocore/net/P_UnixPollDescriptor.h:28
    #1  0x080e8906 in ParentSiblingPeer::RecvFrom_re (this=0xbf04f030,
    cont=0x9dbb07c8, token=0x9dbb07c8, bufblock=0x9dbb8ff8,
        size=16347, from=0xa5cb0cb4, fromlen=0xa5cb0cc4) at
    ../../proxy/ICPConfig.cc:938
    #2  0x080e207b in ICPPeerReadCont::PeerReadStateMachine
    (this=0x9dbb07c8, s=0x9dbb7f20, e=0x0)
        at ../../libinktomi++/Ptr.h:213
    #3  0x080e3c4c in ICPPeerReadCont::ICPPeerReadEvent
    (this=0x9dbb07c8, event=2, e=0x0) at ../../proxy/ICP.cc:361
    #4  0x080e44e5 in ICPHandlerCont::PeriodicEvent (this=0xa5cb0f48,
    event=2, e=0x8612fd0)
        at ../../iocore/eventsystem/I_Continuation.h:103
    #5  0x08338cb2 in EThread::process_event (this=0xbf04d008,
    e=0x8612fd0, calling_code=2)
        at ../../../iocore/eventsystem/I_Continuation.h:103
    #6  0x0833954e in EThread::execute (this=0xbf04d008) at
    ../../../iocore/eventsystem/UnixEThread.cc:188
    #7  0x08137903 in main (argc=3, argv=0xffffd614) at
    ../../iocore/eventsystem/P_Thread.h:21


Do you team have any ideas?

Please advise and many thanks,
Ethan




Original description
by Ravi Teja  5 months ago at 2009-10-26 05:49

When I enable ICP in  trafficserver-1.17.2, TS is dumping core and not starting at all. But, when I try with same
configuration in version  trafficserver-1.16.2, TS starts without any problems.


----icp configuration----
yqlyts1.pipes.mud.yahoo.com:209.191.71.34:2:80:3130:0:0.0.0.0:1:
yqlyts2.pipes.mud.yahoo.com:209.191.71.35:2:80:3130:0:0.0.0.0:1:


----logs ----

[Oct 26 04:50:26.669] Manager {4157041024} ERROR: [LocalManager::pollMgmtProcessServer] Server Process
 terminated due to Sig 11: Segmentation fault
[Oct 26 04:50:26.669] Manager {4157041024} ERROR:  (last system error 9: Bad file descriptor)
[Oct 26 04:50:26.669] Manager {4157041024} ERROR: [Alarms::signalAlarm] Server Process was reset
[Oct 26 04:50:26.670] Manager {4157041024} ERROR:  (last system error 9: Bad file descriptor)

[example_alarm_bin.sh] sent alarm: yqlyts2.pipes.mud.yahoo.com [TrafficManager] Traffic Server process
 was reset.

[example_prep.sh] Checking/Moving old cores...
[Oct 26 04:50:29.322] {4150838976} STATUS: opened /home/y/logs/yts/diags.log
NOTE: Traffic Server received Sig 11: Segmentation fault
bin/traffic_server STACK TRACE: 
0xFFFFE500::__kernel_sigreturn
0x08339F6B:bin/traffic_server:_ZN15UDPNetProcessor11recvfrom_reEP12ContinuationPviP8sockaddrPiP13IOBuf
ferBlockibi
0x00004000:[0x4000]
0x080E5FDC:bin/traffic_server:_ZN15ICPPeerReadCont16ICPPeerReadEventEiP5Event
0x080E6875:bin/traffic_server:_ZN14ICPHandlerCont13PeriodicEventEiP5Event
0x0834CBE2:bin/traffic_server:_ZN7EThread13process_eventEP5Eventi
0x0834D47E:bin/traffic_server:_ZN7EThread7executeEv
0x0834A65C:bin/traffic_server:(null)
0xF7F373CC:/lib/tls/libpthread.so.0:(null)
0x00B15F0E:/lib/tls/libc.so.6:__clone
0x00B15F0E:/lib/tls/libc.so.6:__clone
0x00B15F0E:/lib/tls/libc.so.6:__clone
0x00B15F0E:/lib/tls/libc.so.6:__clone

		
 
Comment 1
 by Bryan Call  5 months ago at 2009-10-26 08:42:10

Yes, this is a know issue in the 1.17.x branch.  ICP hasn't been  
working since we reworked how we handle socket connections.

-Bryan

> Fix ICP
> -------
>
>                 Key: TS-32
>                 URL: https://issues.apache.org/jira/browse/TS-32
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Core
>            Reporter: Miles Libbey
>
> http://icp.ircache.net/
> The ICP implementation in Traffic Server broke when epoll() was introduced.  Its still an interesting and used feature in caches:
> - when a caching layer of several boxes are used ICP helps to reduce disparities when a client is not routed to the same cache on subsequent requests
> - after a restart, it can help reduce the time spent in a cold cache situation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.