[jira] [Commented] (TS-1423) Blind tunneling of garbage/invalid requests when using transparent interception

2012-12-11 Thread Uri Shachar (JIRA) 

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

Uri Shachar commented on TS-1423:
-

Alan - Any issues with this patch? The extra ntohs in HttpTransact should be 
removed in any case I'll submit another ticket just for that if needed.

 Blind tunneling of garbage/invalid requests when using transparent 
 interception
 ---

 Key: TS-1423
 URL: https://issues.apache.org/jira/browse/TS-1423
 Project: Traffic Server
  Issue Type: New Feature
Affects Versions: 3.2.0
 Environment: 3.2 with TProxy inteception and 
 proxy.config.http.use_client_target_addr == 1
Reporter: B Wyatt
Assignee: Alan M. Carroll
 Fix For: 3.3.3

 Attachments: transparent_passthrough.diff


 Presently, when ATS encounters a request that it cannot parse or that is 
 malformed in any way, it sends an error response to the client.
 When using transparent interception and 
 proxy.config.http.use_client_target_addr ATS should have enough information 
 to blindly tunnel the original transmission to the desired endpoint and 
 maintain the service regardless of HTTP/1.x compliance and moreover if it is 
 non-HTTP communication over port 80. 
 Bonus would be support for supporting alien protocols where the server speaks 
 first however, ambiguity over a slow incoming request and an expectation that 
 the server speaks first can make that difficult.

--
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-1555) Lua Plugin doesn't work

2012-12-11 Thread Luca Rea (JIRA) 

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

Luca Rea commented on TS-1555:
--


Of course...

Example n.1:

Plugin.config:

{noformat}

# Comments start with a '#' and continue to the end of the line
# Blank lines are ignored
#
# test-plugin.so arg1 arg2 arg3
#
# Example:
#inktomi/iwx/iwx.so
#inktomi/abuse/abuse.so etc/trafficserver/abuse.config
#inktomi/icx/icx.so etc/trafficserver/icx.config
#/usr/local/libexec/trafficserver/lua.so 
/usr/local/libexec/trafficserver/hooks.lua
lua.so /usr/local/libexec/trafficserver/hooks.lua

{noformat}

Result:

{noformat}

[TrafficServer] using root directory '/usr/local'
[Dec 11 10:46:38.187] Server {0x7fe8e7d56840} DIAG: (lua) LuaApiInit: 
initializing TS API
[Dec 11 10:46:38.187] Server {0x7fe8e7d56840} DIAG: (lua) LuaHookApiInit: 
initializing TS Hook API
[Dec 11 10:46:38.187] Server {0x7fe8e7d56840} DIAG: (hooks) loaded 
@/usr/local/libexec/trafficserver/hooks.lua
[Dec 11 10:46:38.187] Server {0x7fe8e7d56840} DIAG: (lua) 
TSLuaHttpHookRegister: [1]=number [2]=function
[Dec 11 10:46:38.187] Server {0x7fe8e7d56840} DIAG: (lua) 
TSLuaHttpHookRegister: registering hook HTTP_SSN_START_HOOK (11)
[Dec 11 10:46:38.187] Server {0x7fe8e7d56840} DIAG: (lua) 
TSLuaHttpHookRegister: installed continuation for HTTP_SSN_START_HOOK
[Dec 11 10:46:38.187] Server {0x7fe8e7d56840} DIAG: (lua) 
TSLuaHttpHookRegister: [1]=number [2]=function
[Dec 11 10:46:38.188] Server {0x7fe8e7d56840} DIAG: (lua) 
TSLuaHttpHookRegister: registering hook HTTP_TXN_START_HOOK (9)
[Dec 11 10:46:38.188] Server {0x7fe8e7d56840} DIAG: (lua) 
TSLuaHttpHookRegister: installed continuation for HTTP_TXN_START_HOOK
^CNOTE: Traffic Server received Sig 2: Interrupt
[root@w0w trafficserver]#

{noformat}






Example n.2:

Plugin.config:

{noformat}

