[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system

2013-02-21 Thread Bin Chen (JIRA) 

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

Bin Chen updated TS-1405:
-

Attachment: TS-1405.patch

1. reconstruct event cancel handler

 apply time-wheel scheduler  about event system
 --

 Key: TS-1405
 URL: https://issues.apache.org/jira/browse/TS-1405
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
 Fix For: 3.3.1

 Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, 
 linux_time_wheel_v3.patch, time_wheel_v4.patch, TS-1405.patch


 when have more and more event in event system scheduler, it's worse. This is 
 the reason why we use inactivecop to handler keepalive. the new scheduler is 
 time-wheel. It's have better time complexity(O(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] [Commented] (TS-1700) disable static libraries by default

2013-02-21 Thread JIRA 

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

Igor Galić commented on TS-1700:


I keep forgetting that we still support 32bit systems… Under Solaris we don't 
compile with -m32..

 disable static libraries by default
 ---

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


 Disable building static libraries by default. There's no upside to having 
 static libraries and some potential to improve binary compatibility by 
 removing them.

--
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-1486) drop solaris studio support

2013-02-21 Thread JIRA 

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

Igor Galić commented on TS-1486:


Perhaps I should be documenting here which changes it took..

[098b2f27081104da0c4e30a64e59c51fbe0bddfe|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=098b2f27081104da0c4e30a64e59c51fbe0bddfe]

 drop solaris studio support
 ---

 Key: TS-1486
 URL: https://issues.apache.org/jira/browse/TS-1486
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Portability
Reporter: James Peach
Assignee: Igor Galić
 Fix For: 3.3.3


 We should drop Solaris Studio support for the 3.4 release.

--
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-1674) TSStatIntDecrement is broken

2013-02-21 Thread Uri Shachar (JIRA) 

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

Uri Shachar commented on TS-1674:
-

James -- You'd win your bet.
I did the legwork on this and got the following results:
1) Switching to using global atomic variables *improves* performance by ~0.5% 
in ATS without plugins
2) In ATS with a simple plugin that does 20 increments/decrements of stat 
variables in 4 different hookpoints (80 calls total per transaction) I see a 
~0.9% performance *degradation*.
-- Once there are a lot of counters the memory barriers/collisions start to 
take a heavy toll

I'll attach a patch for posterity, but considering these results I wouldn't 
recommend integrating it :-)


 TSStatIntDecrement is broken
 

 Key: TS-1674
 URL: https://issues.apache.org/jira/browse/TS-1674
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Reporter: Brian Geffon
Assignee: Brian Geffon
 Fix For: 3.3.1


 ATS keeps a thread-local copy of the stat value and aggregates it 
 periodically and on demand when stats are being collected. However the 
 decrement function doesn't let a value go negative. So in a thread that has 
 not incremented this stat previously, the decrement call fails. This 
 negative value check is logically flawed as it doesn't account for the 
 per-thread distribution of the stats.

--
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-1674) TSStatIntDecrement is broken

2013-02-21 Thread Uri Shachar (JIRA) 

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

Uri Shachar updated TS-1674:


Attachment: remove_per_thread_stats.patch

Adding a patch that removes per-thread stats (it isn't very clean)

 TSStatIntDecrement is broken
 

 Key: TS-1674
 URL: https://issues.apache.org/jira/browse/TS-1674
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Reporter: Brian Geffon
Assignee: Brian Geffon
 Fix For: 3.3.1

 Attachments: remove_per_thread_stats.patch


 ATS keeps a thread-local copy of the stat value and aggregates it 
 periodically and on demand when stats are being collected. However the 
 decrement function doesn't let a value go negative. So in a thread that has 
 not incremented this stat previously, the decrement call fails. This 
 negative value check is logically flawed as it doesn't account for the 
 per-thread distribution of the stats.

--
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-1718) iconv incorrectly recognized on Solaris

