[jira] [Created] (TS-4523) The ability to pause/resume data consumption in the Transformation Plugin.

[David Ben Zakai (JIRA)]

David Ben Zakai created TS-4523:
---

 Summary: The ability to pause/resume data consumption in the 
Transformation Plugin.
 Key: TS-4523
 URL: https://issues.apache.org/jira/browse/TS-4523
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: David Ben Zakai


It would be nice to be able to pause/resume the data consumption in the 
Transformation Plugin.

Use case:
Manipulating the data in chunks (without reading all of it - waste of memory)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4523) Add the ability to pause/resume data consumption in the cpp api.

[Uri Shachar (JIRA)]

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

Uri Shachar reassigned TS-4523:
---

Assignee: Uri Shachar

> Add the ability to pause/resume data consumption in the cpp api.
> 
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> Use case:
> Manipulating the data in chunks (without reading all of it - waste of memory)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4523) Add the ability to pause/resume data consumption in the cpp api.

[Uri Shachar (JIRA)]

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

Uri Shachar reassigned TS-4523:
---

Assignee: Uri Shachar

> Add the ability to pause/resume data consumption in the cpp api.
> 
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> Use case:
> Manipulating the data in chunks (without reading all of it - waste of memory)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the cpp api.

[Uri Shachar (JIRA)]

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

Uri Shachar updated TS-4523:

Assignee: (was: Uri Shachar)

> Add the ability to pause/resume data consumption in the cpp api.
> 
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> Use case:
> Manipulating the data in chunks (without reading all of it - waste of memory)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the cpp api.

[David Ben Zakai (JIRA)]

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

David Ben Zakai updated TS-4523:

Summary: Add the ability to pause/resume data consumption in the cpp api.  
(was: The ability to pause/resume data consumption in the Transformation 
Plugin.)

> Add the ability to pause/resume data consumption in the cpp api.
> 
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> Use case:
> Manipulating the data in chunks (without reading all of it - waste of memory)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[Uri Shachar (JIRA)]

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

Uri Shachar updated TS-4523:

Fix Version/s: 7.0.0

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> Use case:
> Manipulating the data in chunks (without reading all of it - waste of memory)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[Uri Shachar (JIRA)]

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

Uri Shachar updated TS-4523:

Summary: Add the ability to pause/resume data consumption in the CPP API  
(was: Add the ability to pause/resume data consumption in the cpp api.)

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> Use case:
> Manipulating the data in chunks (without reading all of it - waste of memory)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[David Ben Zakai (JIRA)]

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

David Ben Zakai updated TS-4523:

Description: 
It would be nice to be able to pause/resume the data consumption in the 
Transformation Plugin.

My Own Use case:
I'm writing the data into a file, when it reaches a certain size I'd like to 
produce the file output for the downstream, while doing so I'd like to avoid 
reading more data from the upstream.
So the flow would be:
consume -> write into a file x N times
file reaches X KB ? -> pause upstream socket, produce data from file and then 
resume

  was:
It would be nice to be able to pause/resume the data consumption in the 
Transformation Plugin.

Use case:
Manipulating the data in chunks (without reading all of it - waste of memory)


> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> My Own Use case:
> I'm writing the data into a file, when it reaches a certain size I'd like to 
> produce the file output for the downstream, while doing so I'd like to avoid 
> reading more data from the upstream.
> So the flow would be:
> consume -> write into a file x N times
> file reaches X KB ? -> pause upstream socket, produce data from file and then 
> resume



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[David Ben Zakai (JIRA)]

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

David Ben Zakai updated TS-4523:

Description: 
It would be nice to be able to pause/resume the data consumption in the 
Transformation Plugin.

My Own Use case:
I'm writing the data into a file, when it reaches a certain size I'd like to 
produce the file output for the downstream, while doing so I'd like to avoid 
reading more data from the upstream.
So the flow would be:
consume -> write into a file (K times)
file reaches X KB ?
  pause upstream socket
  produce data from file
  resume

  was:
It would be nice to be able to pause/resume the data consumption in the 
Transformation Plugin.

My Own Use case:
I'm writing the data into a file, when it reaches a certain size I'd like to 
produce the file output for the downstream, while doing so I'd like to avoid 
reading more data from the upstream.
So the flow would be:
consume -> write into a file x N times
file reaches X KB ? -> pause upstream socket, produce data from file and then 
resume


> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> It would be nice to be able to pause/resume the data consumption in the 
> Transformation Plugin.
> My Own Use case:
> I'm writing the data into a file, when it reaches a certain size I'd like to 
> produce the file output for the downstream, while doing so I'd like to avoid 
> reading more data from the upstream.
> So the flow would be:
> consume -> write into a file (K times)
> file reaches X KB ?
>   pause upstream socket
>   produce data from file
>   resume



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4517) Build tests in the same build phase all over components

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4517:


Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/702
  
:+1:


> Build tests in the same build phase all over components
> ---
>
> Key: TS-4517
> URL: https://issues.apache.org/jira/browse/TS-4517
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> Currently, tests for H2 are built during normal build phase but others are 
> not built until you run "make check".
> There may be reasons on both cases, but it should be consistent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4517) Build tests in the same build phase all over components

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-4517:
-

Commit a826e1b49a449bb7810dd9fc3e835bb12e9e70c8 in trafficserver's branch 
refs/heads/master from [~maskit]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a826e1b ]

TS-4517: Build tests during "make check" phase (#702)



> Build tests in the same build phase all over components
> ---
>
> Key: TS-4517
> URL: https://issues.apache.org/jira/browse/TS-4517
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> Currently, tests for H2 are built during normal build phase but others are 
> not built until you run "make check".
> There may be reasons on both cases, but it should be consistent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4517) Build tests in the same build phase all over components

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4517:


Github user maskit closed the pull request at:

https://github.com/apache/trafficserver/pull/702


> Build tests in the same build phase all over components
> ---
>
> Key: TS-4517
> URL: https://issues.apache.org/jira/browse/TS-4517
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> Currently, tests for H2 are built during normal build phase but others are 
> not built until you run "make check".
> There may be reasons on both cases, but it should be consistent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4521) compile error on build proxy/http2/test_HPACK

[Masakazu Kitajo (JIRA)]

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

Masakazu Kitajo commented on TS-4521:
-

Good. Could you create a Pull Request for this? Thanks.

> compile error on build proxy/http2/test_HPACK
> -
>
> Key: TS-4521
> URL: https://issues.apache.org/jira/browse/TS-4521
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Oknet Xu
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> OS: Debian 7 (wheezy)
> ATS Branch: master
> GCC: 4.7.2(Debian 4.7.2-5)
> {code}
> /usr/bin/ld: ../../proxy/hdrs/libhdrs.a(HttpCompat.o): undefined reference to 
> symbol 'Tcl_NextHashEntry'
> /usr/bin/ld: note: 'Tcl_NextHashEntry' is defined in DSO 
> /usr/lib/libtcl8.5.so.0 so try adding it to the linker command line
> /usr/lib/libtcl8.5.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4524) add unique session ID

[James Peach (JIRA)]

James Peach created TS-4524:
---

 Summary: add unique session ID
 Key: TS-4524
 URL: https://issues.apache.org/jira/browse/TS-4524
 Project: Traffic Server
  Issue Type: New Feature
  Components: Core
Reporter: James Peach


Since transactions have a unique ID for tracking, {{TSHttpTxnIdGet()}}, it 
would be convenient to have the same facility for sessions. We should also use 
this in session-based logs for each protocol.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4525) Change sm_id to be uint64_t

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4525:
-

 Summary: Change sm_id to be uint64_t
 Key: TS-4525
 URL: https://issues.apache.org/jira/browse/TS-4525
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: Leif Hedstrom