# Comments start with a '#' and continue to the end of the line
# Blank lines are ignored
#
# test-plugin.so arg1 arg2 arg3
#
# Example:
#inktomi/iwx/iwx.so
#inktomi/abuse/abuse.so etc/trafficserver/abuse.config
#inktomi/icx/icx.so etc/trafficserver/icx.config
/usr/local/libexec/trafficserver/lua.so 
/usr/local/libexec/trafficserver/hooks.lua
#lua.so /usr/local/libexec/trafficserver/hooks.lua

{noformat}

Result:

{noformat}

[root@w0w trafficserver]# /usr/local/bin/traffic_server 
[TrafficServer] using root directory '/usr/local'
^CNOTE: Traffic Server received Sig 2: Interrupt
[root@w0w trafficserver]# 

{noformat}


In the second example the Lua plugin seems not working correctly.

 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
 Fix For: 3.3.3


 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] [Commented] (TS-1616) authorization proxy plugin

2012-12-11 Thread Luca Rea (JIRA) 

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

Luca Rea commented on TS-1616:
--

Thank you!! I'll test it as soon as possible

 authorization proxy plugin
 --

 Key: TS-1616
 URL: https://issues.apache.org/jira/browse/TS-1616
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.3.1


 An authorization proxy plugin that delegates the authorization decision to an 
 external web service.

--
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-1006) memory management, cut down memory waste ?

2012-12-11 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom commented on TS-1006:
---

I haven't had a chance to review the patch (yet), but a few comments / concerns:

1) I understand you want to reclaim the memory, to use it for another (non-ATS) 
process. I guess that's reasonable, but bear in mind that bad things can happen 
here. Such as, if you need 10G RAM to handle certain load, reclaim 4G of it to 
use for some other process, if you now see that same load again, you might not 
be able to allocate that full 10G again (at least not without going on swap).

2) I also see / hear about problems where the claim is that we sort of leak, or 
don't use, the freelist as efficiently as possible. If that's the case, this 
patch seems like a bandaid (or duct tape) solution. I'm not opposing it per se, 
but doing this sort of garbage collection could then hide real, serious 
problems that we should otherwise fix.

3) This becomes more difficult to configure. How do I know what to set the max 
memory to? How do I avoid the case where it constantly garbage collects off the 
freelist, just to cause it to malloc() new objects, and then garbage collect 
again? Such cycles could completely kill performance.


At a minimum, I'd encourage that we make this behavior optional, and disabled 
by default. I'd be interested to hear from the Taoabao team and John about 
these concerns as well.

Thanks!

-- Leif


 memory management, cut down memory waste ?
 --

 Key: TS-1006
 URL: https://issues.apache.org/jira/browse/TS-1006
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
 Fix For: 3.3.2

 Attachments: 0001-Allocator-optimize-InkFreeList-memory-pool.patch, 
 0002-Allocator-make-InkFreeList-memory-pool-configurable.patch, 
 Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods


 when we review the memory usage in the production, there is something 
 abnormal, ie, looks like TS take much memory than index data + common system 
 waste, and here is some memory dump result by set 
 proxy.config.dump_mem_info_frequency
 1, the one on a not so busy forwarding system:
 physics memory: 32G
 RAM cache: 22G
 DISK: 6140 GB
 average_object_size 64000
 {code}
  allocated  |in-use  | type size  |   free list name
 |||--
   671088640 |   37748736 |2097152 | 
 memory/ioBufAllocator[14]
  2248146944 | 2135949312 |1048576 | 
 memory/ioBufAllocator[13]
  1711276032 | 1705508864 | 524288 | 
 memory/ioBufAllocator[12]
  1669332992 | 1667760128 | 262144 | 
 memory/ioBufAllocator[11]
  2214592512 | 221184 | 131072 | 
 memory/ioBufAllocator[10]
  2325741568 | 2323775488 |  65536 | 
 memory/ioBufAllocator[9]
  2091909120 | 2089123840 |  32768 | 
 memory/ioBufAllocator[8]
  1956642816 | 1956478976 |  16384 | 
 memory/ioBufAllocator[7]
  2094530560 | 2094071808 |   8192 | 
 memory/ioBufAllocator[6]
   356515840 |  355540992 |   4096 | 
 memory/ioBufAllocator[5]
 1048576 |  14336 |   2048 | 
 memory/ioBufAllocator[4]
  131072 |  0 |   1024 | 
 memory/ioBufAllocator[3]
   65536 |  0 |512 | 
 memory/ioBufAllocator[2]
   32768 |  0 |256 | 
 memory/ioBufAllocator[1]
   16384 |  0 |128 | 
 memory/ioBufAllocator[0]
   0 |  0 |576 | 
 memory/ICPRequestCont_allocator
   0 |  0 |112 | 
 memory/ICPPeerReadContAllocator
   0 |  0 |432 | 
 memory/PeerReadDataAllocator
   0 |  0 | 32 | 
 memory/MIMEFieldSDKHandle
   0 |  0 |240 | 
 memory/INKVConnAllocator
   0 |  0 | 96 | 
 memory/INKContAllocator