2013-02-21 Thread JIRA 
Igor Galić created TS-1718:
--

 Summary: iconv incorrectly recognized on Solaris
 Key: TS-1718
 URL: https://issues.apache.org/jira/browse/TS-1718
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: Igor Galić


A solaris system can have multiple installations of iconv (the most obvious 
being that of its {{libc}}).

However, once {{configure}} has successfully identified an iconv, we don't 
really do anything with that information. Instead we try to replicate it 
(poorly) in our code.

Here's an example from {{ink_string.cc}}:

{code}
#if !defined(kfreebsd)  (defined(freebsd) || (!defined(__GNUC__)  
defined(solaris)))
  if (iconv(ic, in, inbytesleft, out, outbytesleft) == (size_t) - 1)
#else
  if (iconv(ic, (char **) in, inbytesleft, out, outbytesleft) == (size_t) - 
1)
#endif
{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-1715) Possibly range related crashing since upgrading to 3.2.4

2013-02-21 Thread David Carlin (JIRA) 

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

David Carlin updated TS-1715:
-

Description: 
This might be related to TS-1574

I upgraded one box to 3.2.4, and and I am experiencing the following crash 
approximately twice a day:

Backtraces - the first happens more frequently:

#0  RangeTransform::transform_to_range (this=0x2b40e40973d0) at Transform.cc:843
#1  0x004e52e8 in RangeTransform::handle_event (this=0x2b40e40973d0, 
event=value optimized out, edata=value optimized out) at Transform.cc:816
#2  0x006970f4 in handleEvent (this=0x2b40b9762010, e=0x2b40dc47f9e0, 
calling_code=1) at I_Continuation.h:146
#3  EThread::process_event (this=0x2b40b9762010, e=0x2b40dc47f9e0, 
calling_code=1) at UnixEThread.cc:142
#4  0x00697b6b in EThread::execute (this=0x2b40b9762010) at 
UnixEThread.cc:191
#5  0x006960c2 in spawn_thread_internal (a=0x15e04a0) at Thread.cc:88
#6  0x0031f8c07851 in start_thread () from /lib64/libpthread.so.0
#7  0x0031f88e76dd in clone () from /lib64/libc.so.6

#0  RangeTransform::transform_to_range (this=0x2b11441773f0) at Transform.cc:843
#1  0x004e52e8 in RangeTransform::handle_event (this=0x2b11441773f0, 
event=value optimized out, edata=value optimized out) at Transform.cc:816
#2  0x006970f4 in handleEvent (this=0x2b109f266010, e=0x2b110006f360, 
calling_code=1) at I_Continuation.h:146
#3  EThread::process_event (this=0x2b109f266010, e=0x2b110006f360, 
calling_code=1) at UnixEThread.cc:142
#4  0x00697b6b in EThread::execute (this=0x2b109f266010) at 
UnixEThread.cc:191
#5  0x004c28c9 in main (argc=value optimized out, argv=value 
optimized out) at Main.cc:1822

From /var/log/messages:

Feb 16 11:43:26 l4 kernel: [ET_NET 18][16876]: segfault at 155 ip
00567571 sp 2b04d1412b40 error 4 in
traffic_server[40+341000]

From traffic.out:

/home/y/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0[0x31f8c0f500]
/home/y/bin/traffic_server(_ZN14RangeTransform18transform_to_rangeEv+0x83)[0x4e4b63]
/home/y/bin/traffic_server(_ZN14RangeTransform12handle_eventEiPv+0x158)[0x4e52e8]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6970f4]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x5ab)[0x697b6b]
/home/y/bin/traffic_server[0x6960c2]
/lib64/libpthread.so.0[0x31f8c07851]
/lib64/libc.so.6(clone+0x6d)[0x31f88e76dd]


  was:
This might be related to TS-1574

I upgraded one box to 3.2.4, and and I am experiencing the following crash 
approximately twice a day:

Backtraces - the first happens more frequently:

#0  RangeTransform::transform_to_range (this=0x2b40e40973d0) at Transform.cc:843
#1  0x004e52e8 in RangeTransform::handle_event (this=0x2b40e40973d0, 
event=value optimized out, edata=value optimized out) at Transform.cc:816
#2  0x006970f4 in handleEvent (this=0x2b40b9762010, e=0x2b40dc47f9e0, 
calling_code=1) at I_Continuation.h:146
#3  EThread::process_event (this=0x2b40b9762010, e=0x2b40dc47f9e0, 
calling_code=1) at UnixEThread.cc:142
#4  0x00697b6b in EThread::execute (this=0x2b40b9762010) at 
UnixEThread.cc:191
#5  0x006960c2 in spawn_thread_internal (a=0x15e04a0) at Thread.cc:88
#6  0x0031f8c07851 in start_thread () from /lib64/libpthread.so.0
#7  0x0031f88e76dd in clone () from /lib64/libc.so.6

#0  RangeTransform::transform_to_range (this=0x2b11441773f0) at Transform.cc:843
#1  0x004e52e8 in RangeTransform::handle_event (this=0x2b11441773f0, 
event=value optimized out, edata=value optimized out) at Transform.cc:816
#2  0x006970f4 in handleEvent (this=0x2b109f266010, e=0x2b110006f360, 
calling_code=1) at I_Continuation.h:146
#3  EThread::process_event (this=0x2b109f266010, e=0x2b110006f360, 
calling_code=1) at UnixEThread.cc:142
#4  0x00697b6b in EThread::execute (this=0x2b109f266010) at 
UnixEThread.cc:191
#5  0x004c28c9 in main (argc=value optimized out, argv=value 
optimized out) at Main.cc:1822

From /var/log/messages:

Feb 16 11:43:26 l4 kernel: [ET_NET 18][16876]: segfault at 155 ip
00567571 sp 2b04d1412b40 error 4 in
traffic_server[40+341000]

From traffic.out:

NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x31f8c0f500]
/home/y/bin/traffic_server(_ZN10HttpTunnel15chain_abort_allEP18HttpTunnelPr
oducer+0xe1)[0x567571]
/home/y/bin/traffic_server(_ZN6HttpSM17tunnel_handler_uaEiP18HttpTunnelCons
umer+0x354)[0x5205b4]
/home/y/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnel
Consumer+0x96)[0x56b716]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56bf6
d]
/home/y/bin/traffic_server(_ZN6HttpSM28state_watch_for_client_abortEiPv+0x2
aa)[0x523d2a]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x52b2f8]
/home/y/bin/traffic_server[0x672b5b]

[jira] [Commented] (TS-1717) static library build fails with duplicate symbols

2013-02-21 Thread JIRA 

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

Igor Galić commented on TS-1717:


Are you gonna, or should someone else pick it up?

 static library build fails with duplicate symbols
 -

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

 fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static 
  make -j  sudo make install
 ...
   CXXLDtraffic_manager
   AR   libmgmt_p.a
 duplicate symbol _diags in:
 Main.o
 ../lib/ts/.libs/libtsutil.a(Diags.o)
 ld: 1 duplicate symbol for architecture x86_64
 example/app-template/app-template.cc://Diags *diags = NULL;
 iocore/aio/test_AIO.i:Diags *diags;
 iocore/cluster/test_I_Cluster.cc:Diags *diags;
 iocore/cluster/test_P_Cluster.cc:Diags *diags;
 iocore/dns/test_I_DNS.cc:Diags *diags;
 iocore/dns/test_P_DNS.cc:Diags *diags;
 iocore/eventsystem/test_Buffer.cc:Diags *diags;
 iocore/eventsystem/test_Event.i:Diags *diags;
 iocore/hostdb/test_I_HostDB.cc:Diags *diags;
 iocore/hostdb/test_P_HostDB.cc:Diags *diags;
 iocore/net/test_I_Net.cc:Diags *diags;
 iocore/net/test_I_UDPNet.cc:Diags *diags;
 iocore/net/test_P_Net.cc:Diags *diags;
 iocore/net/test_P_UDPNet.cc:Diags *diags;
 iocore/utils/diags.i://Diags *diags;
 lib/records/I_RecCore.h:int RecSetDiags(Diags * diags);
 lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL);
 lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * 
 diags = NULL);
 lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags);
 lib/records/RecCore.cc:Diags *g_diags = NULL;
 lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags)
 lib/records/RecCore.cc:RecSetDiags(Diags * _diags)
 lib/records/RecLocal.cc:RecLocalInit(Diags * _diags)
 lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags)
 lib/records/RecUtils.cc:extern Diags *g_diags;
 lib/records/test_I_RecLocal.cc:Diags *diags = NULL;
 lib/records/test_RecProcess.i:Diags *diags = NULL;
 lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL;
 lib/ts/Diags.h:extern inkcoreapi Diags *diags;
 mgmt/Main.cc:inkcoreapi Diags *diags;
 proxy/DiagsConfig.h:  Diags *diags;
 proxy/Initialize.h:extern Diags *diags;
 proxy/Main.cc://inkcoreapi Diags *diags = NULL;
 proxy/hdrs/load_http_hdr.cc://Diags *diags;
 proxy/logging/LogStandalone.cc:Diags *diags = NULL;
 Additionally, AFAICT diags.i is not used and can be removed.

--
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-1674) TSStatIntDecrement is broken

2013-02-21 Thread James Peach (JIRA) 

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

James Peach commented on TS-1674:
-

Thanks Uri!

 TSStatIntDecrement is broken
 

 Key: TS-1674
 URL: https://issues.apache.org/jira/browse/TS-1674
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Reporter: Brian Geffon
Assignee: Brian Geffon
 Fix For: 3.3.1

 Attachments: remove_per_thread_stats.patch


 ATS keeps a thread-local copy of the stat value and aggregates it 
 periodically and on demand when stats are being collected. However the 
 decrement function doesn't let a value go negative. So in a thread that has 
 not incremented this stat previously, the decrement call fails. This 
 negative value check is logically flawed as it doesn't account for the 
 per-thread distribution of the stats.

--
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-1718) iconv incorrectly recognized on Solaris

2013-02-21 Thread JIRA 

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

Igor Galić commented on TS-1718:


Generally, yeah: But autoconf already knows that, our code doesn't.



-- 
Sent from my phone. Please excuse my brevity.


 iconv incorrectly recognized on Solaris
 ---

 Key: TS-1718
 URL: https://issues.apache.org/jira/browse/TS-1718
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: Igor Galić

 A solaris system can have multiple installations of iconv (the most obvious 
 being that of its {{libc}}).
 However, once {{configure}} has successfully identified an iconv, we don't 
 really do anything with that information. Instead we try to replicate it 
 (poorly) in our code.
 Here's an example from {{ink_string.cc}}:
 {code}
 #if !defined(kfreebsd)  (defined(freebsd) || (!defined(__GNUC__)  
 defined(solaris)))
   if (iconv(ic, in, inbytesleft, out, outbytesleft) == (size_t) - 1)
 #else
   if (iconv(ic, (char **) in, inbytesleft, out, outbytesleft) == (size_t) 
 - 1)
 #endif
 {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-1640) SSL certificate reconfiguration only works once

2013-02-21 Thread jaekyung oh (JIRA) 

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

jaekyung oh commented on TS-1640:
-

Hi James Peach.

can i get patch or diff? i'm using 3.2.4 on OpenSuse. op team can't reload the 
new ssl config by traffic_line -x.

 SSL certificate reconfiguration only works once
 ---

 Key: TS-1640
 URL: https://issues.apache.org/jira/browse/TS-1640
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Management, SSL
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.3.1


 Using traffic_line -x to update the SSL certificate configuration only works 
 the first time. This indicates a problem with the ConfigUpdateHandler 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