In the HttpSM, we have an int64_t sm_id which is sequence number, starting at 
0. We should change this to uint64_t.

I'd recommend waiting with this change until we've landed all the work around 
improving the UUID and SM debug information, as proposed by Acacio.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: freebsd_10-master » clang,freebsd_10,release #979

[jenkins]

See 


--
[...truncated 6723 lines...]
*** TEST 103 *** STARTING ***
*** TEST 103 *** PASSED ***
*** TEST 104 *** STARTING ***
*** TEST 104 *** PASSED ***
*** TEST 105 *** STARTING ***
*** TEST 105 *** PASSED ***
*** TEST 106 *** STARTING ***
*** TEST 106 *** PASSED ***
*** TEST 107 *** STARTING ***
*** TEST 107 *** PASSED ***
*** TEST 108 *** STARTING ***
*** TEST 108 *** PASSED ***
*** TEST 109 *** STARTING ***
*** TEST 109 *** PASSED ***
*** TEST 110 *** STARTING ***
*** TEST 110 *** PASSED ***
*** TEST 111 *** STARTING ***
*** TEST 111 *** PASSED ***
*** TEST 112 *** STARTING ***
*** TEST 112 ***[SDK_API_TSTextLog] TSTextLogObjectDestroy : [TestCase1] 
<> { ok }
[SDK_API_TSTextLog] TSTextLogObject : [TestCase1] <> { ok }
[SDK_API_TSThread] TSThreadCreate : [TestCase2] <> { ok }
REGRESSION_RESULT PARENTSELECTION:  PASSED
REGRESSION TEST PVC started
[SDK_API_TSActionCancel] TSActionCancel : [TestCase1] <> { ok }
[SDK_API_TSContSchedule] TSContSchedule : [TestCase2] <> { ok }
RPRINT DNS: host www.apple.com [e6858.dscc.akamaiedge.net] = 184.30.12.155
RPRINT DNS: host www.ibm.com [e2874.x.akamaiedge.net] = 23.48.102.137
RPRINT DNS: host www.microsoft.com [e2847.dspb.akamaiedge.net] = 23.48.109.197
RPRINT DNS: host www.coke.com [a1128.g2.akamai.net] = 204.2.193.144
REGRESSION_RESULT SDK_API_TSTextLog:PASSED
REGRESSION_RESULT SDK_API_TSContSchedule:   PASSED
REGRESSION_RESULT SDK_API_TSContDataGet:PASSED
REGRESSION_RESULT SDK_API_TSActionCancel:   PASSED
REGRESSION_RESULT SDK_API_TSThreadInit: PASSED
REGRESSION_RESULT SDK_API_TSThread: PASSED
REGRESSION_RESULT SDK_API_TSCache:  PASSED
REGRESSION_RESULT SDK_API_TSPortDescriptor: PASSED
REGRESSION_RESULT SDK_API_TSNetVConn:   PASSED
REGRESSION_RESULT DNS:  PASSED
 PASSED ***
*** TEST 113 *** STARTING ***
*** TEST 113 *** PASSED ***
*** TEST 114 *** STARTING ***
*** TEST 114 *** PASSED ***
*** TEST 115 *** STARTING ***
*** TEST 115 *** PASSED ***
*** TEST 116 *** STARTING ***
*** TEST 116 *** PASSED ***
*** TEST 117 *** STARTING ***
*** TEST 117 *** PASSED ***
*** TEST 118 *** STARTING ***
*** TEST 118 *** PASSED ***
*** TEST 119 *** STARTING ***
*** TEST 119 *** PASSED ***
*** TEST 120 *** STARTING ***
*** TEST 120 *** PASSED ***
*** TEST 121 *** STARTING ***
*** TEST 121 *** PASSED ***
*** TEST 122 *** STARTING ***
*** TEST 122 *** PASSED ***
*** TEST 123 *** STARTING ***
*** TEST 123 *** PASSED ***
*** TEST 124 *** STARTING ***
*** TEST 124 *** PASSED ***
*** TEST 125 *** STARTING ***
*** TEST 125 *** PASSED ***
*** TEST 126 *** STARTING ***
*** TEST 126 *** PASSED ***
*** TEST 127 *** STARTING ***
*** TEST 127 *** PASSED ***
*** TEST 128 *** STARTING ***
*** TEST 128 *** PASSED ***
*** TEST 129 *** STARTING ***
*** TEST 129 *** PASSED ***
*** TEST 130 *** STARTING ***
*** TEST 130 *** PASSED ***
*** TEST 131 *** STARTING ***
*** TEST 131 *** PASSED ***
*** TEST 132 *** STARTING ***
*** TEST 132 *** PASSED ***
*** TEST 133 *** STARTING ***
*** TEST 133 *** PASSED ***
*** TEST 134 *** STARTING ***
*** TEST 134 *** PASSED ***
*** TEST 135 *** STARTING ***
*** TEST 135 *** PASSED ***
*** TEST 136 *** STARTING ***
*** TEST 136 *** PASSED ***
*** TEST 137 *** STARTING ***
*** TEST 137 *** PASSED ***
*** TEST 138 *** STARTING ***
*** TEST 138 *** PASSED ***
*** TEST 139 *** STARTING ***
*** TEST 139 *** PASSED ***
*** TEST 140 *** STARTING ***
*** TEST 140 *** PASSED ***
*** TEST 141 *** STARTING ***
*** TEST 141 *** PASSED ***
*** TEST 142 *** STARTING ***
*** TEST 142 *** PASSED ***
*** TEST 143 *** STARTING ***
*** TEST 143 *** PASSED ***
*** TEST 144 *** STARTING ***
*** TEST 144 *** PASSED ***
*** TEST 145 *** STARTING ***
*** TEST 145 *** PASSED ***
*** TEST 146 *** STARTING ***
*** TEST 146 *** PASSED ***
*** TEST 147 *** STARTING ***
*** TEST 147 *** PASSED ***
*** TEST 148 *** STARTING ***
*** TEST 148 *** PASSED ***
*** TEST 149 *** STARTING ***
*** TEST 149 *** PASSED ***
*** TEST 150 *** STARTING ***
*** TEST 150 *** PASSED ***
*** TEST 151 *** STARTING ***
*** TEST 151 *** PASSED ***
*** TEST 152 *** STARTING ***
*** TEST 152 *** PASSED ***
*** TEST 153 *** STARTING ***
*** TEST 153 *** PASSED ***
*** TEST 154 *** STARTING ***
*** TEST 154 *** PASSED ***
*** TEST 155 *** STARTING ***
*** TEST 155 *** PASSED ***
*** TEST 156 *** STARTING ***
*** TEST 156 *** PASSED ***
*** TEST 157 *** STARTING ***
*** TEST 157 *** PASSED ***
*** TEST 158 *** STARTING ***
*** TEST 158 *** PASSED ***
*** TEST 159 *** STARTING ***
*** TEST 159 *** PASSED ***
*** TEST 160 *** STARTING ***
*** TEST 160 *** PASSED ***
*** TEST 161 *** STARTING ***
**

[jira] [Created] (TS-4526) ASAN issue in 6.2.0 release

[Bryan Call (JIRA)]

Bryan Call created TS-4526:
--

 Summary: ASAN issue in 6.2.0 release 
 Key: TS-4526
 URL: https://issues.apache.org/jira/browse/TS-4526
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Bryan Call


{code}
ASAN:SIGSEGV
=
==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
#0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
#1 0xe9ee75 in ink_thread_create 
../../../trafficserver/lib/ts/ink_thread.h:147
#2 0xe9ee75 in Thread::start(char const*, unsigned long, void* (*)(void*), 
void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
#3 0xea8389 in EventProcessor::start(int, unsigned long) 
../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
#4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
#5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)