4096 |  0 | 32 | 
 memory/apiHookAllocator
   0 |  0 |288 | 
 memory/FetchSMAllocator
   0 |  0 | 80 | 
 memory/prefetchLockHandlerAllocator
   0 |  0 |176 | 
 memory/PrefetchBlasterAllocator
   0 |  0 | 80 | 
 memory/prefetchUrlBlaster

[jira] [Commented] (TS-1006) memory management, cut down memory waste ?

2012-12-11 Thread John Plevyak (JIRA) 

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

John Plevyak commented on TS-1006:
--

I agree.  We should land this initially as a compile time option in the dev
branch to get wider production time on it before moving it to default.

The main reason is that it is invasive and complicated, particularly in the
way it will interact with the VM system and it would be nice to see how it
responds in a variety of environments.

If it is much better than TCMalloc, then perhaps we should package it up in
a more general form as well.

Was the design based on another allocator/paper?  Any references?

john




 memory management, cut down memory waste ?
 --

 Key: TS-1006
 URL: https://issues.apache.org/jira/browse/TS-1006
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
 Fix For: 3.3.2

 Attachments: 0001-Allocator-optimize-InkFreeList-memory-pool.patch, 
 0002-Allocator-make-InkFreeList-memory-pool-configurable.patch, 
 Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods


 when we review the memory usage in the production, there is something 
 abnormal, ie, looks like TS take much memory than index data + common system 
 waste, and here is some memory dump result by set 
 proxy.config.dump_mem_info_frequency
 1, the one on a not so busy forwarding system:
 physics memory: 32G
 RAM cache: 22G
 DISK: 6140 GB
 average_object_size 64000
 {code}
  allocated  |in-use  | type size  |   free list name
 |||--
   671088640 |   37748736 |2097152 | 
 memory/ioBufAllocator[14]
  2248146944 | 2135949312 |1048576 | 
 memory/ioBufAllocator[13]
  1711276032 | 1705508864 | 524288 | 
 memory/ioBufAllocator[12]
  1669332992 | 1667760128 | 262144 | 
 memory/ioBufAllocator[11]
  2214592512 | 221184 | 131072 | 
 memory/ioBufAllocator[10]
  2325741568 | 2323775488 |  65536 | 
 memory/ioBufAllocator[9]
  2091909120 | 2089123840 |  32768 | 
 memory/ioBufAllocator[8]
  1956642816 | 1956478976 |  16384 | 
 memory/ioBufAllocator[7]
  2094530560 | 2094071808 |   8192 | 
 memory/ioBufAllocator[6]
   356515840 |  355540992 |   4096 | 
 memory/ioBufAllocator[5]
 1048576 |  14336 |   2048 | 
 memory/ioBufAllocator[4]
  131072 |  0 |   1024 | 
 memory/ioBufAllocator[3]
   65536 |  0 |512 | 
 memory/ioBufAllocator[2]
   32768 |  0 |256 | 
 memory/ioBufAllocator[1]
   16384 |  0 |128 | 
 memory/ioBufAllocator[0]
   0 |  0 |576 | 
 memory/ICPRequestCont_allocator
   0 |  0 |112 | 
 memory/ICPPeerReadContAllocator
   0 |  0 |432 | 
 memory/PeerReadDataAllocator
   0 |  0 | 32 | 
 memory/MIMEFieldSDKHandle
   0 |  0 |240 | 
 memory/INKVConnAllocator
   0 |  0 | 96 | 
 memory/INKContAllocator
4096 |  0 | 32 | 
 memory/apiHookAllocator
   0 |  0 |288 | 
 memory/FetchSMAllocator
   0 |  0 | 80 | 
 memory/prefetchLockHandlerAllocator
   0 |  0 |176 | 
 memory/PrefetchBlasterAllocator
   0 |  0 | 80 | 
 memory/prefetchUrlBlaster
   0 |  0 | 96 | memory/blasterUrlList
   0 |  0 | 96 | 
 memory/prefetchUrlEntryAllocator
   0 |  0 |128 | 
 memory/socksProxyAllocator
   0 |  0 |144 | 
 memory/ObjectReloadCont
 3258368 | 576016 |592 | 
 memory/httpClientSessionAllocator
  825344 | 139568 |208 | 
 memory/httpServerSessionAllocator
22597632 |1284848 |   9808 | memory/httpSMAllocator
   0 |  0 | 32 | 
 memory/CacheLookupHttpConfigAllocator
   0 |  0 |   9856 | 
 memory/httpUpdateSMAllocator
   0 |

Re: [jira] [Commented] (TS-1006) memory management, cut down memory waste ?

2012-12-11 Thread Yunkai Zhang 
On Wed, Dec 12, 2012 at 12:09 AM, Leif Hedstrom (JIRA) j...@apache.orgwrote:


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

 Leif Hedstrom commented on TS-1006:
 ---

 I haven't had a chance to review the patch (yet), but a few comments /
 concerns:

 1) I understand you want to reclaim the memory, to use it for another
 (non-ATS) process. I guess that's reasonable, but bear in mind that bad
 things can happen here. Such as, if you need 10G RAM to handle certain
 load, reclaim 4G of it to use for some other process, if you now see that
 same load again, you might not be able to allocate that full 10G again (at
 least not without going on swap).


The main propose of this patch is to fasten total memory size, so that we
can prevent TS running into swap which will lead to OOM.

I can disable reclaiming when the total memory size less than *max_mem* by
default (In fact, we can control the reclaiming speed by setting
*reclaim_factor* and *max_overage* variables).



 2) I also see / hear about problems where the claim is that we sort of
 leak, or don't use, the freelist as efficiently as possible. If that's the
 case, this patch seems like a bandaid (or duct tape) solution. I'm not
 opposing it per se, but doing this sort of garbage collection could then
 hide real, serious problems that we should otherwise fix.


I agree with you that we need to fix the real problems.

But there is a serious problem about original InkFreeList -- the original
InkFreeList can't reclaim itself, so some free memory used by one kind of
idle Class/RAM-cache can't reused by another kind of busy Class/RAM-cahe.



 3) This becomes more difficult to configure. How do I know what to set the
 max memory to? How do I avoid the case where it constantly garbage collects
 off the freelist, just to cause it to malloc() new objects, and then
 garbage collect again? Such cycles could completely kill performance.


Right, I have observed that when TS exceed the max_mem, it will kill some
performance(CPU will become more busy).

But it should only kill the performance of requests which lead to memory
beyond max_mem. The other request should no be affected.




 At a minimum, I'd encourage that we make this behavior optional, and
 disabled by default. I'd be interested to hear from the Taoabao team and
 John about these concerns as well.



I can make it not reclaiming by default:)



 Thanks!

 -- Leif


  memory management, cut down memory waste ?
  --
 
  Key: TS-1006
  URL: https://issues.apache.org/jira/browse/TS-1006
  Project: Traffic Server
   Issue Type: Improvement
   Components: Core
 Affects Versions: 3.1.1
 Reporter: Zhao Yongming
 Assignee: Bin Chen
  Fix For: 3.3.2
 
  Attachments:
 0001-Allocator-optimize-InkFreeList-memory-pool.patch,
 0002-Allocator-make-InkFreeList-memory-pool-configurable.patch,
 Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
 
 
  when we review the memory usage in the production, there is something
 abnormal, ie, looks like TS take much memory than index data + common
 system waste, and here is some memory dump result by set
 proxy.config.dump_mem_info_frequency
  1, the one on a not so busy forwarding system:
  physics memory: 32G
  RAM cache: 22G
  DISK: 6140 GB
  average_object_size 64000
  {code}
   allocated  |in-use  | type size  |   free list name
 
 |||--