==11217==ABORTING
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4527) vc error messages in 6.2.0 release

[Bryan Call (JIRA)]

Bryan Call created TS-4527:
--

 Summary: vc error messages in 6.2.0 release
 Key: TS-4527
 URL: https://issues.apache.org/jira/browse/TS-4527
 Project: Traffic Server
  Issue Type: Bug
  Components: Network
Reporter: Bryan Call


Seeing this in the error logs *a lot*:
{code}
[Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR:  do_io_read invoked on closed vc 0x634000c186a0, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR:  do_io_write invoked on closed vc 0x634000c186a0, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR:  do_io_read invoked on closed vc 0x634000c0f220, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR:  do_io_write invoked on closed vc 0x634000c0f220, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR:  do_io_read invoked on closed vc 0x634000c13240, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR:  do_io_write invoked on closed vc 0x634000c13240, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR:  do_io_read invoked on closed vc 0x6340002364e0, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR:  do_io_write invoked on closed vc 0x6340002364e0, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR:  do_io_read invoked on closed vc 0x63400088c2e0, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR:  do_io_write invoked on closed vc 0x63400088c2e0, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR:  do_io_read invoked on closed vc 0x6340004f7fe0, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR:  do_io_write invoked on closed vc 0x6340004f7fe0, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR:  do_io_read invoked on closed vc 0x63400025a860, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR:  do_io_write invoked on closed vc 0x63400025a860, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR:  do_io_read invoked on closed vc 0x634000ad2820, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR:  do_io_write invoked on closed vc 0x634000ad2820, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR:  do_io_read invoked on closed vc 0x6340003fa1a0, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR:  do_io_write invoked on closed vc 0x6340003fa1a0, cont (nil), 
nbytes 0, reader (nil)
[Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR:  do_io_read invoked on closed vc 0x634000807f60, cont (nil), 
nbytes 0, buf (nil)
[Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR:  do_io_write invoked on closed vc 0x634000807f60, cont (nil), 
nbytes 0, reader (nil)
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4527) vc error messages in 6.2.0 release

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4527:
---
Affects Version/s: 6.2.0

> vc error messages in 6.2.0 release
> --
>
> Key: TS-4527
> URL: https://issues.apache.org/jira/browse/TS-4527
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4528) Active connections count is high in the 6.2.0 release

[Bryan Call (JIRA)]

Bryan Call created TS-4528:
--

 Summary: Active connections count is high in the 6.2.0 release
 Key: TS-4528
 URL: https://issues.apache.org/jira/browse/TS-4528
 Project: Traffic Server
  Issue Type: Bug
  Components: Network
Reporter: Bryan Call


There is either a problem with the number of active connections or the stat is 
off.  When running traffic_top:
{code}
Active Con   2.4K
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4527) vc error messages in 6.2.0 release

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4527:
---

This is definitely related to H2 in some way. I turned off H2 to debug another 
issue, and then these messages went away).

> vc error messages in 6.2.0 release
> --
>
> Key: TS-4527
> URL: https://issues.apache.org/jira/browse/TS-4527
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4522) did not check EPIPE on write_to_net_io

[James Peach (JIRA)]

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

James Peach commented on TS-4522:
-

Possibly related.

> did not check EPIPE on write_to_net_io
> --
>
> Key: TS-4522
> URL: https://issues.apache.org/jira/browse/TS-4522
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>
> On a closed socket fd:
> read(socketfd) return 0
> write(socketfd) return EPIPE
> In the write_to_net_io, we check the return value of write() with the same 
> way to read().
> {code}
> if (!r || r == -ECONNRESET) {
> {code}
> The bug makes no VC_EVENT_EOS callbacked while write_to_net_io, but 
> VC_EVENT_ERROR instead. 
> full code here:
> {code}
>   int64_t r = vc->load_buffer_and_write(towrite, buf, total_written, needs);
>   if (total_written > 0) {
> NET_SUM_DYN_STAT(net_write_bytes_stat, total_written);
> s->vio.ndone += total_written;
>   }
>   // check for errors
>   if (r <= 0) { // if the socket was not ready,add to WaitList
> if (r == -EAGAIN || r == -ENOTCONN) {
>   NET_INCREMENT_DYN_STAT(net_calls_to_write_nodata_stat);
>   if ((needs & EVENTIO_WRITE) == EVENTIO_WRITE) {
> vc->write.triggered = 0;
> nh->write_ready_list.remove(vc);
> write_reschedule(nh, vc);
>   }
>   if ((needs & EVENTIO_READ) == EVENTIO_READ) {
> vc->read.triggered = 0;
> nh->read_ready_list.remove(vc);
> read_reschedule(nh, vc);
>   }
>   return;
> }
> if (!r || r == -ECONNRESET) {
>   vc->write.triggered = 0;
>   write_signal_done(VC_EVENT_EOS, nh, vc);
>   return;
> }
> vc->write.triggered = 0;
> write_signal_error(nh, vc, (int)-total_written);
> return;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4526:
--
Summary: ASAN SEGV on unknown address (6.2.0)  (was: ASAN issue in 6.2.0 
release )

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4526:
--
Fix Version/s: 7.0.0

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4526:
--
Affects Version/s: 6.2.0

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4424) ASAN: heap-buffer-overflow in 6.2.x branch

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4424:
--
Affects Version/s: 6.2.0

> ASAN: heap-buffer-overflow in 6.2.x branch
> --
>
> Key: TS-4424
> URL: https://issues.apache.org/jira/browse/TS-4424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>  Labels: crash
> Fix For: 7.0.0
>
>
> From a few days ago:
> {code}
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> =
> ==17268==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x62a0064b5000 at pc 0x2b8fd0a73615 bp 0x7ffd34d416e0 sp 0x7ffd34d40e90
> READ of size 16384 at 0x62a0064b5000 thread T0 ([ET_NET 0])
> #0 0x2b8fd0a73614 in __asan_memcpy 
> ../../../../libsanitizer/asan/asan_interceptors.cc:367
> #1 0x2b8fd26f7b63 in ssl3_write_bytes 
> (/opt/openssl/lib/libssl.so.1.0.0+0x29b63)
> #2 0xbfe2e0 in SSLWriteBuffer(ssl_st*, void const*, long, long&) 
> /usr/local/src/trafficserver/iocore/net/SSLUtils.cc:2041
> #3 0xbd2a6a in SSLNetVConnection::load_buffer_and_write(long, long&, 
> long&, MIOBufferAccessor&, int&) 
> /usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:735
> #4 0xc48dad in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:511
> #5 0xc0a8ba in NetHandler::mainNetEvent(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNet.cc:529
> #6 0xcf6da3 in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #7 0xcf6da3 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:129
> #8 0xcf9d4a in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:256
> #9 0x498ad5 in main /usr/local/src/trafficserver/proxy/Main.cc:1909
> #10 0x2b8fd475bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #11 0x4a8244  (/opt/ats/bin/traffic_server+0x4a8244)
> 0x62a0064b5000 is located 0 bytes to the right of 16384-byte region 
> [0x62a0064b1000,0x62a0064b5000)
> allocated by thread T0 ([ET_NET 0]) here:
> #0 0x2b8fd0a7f9ae in __interceptor_posix_memalign 
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:105
> #1 0x2b8fd19b2ca9 in ats_memalign 
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:105
> #2 0x2b8fd19b3f3e in ink_freelist_new 
> /usr/local/src/trafficserver/lib/ts/ink_queue.cc:183
> #3 0x7d5670 in Allocator::alloc_void() ../../lib/ts/Allocator.h:63
> #4 0x7d5670 in IOBufferData::alloc(long, AllocType) 
> ../../iocore/eventsystem/P_IOBuffer.h:282
> #5 0x7d5670 in new_IOBufferData_internal(char const*, long, AllocType) 
> ../../iocore/eventsystem/P_IOBuffer.h:253
> #6 0x7d5670 in IOBufferBlock::alloc(long) 
> ../../iocore/eventsystem/P_IOBuffer.h:396
> #7 0x7d5670 in Http2Frame::alloc(int) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.h:96
> #8 0x7d5670 in Http2ConnectionState::send_data_frame(Http2Stream*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:959
> #9 0x7ea209 in Http2Stream::update_write_request(IOBufferReader*, long, 
> bool) /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:462
> #10 0x7efe96 in Http2Stream::reenable(VIO*) 
> /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:482
> #11 0x777c49 in VIO::reenable() ../../iocore/eventsystem/P_VIO.h:111
> #12 0x777c49 in HttpTunnel::producer_handler(int, HttpTunnelProducer*) 
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1199
> #13 0x77a0ee in HttpTunnel::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1568
> #14 0x9a2467 in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 0x9a2467 in CacheVC::calluser(int) 
> ../../iocore/cache/P_CacheInternal.h:623
> #16 0xb21d2c in CacheVC::openReadMain(int, Event*) 
> /usr/local/src/trafficserver/iocore/cache/CacheRead.cc:717
> #17 0x9a284c in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:153
> #18 0x9a284c in CacheVC::callcont(int) 
> ../../iocore/cache/P_CacheInternal.h:642
> #19 0xb30df9 in CacheVC::openReadStartHead(int, Event*) 
> /usr/local/src/trafficserver/iocore/cache/CacheRead.cc:1162
> #20 0xb29c07 in Continuation::handleEvent(int, void*) 
> ../../io