671088640 |   37748736 |2097152 |
 memory/ioBufAllocator[14]
   2248146944 | 2135949312 |1048576 |
 memory/ioBufAllocator[13]
   1711276032 | 1705508864 | 524288 |
 memory/ioBufAllocator[12]
   1669332992 | 1667760128 | 262144 |
 memory/ioBufAllocator[11]
   2214592512 | 221184 | 131072 |
 memory/ioBufAllocator[10]
   2325741568 | 2323775488 |  65536 |
 memory/ioBufAllocator[9]
   2091909120 | 2089123840 |  32768 |
 memory/ioBufAllocator[8]
   1956642816 | 1956478976 |  16384 |
 memory/ioBufAllocator[7]
   2094530560 | 2094071808 |   8192 |
 memory/ioBufAllocator[6]
356515840 |  355540992 |   4096 |
 memory/ioBufAllocator[5]
  1048576 |  14336 |   2048 |
 memory/ioBufAllocator[4]
   131072 |  0 |   1024 |
 memory/ioBufAllocator[3]
65536 |  0 |512 |
 memory/ioBufAllocator[2]
32768 |  0 |256 |
 memory/ioBufAllocator[1]
16384 |  0 |128 |

Re: [jira] [Commented] (TS-1006) memory management, cut down memory waste ?

2012-12-11 Thread Yunkai Zhang 
On Wed, Dec 12, 2012 at 12:53 AM, John Plevyak (JIRA) j...@apache.orgwrote:


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

 John Plevyak commented on TS-1006:
 --

 I agree.  We should land this initially as a compile time option in the dev
 branch to get wider production time on it before moving it to default.

 The main reason is that it is invasive and complicated, particularly in the
 way it will interact with the VM system and it would be nice to see how it
 responds in a variety of environments.

 If it is much better than TCMalloc, then perhaps we should package it up in
 a more general form as well.

 Was the design based on another allocator/paper?  Any references?


The code and design is simple, not so profound:)



 john




  memory management, cut down memory waste ?
  --
 
  Key: TS-1006
  URL: https://issues.apache.org/jira/browse/TS-1006
  Project: Traffic Server
   Issue Type: Improvement
   Components: Core
 Affects Versions: 3.1.1
 Reporter: Zhao Yongming
 Assignee: Bin Chen
  Fix For: 3.3.2
 
  Attachments:
 0001-Allocator-optimize-InkFreeList-memory-pool.patch,
 0002-Allocator-make-InkFreeList-memory-pool-configurable.patch,
 Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
 
 
  when we review the memory usage in the production, there is something
 abnormal, ie, looks like TS take much memory than index data + common
 system waste, and here is some memory dump result by set
 proxy.config.dump_mem_info_frequency
  1, the one on a not so busy forwarding system:
  physics memory: 32G
  RAM cache: 22G
  DISK: 6140 GB
  average_object_size 64000
  {code}
   allocated  |in-use  | type size  |   free list name
 
 |||--
671088640 |   37748736 |2097152 |
 memory/ioBufAllocator[14]
   2248146944 | 2135949312 |1048576 |
 memory/ioBufAllocator[13]
   1711276032 | 1705508864 | 524288 |
 memory/ioBufAllocator[12]
   1669332992 | 1667760128 | 262144 |
 memory/ioBufAllocator[11]
   2214592512 | 221184 | 131072 |
 memory/ioBufAllocator[10]
   2325741568 | 2323775488 |  65536 |
 memory/ioBufAllocator[9]
   2091909120 | 2089123840 |  32768 |
 memory/ioBufAllocator[8]
   1956642816 | 1956478976 |  16384 |
 memory/ioBufAllocator[7]
   2094530560 | 2094071808 |   8192 |
 memory/ioBufAllocator[6]
356515840 |  355540992 |   4096 |
 memory/ioBufAllocator[5]
  1048576 |  14336 |   2048 |
 memory/ioBufAllocator[4]
   131072 |  0 |   1024 |
 memory/ioBufAllocator[3]
65536 |  0 |512 |
 memory/ioBufAllocator[2]
32768 |  0 |256 |
 memory/ioBufAllocator[1]
16384 |  0 |128 |
 memory/ioBufAllocator[0]
0 |  0 |576 |
 memory/ICPRequestCont_allocator
0 |  0 |112 |
 memory/ICPPeerReadContAllocator
0 |  0 |432 |
 memory/PeerReadDataAllocator
0 |  0 | 32 |
 memory/MIMEFieldSDKHandle
0 |  0 |240 |
 memory/INKVConnAllocator
0 |  0 | 96 |
 memory/INKContAllocator
 4096 |  0 | 32 |
 memory/apiHookAllocator
0 |  0 |288 |
 memory/FetchSMAllocator
0 |  0 | 80 |
 memory/prefetchLockHandlerAllocator
0 |  0 |176 |
 memory/PrefetchBlasterAllocator
0 |  0 | 80 |
 memory/prefetchUrlBlaster
0 |  0 | 96 |
 memory/blasterUrlList
0 |  0 | 96 |
 memory/prefetchUrlEntryAllocator
0 |  0 |128 |
 memory/socksProxyAllocator
0 |  0 |144 |
 memory/ObjectReloadCont
  3258368 | 576016 |592 |
 memory/httpClientSessionAllocator
   825344 | 139568 |208 |
 memory/httpServerSessionAllocator
 22597632 |1284848 |   9808 |
 memory/httpSMAllocator
0 |  0 | 32 |

[jira] [Created] (TS-1618) crash with 3.2.3

2012-12-11 Thread Jan-Frode Myklebust (JIRA) 
Jan-Frode Myklebust created TS-1618:
---

 Summary: crash with 3.2.3
 Key: TS-1618
 URL: https://issues.apache.org/jira/browse/TS-1618
 Project: Traffic Server
  Issue Type: Bug
Reporter: Jan-Frode Myklebust


We're seeing crashes with 3.2.3 on RHEL6...

NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(_ZN7CacheVC16is_pread_capableEv+0x7)[0x628db7]
/usr/bin/traffic_server(_ZN6HttpSM27do_range_setup_if_necessaryEv+0x1d0)[0x523270]
/usr/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0x242)[0x552672]
/usr/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x4e1)[0x553711]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x62)[0x51af92]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0xfe)[0x5291be]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x52b558]
/usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1a2)[0x50a912]
/usr/bin/traffic_server(_ZN7CacheVC8callcontEi+0x27)[0x64af07]
/usr/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x7e2)[0x646b42]
/usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x383)[0x647843]
/usr/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x158)[0x624dd8]
/usr/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x84)[0x50a364]
/usr/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x51c263]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6d1)[0x533a31]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7c4)[0x533b24]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x6b7)[0x52d527]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x52b558]
/usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6724a7]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x666bc2]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66da12]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6966e4]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: 
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:  (last system error 104: 
Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: 
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:  (last system error 32: 
Broken pipe)

Please let me know if there's anything else I can provide to debug this.

--
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-1618) crash with 3.2.3

2012-12-11 Thread JIRA 

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

Igor Galić updated TS-1618:
---

Description: 
We're seeing crashes with 3.2.3 on RHEL6...

NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
 HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_cache_open_read(int, 
void*)+0xfe)[0x5291be]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, 
void*)+0x1a2)[0x50a912]
/usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
/usr/bin/traffic_server(CacheVC::openReadStartHead(int, Event*)+0x7e2)[0x646b42]
/usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*, 
CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
/usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, 
HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
/usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, 
CacheLookupHttpConfig*, long)+0x84)[0x50a364]
/usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_read_client_request_header(int, 
void*)+0x6b7)[0x52d527]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
/usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*, 
EThread*)+0x832)[0x666bc2]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: 
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:  (last system error 104: 
Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: 
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:  (last system error 32: 
Broken pipe)

Please let me know if there's anything else I can provide to debug this.


  was:
We're seeing crashes with 3.2.3 on RHEL6...

NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(_ZN7CacheVC16is_pread_capableEv+0x7)[0x628db7]
/usr/bin/traffic_server(_ZN6HttpSM27do_range_setup_if_necessaryEv+0x1d0)[0x523270]
/usr/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0x242)[0x552672]
/usr/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x4e1)[0x553711]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x62)[0x51af92]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]