[jira] [Updated] (TS-4424) ASAN: heap-buffer-overflow (6.2.0)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4424:
--
Summary: ASAN: heap-buffer-overflow (6.2.0)  (was: ASAN: 
heap-buffer-overflow in 6.2.x branch)

> ASAN: heap-buffer-overflow (6.2.0)
> --
>
> Key: TS-4424
> URL: https://issues.apache.org/jira/browse/TS-4424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>  Labels: crash
> Fix For: 7.0.0
>
>
> From a few days ago:
> {code}
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> =
> ==17268==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x62a0064b5000 at pc 0x2b8fd0a73615 bp 0x7ffd34d416e0 sp 0x7ffd34d40e90
> READ of size 16384 at 0x62a0064b5000 thread T0 ([ET_NET 0])
> #0 0x2b8fd0a73614 in __asan_memcpy 
> ../../../../libsanitizer/asan/asan_interceptors.cc:367
> #1 0x2b8fd26f7b63 in ssl3_write_bytes 
> (/opt/openssl/lib/libssl.so.1.0.0+0x29b63)
> #2 0xbfe2e0 in SSLWriteBuffer(ssl_st*, void const*, long, long&) 
> /usr/local/src/trafficserver/iocore/net/SSLUtils.cc:2041
> #3 0xbd2a6a in SSLNetVConnection::load_buffer_and_write(long, long&, 
> long&, MIOBufferAccessor&, int&) 
> /usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:735
> #4 0xc48dad in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:511
> #5 0xc0a8ba in NetHandler::mainNetEvent(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNet.cc:529
> #6 0xcf6da3 in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #7 0xcf6da3 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:129
> #8 0xcf9d4a in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:256
> #9 0x498ad5 in main /usr/local/src/trafficserver/proxy/Main.cc:1909
> #10 0x2b8fd475bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #11 0x4a8244  (/opt/ats/bin/traffic_server+0x4a8244)
> 0x62a0064b5000 is located 0 bytes to the right of 16384-byte region 
> [0x62a0064b1000,0x62a0064b5000)
> allocated by thread T0 ([ET_NET 0]) here:
> #0 0x2b8fd0a7f9ae in __interceptor_posix_memalign 
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:105
> #1 0x2b8fd19b2ca9 in ats_memalign 
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:105
> #2 0x2b8fd19b3f3e in ink_freelist_new 
> /usr/local/src/trafficserver/lib/ts/ink_queue.cc:183
> #3 0x7d5670 in Allocator::alloc_void() ../../lib/ts/Allocator.h:63
> #4 0x7d5670 in IOBufferData::alloc(long, AllocType) 
> ../../iocore/eventsystem/P_IOBuffer.h:282
> #5 0x7d5670 in new_IOBufferData_internal(char const*, long, AllocType) 
> ../../iocore/eventsystem/P_IOBuffer.h:253
> #6 0x7d5670 in IOBufferBlock::alloc(long) 
> ../../iocore/eventsystem/P_IOBuffer.h:396
> #7 0x7d5670 in Http2Frame::alloc(int) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.h:96
> #8 0x7d5670 in Http2ConnectionState::send_data_frame(Http2Stream*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:959
> #9 0x7ea209 in Http2Stream::update_write_request(IOBufferReader*, long, 
> bool) /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:462
> #10 0x7efe96 in Http2Stream::reenable(VIO*) 
> /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:482
> #11 0x777c49 in VIO::reenable() ../../iocore/eventsystem/P_VIO.h:111
> #12 0x777c49 in HttpTunnel::producer_handler(int, HttpTunnelProducer*) 
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1199
> #13 0x77a0ee in HttpTunnel::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1568
> #14 0x9a2467 in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 0x9a2467 in CacheVC::calluser(int) 
> ../../iocore/cache/P_CacheInternal.h:623
> #16 0xb21d2c in CacheVC::openReadMain(int, Event*) 
> /usr/local/src/trafficserver/iocore/cache/CacheRead.cc:717
> #17 0x9a284c in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:153
> #18 0x9a284c in CacheVC::callcont(int) 
> ../../iocore/cache/P_CacheInternal.h:642
> #19 0xb30df9 in CacheVC::openReadStartHead(int, Event*) 
> /usr/local/src/trafficserver/iocore/cache/CacheRead.cc:1162
> #20 0xb29c

[jira] [Commented] (TS-4424) ASAN: heap-buffer-overflow (6.2.0)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4424:
---

I've spent some more time debugging this, and have found that this does not 
seem to happen when you disable H2. In addition, with [~shinrich] we found out 
that this *might* be related to 

{code}
proxy.config.ssl.max_record_size: -1
{code}

After confirming that this only happens with H2 enabled, I'll try with changing 
max_record_size to 0.