[jira] [Updated] (TS-1618) crash with 3.2.3

2012-12-11 Thread JIRA 

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

Igor Galić updated TS-1618:
---

Description: 
We're seeing crashes with 3.2.3 on RHEL6...

{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
 HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_cache_open_read(int, 
void*)+0xfe)[0x5291be]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, 
void*)+0x1a2)[0x50a912]
/usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
/usr/bin/traffic_server(CacheVC::openReadStartHead(int, Event*)+0x7e2)[0x646b42]
/usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*, 
CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
/usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, 
HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
/usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, 
CacheLookupHttpConfig*, long)+0x84)[0x50a364]
/usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_read_client_request_header(int, 
void*)+0x6b7)[0x52d527]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
/usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*, 
EThread*)+0x832)[0x666bc2]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: 
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:  (last system error 104: 
Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: 
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:  (last system error 32: 
Broken pipe)
{noformat}

Please let me know if there's anything else I can provide to debug this.


  was:
We're seeing crashes with 3.2.3 on RHEL6...

NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
 HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]

[jira] [Commented] (TS-1618) crash with 3.2.3

2012-12-11 Thread Jan-Frode Myklebust (JIRA) 

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

Jan-Frode Myklebust commented on TS-1618:
-

RHEL6, x86_64, using IPv4 and IPv6, using multiple wildcard SSL certificates, 
running on RHEV virtual machines, no clustering (do IP address failover outside 
of ATS), running as reverse proxy.

 crash with 3.2.3
 

 Key: TS-1618
 URL: https://issues.apache.org/jira/browse/TS-1618
 Project: Traffic Server
  Issue Type: Bug