> ASAN: heap-buffer-overflow (6.2.0)
> --
>
> Key: TS-4424
> URL: https://issues.apache.org/jira/browse/TS-4424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>  Labels: crash
> Fix For: 7.0.0
>
>
> From a few days ago:
> {code}
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> =
> ==17268==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x62a0064b5000 at pc 0x2b8fd0a73615 bp 0x7ffd34d416e0 sp 0x7ffd34d40e90
> READ of size 16384 at 0x62a0064b5000 thread T0 ([ET_NET 0])
> #0 0x2b8fd0a73614 in __asan_memcpy 
> ../../../../libsanitizer/asan/asan_interceptors.cc:367
> #1 0x2b8fd26f7b63 in ssl3_write_bytes 
> (/opt/openssl/lib/libssl.so.1.0.0+0x29b63)
> #2 0xbfe2e0 in SSLWriteBuffer(ssl_st*, void const*, long, long&) 
> /usr/local/src/trafficserver/iocore/net/SSLUtils.cc:2041
> #3 0xbd2a6a in SSLNetVConnection::load_buffer_and_write(long, long&, 
> long&, MIOBufferAccessor&, int&) 
> /usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:735
> #4 0xc48dad in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:511
> #5 0xc0a8ba in NetHandler::mainNetEvent(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNet.cc:529
> #6 0xcf6da3 in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #7 0xcf6da3 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:129
> #8 0xcf9d4a in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:256
> #9 0x498ad5 in main /usr/local/src/trafficserver/proxy/Main.cc:1909
> #10 0x2b8fd475bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #11 0x4a8244  (/opt/ats/bin/traffic_server+0x4a8244)
> 0x62a0064b5000 is located 0 bytes to the right of 16384-byte region 
> [0x62a0064b1000,0x62a0064b5000)
> allocated by thread T0 ([ET_NET 0]) here:
> #0 0x2b8fd0a7f9ae in __interceptor_posix_memalign 
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:105
> #1 0x2b8fd19b2ca9 in ats_memalign 
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:105
> #2 0x2b8fd19b3f3e in ink_freelist_new 
> /usr/local/src/trafficserver/lib/ts/ink_queue.cc:183
> #3 0x7d5670 in Allocator::alloc_void() ../../lib/ts/Allocator.h:63
> #4 0x7d5670 in IOBufferData::alloc(long, AllocType) 
> ../../iocore/eventsystem/P_IOBuffer.h:282
> #5 0x7d5670 in new_IOBufferData_internal(char const*, long, AllocType) 
> ../../iocore/eventsystem/P_IOBuffer.h:253
> #6 0x7d5670 in IOBufferBlock::alloc(long) 
> ../../iocore/eventsystem/P_IOBuffer.h:396
> #7 0x7d5670 in Http2Frame::alloc(int) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.h:96
> #8 0x7d5670 in Http2ConnectionState::send_data_frame(Http2Stream*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:959
> #9 0x7ea209 in Http2Stream::update_write_request(IOBufferReader*, long, 
> bool) /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:462
> #10 0x7efe96 in Http2Stream::reenable(VIO*) 
> /usr/local/src/trafficserver/proxy/http2/Http2Stream.cc:482
> #11 0x777c49 in VIO::reenable() ../../iocore/eventsystem/P_VIO.h:111
> #12 0x777c49 in HttpTunnel::producer_handler(int, HttpTunnelProducer*) 
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1199
> #13 0x77a0ee in HttpTunnel::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http/HttpTunnel.cc:1568
> #14 0x9a2467 in Continuation::handleEvent(int, void*) 
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 0x9a2467 in CacheVC::calluser(int) 
> ../../iocore/cache/P_CacheInternal.h:623
> #16 0xb21d2c in CacheVC::openReadMain(int, Event*) 
> /usr/local/src/trafficserver/iocore/cache/CacheRead.cc:717
> #17 0x9a284c in Continuation:

[jira] [Created] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[David Calavera (JIRA)]

David Calavera created TS-4529:
--

 Summary: HttpSM doesn't assign the right continuation when 
adjusting threads
 Key: TS-4529
 URL: https://issues.apache.org/jira/browse/TS-4529
 Project: Traffic Server
  Issue Type: Bug
Reporter: David Calavera


We're still seeing some segfaults after testing [~shinrich]'s patch in 
https://github.com/apache/trafficserver/pull/688 more thoroughly.

I have a patch that seems to fix those remaining issues and I'll open a Pull 
Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4529:


GitHub user calavera opened a pull request:

https://github.com/apache/trafficserver/pull/703

[TS-4529] Adjust thread with the right continuation.

This patch seems to fix our issues with HttpAsync calls.

https://issues.apache.org/jira/browse/TS-4529

Signed-off-by: David Calavera 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/calavera/trafficserver 
fix_proxy_client_transaction_adjust_thread

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/703.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #703


commit 3480b3aa400bcd099029d538d1a6190d716f9306
Author: David Calavera 
Date:   2016-06-13T16:49:15Z

[TS-4529] Adjust thread with the right continuation.

Signed-off-by: David Calavera 




> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4522) did not check EPIPE on write_to_net_io

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4522:


Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/701
  
AFAICT we would get ``EPIPE`` when we write to a socket that has been 
closed. This would be an error because there is unwritten data that we can't 
write. We would get ``ECONNRESET`` reading from a socket that is closed. The 
other side closed the socket but we don't know whether that was premature or 
not (yet). Most places that I saw treated ``VC_EVENT_ERROR`` and 
``VC_EVENT_EOS`` similarly apart from logging.

By the same logic, I agree that handling ``ECONNRESET`` specially in 
``write_to_net_io`` looks odd and could be a bug. Maybe the right change is to 
remove the ``ECONNRESET`` check in ``write_to_net_io``. Also in this code path, 
the return from ``UnixNetVConnection::load_buffer_and_write`` should never be 0 
because we never try to write 0 bytes.

So consider:
```C
diff --git a/iocore/net/UnixNetVConnection.cc 
b/iocore/net/UnixNetVConnection.cc
index b52985c..bc9764d 100644
--- a/iocore/net/UnixNetVConnection.cc
+++ b/iocore/net/UnixNetVConnection.cc
@@ -535,11 +535,9 @@ write_to_net_io(NetHandler *nh, UnixNetVConnection 
*vc, EThread *thread)
   }
   return;
 }
-if (!r || r == -ECONNRESET) {
-  vc->write.triggered = 0;
-  write_signal_done(VC_EVENT_EOS, nh, vc);
-  return;
-}
+// A write of 0 makes no sense since we tried to write more than 0. 
Either
+// we wrote something or we got an error.
+ink_assert(r < 0);
 vc->write.triggered = 0;
 write_signal_error(nh, vc, (int)-total_written);
 return;
```




> did not check EPIPE on write_to_net_io
> --
>
> Key: TS-4522
> URL: https://issues.apache.org/jira/browse/TS-4522
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>
> On a closed socket fd:
> read(socketfd) return 0
> write(socketfd) return EPIPE
> In the write_to_net_io, we check the return value of write() with the same 
> way to read().
> {code}
> if (!r || r == -ECONNRESET) {
> {code}
> The bug makes no VC_EVENT_EOS callbacked while write_to_net_io, but 
> VC_EVENT_ERROR instead. 
> full code here:
> {code}
>   int64_t r = vc->load_buffer_and_write(towrite, buf, total_written, needs);
>   if (total_written > 0) {
> NET_SUM_DYN_STAT(net_write_bytes_stat, total_written);
> s->vio.ndone += total_written;
>   }
>   // check for errors
>   if (r <= 0) { // if the socket was not ready,add to WaitList
> if (r == -EAGAIN || r == -ENOTCONN) {
>   NET_INCREMENT_DYN_STAT(net_calls_to_write_nodata_stat);
>   if ((needs & EVENTIO_WRITE) == EVENTIO_WRITE) {
> vc->write.triggered = 0;
> nh->write_ready_list.remove(vc);
> write_reschedule(nh, vc);
>   }
>   if ((needs & EVENTIO_READ) == EVENTIO_READ) {
> vc->read.triggered = 0;
> nh->read_ready_list.remove(vc);
> read_reschedule(nh, vc);
>   }
>   return;
> }
> if (!r || r == -ECONNRESET) {
>   vc->write.triggered = 0;
>   write_signal_done(VC_EVENT_EOS, nh, vc);
>   return;
> }
> vc->write.triggered = 0;
> write_signal_error(nh, vc, (int)-total_written);
> return;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4530) enable proxy.config.hostdb.host_file.path by default

[James Peach (JIRA)]

James Peach created TS-4530:
---

 Summary: enable proxy.config.hostdb.host_file.path by default
 Key: TS-4530
 URL: https://issues.apache.org/jira/browse/TS-4530
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration
Reporter: James Peach


{{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
should enable it do that Traffic Server meets operators expectations in the 
default config.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4530) enable proxy.config.hostdb.host_file.path by default

[James Peach (JIRA)]

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

James Peach updated TS-4530:

Fix Version/s: 7.0.0

> enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4531) time unit confusion in HostDB sync interval

[James Peach (JIRA)]

James Peach created TS-4531:
---

 Summary: time unit confusion in HostDB sync interval
 Key: TS-4531
 URL: https://issues.apache.org/jira/browse/TS-4531
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: James Peach


In {{d48b76e}}, which is part of TS-4331, 
{{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
(nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4532) static type checking for time units

[James Peach (JIRA)]

James Peach created TS-4532:
---

 Summary: static type checking for time units
 Key: TS-4532
 URL: https://issues.apache.org/jira/browse/TS-4532
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: James Peach


Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are all 
typedefs of C integral types, it is very hard to ensure that units are being 
converted and compared correctly.

Consider wrapping these in trivial classes as part of making the time APIs more 
straightforward. Alternatively, if we move to {{C++11}} investigate 
{{std::chrono}} for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4526:
---
Fix Version/s: 6.2.0

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 6.2.0, 7.0.0
>
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4527) vc error messages in 6.2.0 release

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4527:
---
Fix Version/s: 6.2.0

> vc error messages in 6.2.0 release
> --
>
> Key: TS-4527
> URL: https://issues.apache.org/jira/browse/TS-4527
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 6.2.0
>
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4528) Active connections count is high in the 6.2.0 release

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4528:
---
Affects Version/s: 6.2.0

> Active connections count is high in the 6.2.0 release
> -
>
> Key: TS-4528
> URL: https://issues.apache.org/jira/browse/TS-4528
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 6.2.0
>
>
> There is either a problem with the number of active connections or the stat 
> is off.  When running traffic_top:
> {code}
> Active Con   2.4K
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4528) Active connections count is high in the 6.2.0 release

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4528:
---
Fix Version/s: 6.2.0

> Active connections count is high in the 6.2.0 release
> -
>
> Key: TS-4528
> URL: https://issues.apache.org/jira/browse/TS-4528
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 6.2.0
>
>
> There is either a problem with the number of active connections or the stat 
> is off.  When running traffic_top:
> {code}
> Active Con   2.4K
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4528) Active connections count is high in the 6.2.0 release

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4528:
---
  Affects Version/s: (was: 6.2.0)
Backport to Version: 6.2.0
  Fix Version/s: (was: 6.2.0)
 7.0.0

> Active connections count is high in the 6.2.0 release
> -
>
> Key: TS-4528
> URL: https://issues.apache.org/jira/browse/TS-4528
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> There is either a problem with the number of active connections or the stat 
> is off.  When running traffic_top:
> {code}
> Active Con   2.4K
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4527) vc error messages in 6.2.0 release

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4527:
---
Backport to Version: 6.2.0
  Fix Version/s: (was: 6.2.0)
 7.0.0

> vc error messages in 6.2.0 release
> --
>
> Key: TS-4527
> URL: https://issues.apache.org/jira/browse/TS-4527
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4526) ASAN SEGV on unknown address (6.2.0)

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4526:
---
Backport to Version: 6.2.0
  Fix Version/s: (was: 6.2.0)

> ASAN SEGV on unknown address (6.2.0)
> 
>
> Key: TS-4526
> URL: https://issues.apache.org/jira/browse/TS-4526
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ASAN:SIGSEGV
> =
> ==11217==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x sp 0x2b853414daf8 bp 0x2b853414dc00 T6)
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x4c73ca in pthread_create (/home/y/bin64/traffic_server+0x4c73ca)
> #1 0xe9ee75 in ink_thread_create 
> ../../../trafficserver/lib/ts/ink_thread.h:147
> #2 0xe9ee75 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) ../../../trafficserver/iocore/eventsystem/Thread.cc:101
> #3 0xea8389 in EventProcessor::start(int, unsigned long) 
> ../../../trafficserver/iocore/eventsystem/UnixEventProcessor.cc:141
> #4 0x4ac4b7 in main ../../trafficserver/proxy/Main.cc:1733
> #5 0x381801ed5c in __libc_start_main (/lib64/libc.so.6+0x381801ed5c)
> ==11217==ABORTING
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4531) time unit confusion in HostDB sync interval

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4531:
--

Assignee: Thomas Jackson

> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: Thomas Jackson
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4531) time unit confusion in HostDB sync interval

[James Peach (JIRA)]

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

James Peach updated TS-4531:

Fix Version/s: 7.0.0

> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4531) time unit confusion in HostDB sync interval

[James Peach (JIRA)]

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

James Peach reassigned TS-4531:
---

Assignee: James Peach  (was: Thomas Jackson)

> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4531) time unit confusion in HostDB sync interval

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4531:


GitHub user jpeach opened a pull request:

https://github.com/apache/trafficserver/pull/704

TS-4531: Clarify time unit confusion in HostDB sync interval.

Commit d48b76e tried to fix some of the time unit conversions in
HostBD, but didn't notice that RefCountedHostsFileMap::next_sync_time
was getting initialized to a nanosecond timestamp + an interval in
seconds.

This clarifies most of the timestamps uses in hosts file update
checking, which are all in Unix epoch seconds. We remove the
HOST_DB_TIMEOUT_INTERVAL definition since that interval is not
really a changeable (all the code assumes it is 1 sec).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jpeach/trafficserver fix/4531

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/704.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #704


commit affe97bbd37d9194f4057860ef632a4644c79892
Author: James Peach 
Date:   2016-06-13T21:25:40Z

TS-4531: Clarify time unit confusion in HostDB sync interval.

Commit d48b76e tried to fix some of the time unit conversions in
HostBD, but didn't notice that RefCountedHostsFileMap::next_sync_time
was getting initialized to a nanosecond timestamp + an interval in
seconds.

This clarifies most of the timestamps uses in hosts file update
checking, which are all in Unix epoch seconds. We remove the
HOST_DB_TIMEOUT_INTERVAL definition since that interval is not
really a changeable (all the code assumes it is 1 sec).




> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4529:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/703
  
Is this fix related to something we previously did to break it? Basically, 
what I'm asking is, should this go into a 6.2.0 back port?


> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4531) time unit confusion in HostDB sync interval

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4531:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/704
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/124/ for details.
 



> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4529:


Github user calavera commented on the issue:

https://github.com/apache/trafficserver/pull/703
  
Yes, I think it should be backported since 
https://issues.apache.org/jira/browse/TS-4478 is in 6.2.0 but it's not complete 
without this addition.


> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4529:
--
Backport to Version: 6.2.0

> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
> Fix For: 7.0.0
>
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4529:
--
Fix Version/s: 7.0.0

> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
> Fix For: 7.0.0
>
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4529:
---

That's what I thought, tagging as a 6.2.0 back port candidate.

> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
> Fix For: 7.0.0
>
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4529:
--
Assignee: David Calavera

> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
>Assignee: David Calavera
> Fix For: 7.0.0
>
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4531) time unit confusion in HostDB sync interval

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4531:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/704
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/227/ for details.
 



> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4531) time unit confusion in HostDB sync interval

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4531:


Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/704
  
Ping @jacksontj @SolidWallOfCode 


> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4529:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/703
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/123/ for details.
 



> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
>Assignee: David Calavera
> Fix For: 7.0.0
>
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4531) time unit confusion in HostDB sync interval

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4531:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/704
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/125/ for details.
 



> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4529) HttpSM doesn't assign the right continuation when adjusting threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4529:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/703
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/226/ for details.
 