Reporter: Jan-Frode Myklebust

 We're seeing crashes with 3.2.3 on RHEL6...
 {noformat}
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
 /usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
 /usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
 /usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
  HTTPWarningCode)+0x242)[0x552672]
 /usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
 /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
 (*)(HttpTransact::State*))+0x62)[0x51af92]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::state_cache_open_read(int, 
 void*)+0xfe)[0x5291be]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
 /usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, 
 void*)+0x1a2)[0x50a912]
 /usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
 /usr/bin/traffic_server(CacheVC::openReadStartHead(int, 
 Event*)+0x7e2)[0x646b42]
 /usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*, 
 CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
 /usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, 
 HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
 /usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, 
 CacheLookupHttpConfig*, long)+0x84)[0x50a364]
 /usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::state_read_client_request_header(int, 
 void*)+0x6b7)[0x52d527]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
 /usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
 /usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*, 
 EThread*)+0x832)[0x666bc2]
 /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
 /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
 /usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
 /usr/bin/traffic_server[0x6956b2]
 /lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
 /lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:  (last system error 
 104: Connection reset by peer)
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
 [LocalManager::mgmtShutdown] Executing shutdown request.
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
 [LocalManager::processShutdown] Executing process shutdown request.
 [Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 [Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:  (last system error 32: 
 Broken pipe)
 {noformat}
 Please let me know if there's anything else I can provide to debug this.

--
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-1618) crash with 3.2.3

2012-12-11 Thread Jan-Frode Myklebust (JIRA) 

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

Jan-Frode Myklebust commented on TS-1618:
-

The ATS version is trafficserver-3.2.3.tar.bz2 
(313b7c6e8303bb21e93a9c3e0c33d170) as announced in:

http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3c1949983350.127675.1350122656277.javamail.r...@brainsware.org%3e

Plus the patch for TS-1526.

 crash with 3.2.3
 

 Key: TS-1618
 URL: https://issues.apache.org/jira/browse/TS-1618
 Project: Traffic Server
  Issue Type: Bug
Reporter: Jan-Frode Myklebust

 We're seeing crashes with 3.2.3 on RHEL6...
 {noformat}
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
 /usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
 /usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
 /usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
  HTTPWarningCode)+0x242)[0x552672]
 /usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
 /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
 (*)(HttpTransact::State*))+0x62)[0x51af92]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::state_cache_open_read(int, 
 void*)+0xfe)[0x5291be]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
 /usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, 
 void*)+0x1a2)[0x50a912]
 /usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
 /usr/bin/traffic_server(CacheVC::openReadStartHead(int, 
 Event*)+0x7e2)[0x646b42]
 /usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*, 
 CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
 /usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, 
 HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
 /usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, 
 CacheLookupHttpConfig*, long)+0x84)[0x50a364]
 /usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::state_read_client_request_header(int, 
 void*)+0x6b7)[0x52d527]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
 /usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
 /usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*, 
 EThread*)+0x832)[0x666bc2]
 /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
 /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
 /usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
 /usr/bin/traffic_server[0x6956b2]
 /lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
 /lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:  (last system error 
 104: Connection reset by peer)
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
 [LocalManager::mgmtShutdown] Executing shutdown request.
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
 [LocalManager::processShutdown] Executing process shutdown request.
 [Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 [Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:  (last system error 32: 
 Broken pipe)
 {noformat}
 Please let me know if there's anything else I can provide to debug this.

--
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-1618) crash with 3.2.3

2012-12-11 Thread Jan-Frode Myklebust (JIRA) 

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

Jan-Frode Myklebust updated TS-1618:


Affects Version/s: 3.2.3

 crash with 3.2.3
 

 Key: TS-1618
 URL: https://issues.apache.org/jira/browse/TS-1618
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Jan-Frode Myklebust

 We're seeing crashes with 3.2.3 on RHEL6...
 {noformat}
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
 /usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
 /usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
 /usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
  HTTPWarningCode)+0x242)[0x552672]
 /usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
 /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
 (*)(HttpTransact::State*))+0x62)[0x51af92]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::state_cache_open_read(int, 
 void*)+0xfe)[0x5291be]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
 /usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, 
 void*)+0x1a2)[0x50a912]
 /usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
 /usr/bin/traffic_server(CacheVC::openReadStartHead(int, 
 Event*)+0x7e2)[0x646b42]
 /usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*, 
 CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
 /usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, 
 HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
 /usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, 
 CacheLookupHttpConfig*, long)+0x84)[0x50a364]
 /usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
 /usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
 /usr/bin/traffic_server(HttpSM::state_read_client_request_header(int, 
 void*)+0x6b7)[0x52d527]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
 /usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
 /usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*, 
 EThread*)+0x832)[0x666bc2]
 /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
 /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
 /usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
 /usr/bin/traffic_server[0x6956b2]
 /lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
 /lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:  (last system error 
 104: Connection reset by peer)
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
 [LocalManager::mgmtShutdown] Executing shutdown request.
 [Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE: 
 [LocalManager::processShutdown] Executing process shutdown request.
 [Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 [Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:  (last system error 32: 
 Broken pipe)
 {noformat}
 Please let me know if there's anything else I can provide to debug this.

--
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-1619) simplify ConfigurationProcessor reconfiguration pattern

2012-12-11 Thread James Peach (JIRA) 
James Peach created TS-1619:
---

 Summary: simplify ConfigurationProcessor reconfiguration pattern
 Key: TS-1619
 URL: https://issues.apache.org/jira/browse/TS-1619
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration
Reporter: James Peach


Add some helper code to establish and simplify the online reconfiguration 
pattern using the ConfigurationProcessor.

--
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-1619) simplify ConfigurationProcessor reconfiguration pattern

2012-12-11 Thread James Peach (JIRA) 

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

James Peach resolved TS-1619.
-

   Resolution: Fixed
Fix Version/s: 3.3.1
 Assignee: James Peach

7e1169c1fa97c9ba336f7ba501192ac074525643 TS-1619: update CHANGES
54a4d3297a823ae73c8898af0f223cb398f05d80 TS-1619: Simplify the config update 
patter with ConfigUpdateHandler
3578517ade2500682b892c0fd2703f242a91dc4b TS-1619: Use ConfigScheduleUpdate in 
SSL certificate update
336db463a6415585b6a29132da6d7a84d3b5d0fb TS-1619: Use ConfigurationProcessor 
for ParentSelection configuration update
7d2524ea1b5865e8005e138fa16e9d12df23ff87 TS-1619: Add ConfigUpdateContinuation 
and ConfigScheduleUpdate helpers


 simplify ConfigurationProcessor reconfiguration pattern
 ---

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


 Add some helper code to establish and simplify the online reconfiguration 
 pattern using the ConfigurationProcessor.

--
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