> HttpSM doesn't assign the right continuation when adjusting threads
> ---
>
> Key: TS-4529
> URL: https://issues.apache.org/jira/browse/TS-4529
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: David Calavera
>Assignee: David Calavera
> Fix For: 7.0.0
>
>
> We're still seeing some segfaults after testing [~shinrich]'s patch in 
> https://github.com/apache/trafficserver/pull/688 more thoroughly.
> I have a patch that seems to fix those remaining issues and I'll open a Pull 
> Request right away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4531) time unit confusion in HostDB sync interval

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4531:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/704
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/228/ for details.
 



> time unit confusion in HostDB sync interval
> ---
>
> Key: TS-4531
> URL: https://issues.apache.org/jira/browse/TS-4531
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{d48b76e}}, which is part of TS-4331, 
> {{RefCountedHostsFileMap::next_sync_time}} is treated as {{ink_hrtime}} 
> (nanoseconds) but in fact it is {{ink_time_t}} (seconds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4424) ASAN: heap-buffer-overflow (6.2.0)

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4424:


Someone within Yahoo is seeing a very similar crash.  They are also running 
with max_record_size set to -1 and Http2 enabled.  I was able to look at one of 
their cores with symbols for ATS and for openssl 1.0.2.  Based on what I've 
seen so far, I think it is due to a bad combination with calling SSL_write on a 
non-blocking socket and dynamically sizing the SSL record block. 
(max_record_size == -1).

The openssl docs say that if SSL_write() is called on a non-blocking socket and 
the operation fails with NEEDS_WRITE, the next call must have the exact same 
arguments (same buffer and length).  If we are doing the dynamic sizing, the 
block size might change.  Based on this core, it looks like we downsized the 
block size from 16K to 1300.  

Working through ssl3_write_bytes in s3_pkt.c, we see at the crash point the 
variable tot = 54943.  The library uses that offset again the buffer, which is 
way off the end of the buffer.  So things crash.  

Earlier in the function there is a test to fail if len is less than tot (line 
670), but after that we see if there is any data left to write from previous 
attempts.  It is nicely annotated with the following comment.
{code}
/*
 * ensure that if we end up with a smaller value of data to write out
 * than the the original len from a write which didn't complete for
 * non-blocking I/O and also somehow ended up avoiding the check for
 * this in ssl3_write_pending/SSL_R_BAD_WRITE_RETRY as it must never be
 * possible to end up with (len-tot) as a large number that will then
 * promptly send beyond the end of the users buffer ... so we trap and
 * report the error in a way the user will notice
 */
{code}

If this ssl3_write_pending is called, tot is incremented.  I'm guessing that 
tot is incremented beyond the len parameter. So by the time we get to line 823, 
the unsigned int n is computed as a large positive number (rather than a 
negative).  

tot = 54953
len = 1300
n = nw = len - tot = 0x2e6b.

So, if we don't change the block size, we should be ok.  I assume that the 
1.0.1 version would return an error in this case and not crash.

To allow for dynamic block sizes, we will need to add state to determine 
whether the last write attempt failed or not.


k

> ASAN: heap-buffer-overflow (6.2.0)
> --
>
> Key: TS-4424
> URL: https://issues.apache.org/jira/browse/TS-4424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>  Labels: crash
> Fix For: 7.0.0
>
>
> From a few days ago:
> {code}
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> [May  2 16:09:34.060] Manager {0x7f44c4e94800} WARNING: Be aware that access 
> control checks for HTTP/2 connections are not active!
> =
> ==17268==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x62a0064b5000 at pc 0x2b8fd0a73615 bp 0x7ffd34d416e0 sp 0x7ffd34d40e90
> READ of size 16384 at 0x62a0064b5000 thread T0 ([ET_NET 0])
> #0 0x2b8fd0a73614 in __asan_memcpy 
> ../../../../libsanitizer/asan/asan_interceptors.cc:367
> #1 0x2b8fd26f7b63 in ssl3_write_bytes 
> (/opt/openssl/lib/libssl.so.1.0.0+0x29b63)
> #2 0xbfe2e0 in SSLWriteBuffer(ssl_st*, void const*, long, long&) 
> /usr/local/src/trafficserver/iocore/net/SSLUtils.cc:2041
> #3 0xbd2a6a in SSLNetVConnection::load_buffer_and_write(long, long&, 
> long&, MIOBufferAccessor&, int&) 
> /usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:735
> #4 0xc48dad in write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*) /usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:511
> #5 0xc0a8ba in NetHandler::mainNetEvent(int, Event*) 
> /usr/local/src/trafficserver/iocore/net/UnixNet.cc:529
> #6 0xcf6da3 in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:153
> #7 0xcf6da3 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:129
> #8 0xcf9d4a in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:256
> #9 0x498ad5 in main /usr/local/src/trafficserver/proxy/Main.cc:1909
> #10 0x2b8fd475bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #11 0x4a8244  (/opt/ats/bin/traffic_server+0x4a8244)
> 0x62a0064b5000 is located 0 bytes to the right of 16384-byte region 
> [0x62a0064b1000,0x62a0064b5000)
> allocated by thr

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/231/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/128/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/131/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/130/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/230/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/234/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/132/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/235/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/133/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/134/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4533) Support port numbers in resolv.conf

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4533:
--

Assignee: Thomas Jackson

> Support port numbers in resolv.conf
> ---
>
> Key: TS-4533
> URL: https://issues.apache.org/jira/browse/TS-4533
> Project: Traffic Server
>  Issue Type: New Feature
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Not terribly useful for production use-cases (although it could be), this is 
> primarily required for testing of our DNS resolution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4533) Support port numbers in resolv.conf

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4533:
--

 Summary: Support port numbers in resolv.conf
 Key: TS-4533
 URL: https://issues.apache.org/jira/browse/TS-4533
 Project: Traffic Server
  Issue Type: New Feature
Reporter: Thomas Jackson


Not terribly useful for production use-cases (although it could be), this is 
primarily required for testing of our DNS resolution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/236/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4533) Support port numbers in resolv.conf

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4533:
---
Fix Version/s: 7.0.0

> Support port numbers in resolv.conf
> ---
>
> Key: TS-4533
> URL: https://issues.apache.org/jira/browse/TS-4533
> Project: Traffic Server
>  Issue Type: New Feature
>Reporter: Thomas Jackson
> Fix For: 7.0.0
>
>
> Not terribly useful for production use-cases (although it could be), this is 
> primarily required for testing of our DNS resolution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4407) Need automated test coverage for hostdb's "serve_stale_for"

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4407:
---
Fix Version/s: (was: sometime)
   7.0.0

> Need automated test coverage for hostdb's "serve_stale_for"
> ---
>
> Key: TS-4407
> URL: https://issues.apache.org/jira/browse/TS-4407
> Project: Traffic Server
>  Issue Type: Test
>  Components: HostDB, Tests
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> config option: 
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=records.config#proxy-config-hostdb-serve-stale-for
> This feature allows hostdb to continue serving stale records until a new one 
> can be acquired. As of today we have no real tests around this, so to do that 
> we'll need to first make ATS support port numbers in resolv.conf-- then we 
> can easily wire up some tsqa tests to test the various failure modes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4407) Need automated test coverage for hostdb

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4407:
---
Summary: Need automated test coverage for hostdb  (was: Need automated test 
coverage for hostdb's "serve_stale_for")

> Need automated test coverage for hostdb
> ---
>
> Key: TS-4407
> URL: https://issues.apache.org/jira/browse/TS-4407
> Project: Traffic Server
>  Issue Type: Test
>  Components: HostDB, Tests
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> config option: 
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=records.config#proxy-config-hostdb-serve-stale-for
> This feature allows hostdb to continue serving stale records until a new one 
> can be acquired. As of today we have no real tests around this, so to do that 
> we'll need to first make ATS support port numbers in resolv.conf-- then we 
> can easily wire up some tsqa tests to test the various failure modes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/135/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4407) Need automated test coverage for hostdb's "serve_stale_foe"

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4407:
---
Summary: Need automated test coverage for hostdb's "serve_stale_foe"  (was: 
Need automated test coverage for hostdb's "serve_stale_fo)

> Need automated test coverage for hostdb's "serve_stale_foe"
> ---
>
> Key: TS-4407
> URL: https://issues.apache.org/jira/browse/TS-4407
> Project: Traffic Server
>  Issue Type: Test
>  Components: HostDB, Tests
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> config option: 
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=records.config#proxy-config-hostdb-serve-stale-for
> This feature allows hostdb to continue serving stale records until a new one 
> can be acquired. As of today we have no real tests around this, so to do that 
> we'll need to first make ATS support port numbers in resolv.conf-- then we 
> can easily wire up some tsqa tests to test the various failure modes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/237/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4407) Need automated test coverage for hostdb's "serve_stale_fo

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4407:
---
Summary: Need automated test coverage for hostdb's "serve_stale_fo  (was: 
Need automated test coverage for hostdb)

> Need automated test coverage for hostdb's "serve_stale_fo
> -
>
> Key: TS-4407
> URL: https://issues.apache.org/jira/browse/TS-4407
> Project: Traffic Server
>  Issue Type: Test
>  Components: HostDB, Tests
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> config option: 
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=records.config#proxy-config-hostdb-serve-stale-for
> This feature allows hostdb to continue serving stale records until a new one 
> can be acquired. As of today we have no real tests around this, so to do that 
> we'll need to first make ATS support port numbers in resolv.conf-- then we 
> can easily wire up some tsqa tests to test the various failure modes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4407) Need automated test coverage for hostdb's "serve_stale_for"

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4407:
---
Summary: Need automated test coverage for hostdb's "serve_stale_for"  (was: 
Need automated test coverage for hostdb's "serve_stale_foe")

> Need automated test coverage for hostdb's "serve_stale_for"
> ---
>
> Key: TS-4407
> URL: https://issues.apache.org/jira/browse/TS-4407
> Project: Traffic Server
>  Issue Type: Test
>  Components: HostDB, Tests
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> config option: 
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=records.config#proxy-config-hostdb-serve-stale-for
> This feature allows hostdb to continue serving stale records until a new one 
> can be acquired. As of today we have no real tests around this, so to do that 
> we'll need to first make ATS support port numbers in resolv.conf-- then we 
> can easily wire up some tsqa tests to test the various failure modes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/136/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4534) hostdb `showall` endpoint with format=json is invalid json

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4534:
--

 Summary: hostdb `showall` endpoint with format=json is invalid json
 Key: TS-4534
 URL: https://issues.apache.org/jira/browse/TS-4534
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4534) hostdb `showall` endpoint with format=json is invalid json

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4534:
--

Assignee: Thomas Jackson

> hostdb `showall` endpoint with format=json is invalid json
> --
>
> Key: TS-4534
> URL: https://issues.apache.org/jira/browse/TS-4534
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4534) hostdb `showall` endpoint with format=json is invalid json

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4534:
---
Fix Version/s: 7.0.0

> hostdb `showall` endpoint with format=json is invalid json
> --
>
> Key: TS-4534
> URL: https://issues.apache.org/jira/browse/TS-4534
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/238/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/137/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4535) segfault in hostdb when "serve_stale_for" on a reverse-dns lookup

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4535:
--

 Summary: segfault in hostdb when "serve_stale_for" on a 
reverse-dns lookup
 Key: TS-4535
 URL: https://issues.apache.org/jira/browse/TS-4535
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson


Before starting the background continuation to refresh the IP hostdb attempts 
to verify that the request is `!is_dotted_form_hostname`, in the reverse-dns 
case there is no hostname so the method segfaults. Regardless of format, if the 
record is expired and we are configured to serve stale while revalidating-- we 
should do just that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/239/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4535) segfault in hostdb for serve_stale_for with no hostname

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4535:
---
Fix Version/s: 7.0.0

> segfault in hostdb for serve_stale_for with no hostname
> ---
>
> Key: TS-4535
> URL: https://issues.apache.org/jira/browse/TS-4535
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Before starting the background continuation to refresh the IP hostdb attempts 
> to verify that the request is `!is_dotted_form_hostname`, in the reverse-dns 
> case there is no hostname so the method segfaults. Regardless of format, if 
> the record is expired and we are configured to serve stale while 
> revalidating-- we should do just that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4535) segfault in hostdb for serve_stale_for with no hostname

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4535:
--

Assignee: Thomas Jackson

> segfault in hostdb for serve_stale_for with no hostname
> ---
>
> Key: TS-4535
> URL: https://issues.apache.org/jira/browse/TS-4535
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Before starting the background continuation to refresh the IP hostdb attempts 
> to verify that the request is `!is_dotted_form_hostname`, in the reverse-dns 
> case there is no hostname so the method segfaults. Regardless of format, if 
> the record is expired and we are configured to serve stale while 
> revalidating-- we should do just that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4535) segfault in hostdb for serve_stale_for with no hostname

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4535:
---
Summary: segfault in hostdb for serve_stale_for with no hostname  (was: 
segfault in hostdb when "serve_stale_for" on a reverse-dns lookup)

> segfault in hostdb for serve_stale_for with no hostname
> ---
>
> Key: TS-4535
> URL: https://issues.apache.org/jira/browse/TS-4535
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
> Fix For: 7.0.0
>
>
> Before starting the background continuation to refresh the IP hostdb attempts 
> to verify that the request is `!is_dotted_form_hostname`, in the reverse-dns 
> case there is no hostname so the method segfaults. Regardless of format, if 
> the record is expired and we are configured to serve stale while 
> revalidating-- we should do just that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4536) hostdb serve_stale_for records sometimes never expire

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4536:
--

 Summary: hostdb serve_stale_for records sometimes never expire
 Key: TS-4536
 URL: https://issues.apache.org/jira/browse/TS-4536
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson


In hostdb when a record is served stale while revalidated-- the ip is 
refreshed. This means that hostdb sets the "query time" to when the record was 
served. In the extreme case, if a request comes in every second for the record 
it will NEVER expire-- which is presumably not what you want (nor what you 
configured).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/240/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/138/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/241/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4537) Add erase to PriorityQueue

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4537:
--

 Summary: Add erase to PriorityQueue
 Key: TS-4537
 URL: https://issues.apache.org/jira/browse/TS-4537
 Project: Traffic Server
  Issue Type: New Feature
Reporter: Thomas Jackson


The priorityqueue (really more of a sorted list...) doesn't have an erase 
method-- we probably should have one :)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4537) Add erase to PriorityQueue

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4537:
---
Fix Version/s: 7.0.0

> Add erase to PriorityQueue
> --
>
> Key: TS-4537
> URL: https://issues.apache.org/jira/browse/TS-4537
> Project: Traffic Server
>  Issue Type: New Feature
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> The priorityqueue (really more of a sorted list...) doesn't have an erase 
> method-- we probably should have one :)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4537) Add erase to PriorityQueue

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4537:
--

Assignee: Thomas Jackson

> Add erase to PriorityQueue
> --
>
> Key: TS-4537
> URL: https://issues.apache.org/jira/browse/TS-4537
> Project: Traffic Server
>  Issue Type: New Feature
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> The priorityqueue (really more of a sorted list...) doesn't have an erase 
> method-- we probably should have one :)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/139/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)