[jira] [Commented] (TS-4055) Segmentation fault

2015-12-14 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom commented on TS-4055:
---

[~bcall] Please review :).

> Segmentation fault 
> ---
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
>  Labels: crash
> Fix For: 6.1.0
>
>
> {code}
> c++filt  traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int, 
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xc8)[0x5c5e38]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
> Event*)+0x4ff)[0x78651f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
> Event*)+0x28d)[0x7789ad]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8a)[0x7bdf5a]
> /usr/bin/traffic_server(EThread::execute()+0xaa5)[0x7bf045]
> /usr/bin/traffic_server[0x7bda25]
> /lib64/libpthread.so.0(+0x7555)[0x2abaac559555]
> /lib64/libc.so.6(clone+0x6d)[0x2abaad67bb9d]
> Dec 05 21:00:12 localhost sendEmail[23289]: Email was sent successfully!
> {code}



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

[jira] [Updated] (TS-4055) Segmentation fault

2015-12-14 Thread Bryan Call (JIRA) 

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

Bryan Call updated TS-4055:
---
Fix Version/s: 6.0.1

> Segmentation fault 
> ---
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
>  Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt  traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int, 
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xc8)[0x5c5e38]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
> Event*)+0x4ff)[0x78651f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
> Event*)+0x28d)[0x7789ad]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8a)[0x7bdf5a]
> /usr/bin/traffic_server(EThread::execute()+0xaa5)[0x7bf045]
> /usr/bin/traffic_server[0x7bda25]
> /lib64/libpthread.so.0(+0x7555)[0x2abaac559555]
> /lib64/libc.so.6(clone+0x6d)[0x2abaad67bb9d]
> Dec 05 21:00:12 localhost sendEmail[23289]: Email was sent successfully!
> {code}



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

[jira] [Updated] (TS-4055) Segmentation fault

2015-12-14 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom updated TS-4055:
--
Assignee: Bryan Call

> Segmentation fault 
> ---
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
>  Labels: crash
> Fix For: 6.1.0
>
>
> {code}
> c++filt  traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int, 
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xc8)[0x5c5e38]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
> Event*)+0x4ff)[0x78651f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
> Event*)+0x28d)[0x7789ad]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8a)[0x7bdf5a]
> /usr/bin/traffic_server(EThread::execute()+0xaa5)[0x7bf045]
> /usr/bin/traffic_server[0x7bda25]
> /lib64/libpthread.so.0(+0x7555)[0x2abaac559555]
> /lib64/libc.so.6(clone+0x6d)[0x2abaad67bb9d]
> Dec 05 21:00:12 localhost sendEmail[23289]: Email was sent successfully!
> {code}



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

[jira] [Updated] (TS-4076) Cache Single Fragment

2015-12-14 Thread song (JIRA) 

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

song updated TS-4076:
-
Attachment: AB4B05B1-12BD-4F5A-B6E5-D2B1420826A0.png

> Cache Single Fragment
> -
>
> Key: TS-4076
> URL: https://issues.apache.org/jira/browse/TS-4076
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: song
> Attachments: AB4B05B1-12BD-4F5A-B6E5-D2B1420826A0.png
>
>
> Dear all
> In CacheVC::openReadStartHead function, it is unnecessary to calculate the 
> next key with a single fragment, because we have already done for a read 
> operation.Why do we do this.



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

[jira] [Closed] (TS-3985) TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash

2015-12-14 Thread song (JIRA) 

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

song closed TS-3985.

Resolution: Fixed

> TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash
> 
>
> Key: TS-3985
> URL: https://issues.apache.org/jira/browse/TS-3985
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS
>Reporter: song
>  Labels: Review
> Fix For: 6.1.0
>
> Attachments: untitled.diff
>
>
> Dear
> ATS cause a crash in how_to_open_connection  while using 
> TSHttpTxnCacheLookupStatusSet . In Function 
> HttpTransact::HandleCacheOpenReadHit, the hook pending_work was set to 
> issue_revalidate function and the variable " s->current.request_to = 
> ORIGIN_SERVER". But the hook  only be released while talking to a parent 
> proxy in PPDNSLookup function. How to fix it.
> thanks



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

[jira] [Updated] (TS-4077) Clean up doc build warnings

2015-12-14 Thread Miles Libbey (JIRA) 

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

Miles Libbey updated TS-4077:
-
Assignee: Jon Sime

> Clean up doc build warnings
> ---
>
> Key: TS-4077
> URL: https://issues.apache.org/jira/browse/TS-4077
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Miles Libbey
>Assignee: Jon Sime
>
> When building the documentation, there are a bunch of warnings about options, 
> invalid syntax etc.  We should clean these up.
> From a clean git repo:
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:160: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:176: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:195: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:281: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:305: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:360: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:413: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:457: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:483: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:520: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:541: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:568: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:584: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:612: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:640: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:672: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:18: 
> SEVERE: Problems with "include" directive path:
> InputError: [Errno 2] No such file or directory: 'admin-guide/common.defs'.
> trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:173: 
> WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:221: 
> WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:265:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:276:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:297:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:321:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuring-traffic-server.en.rst:65: WARNING: 
>

[jira] [Created] (TS-4077) Clean up doc build warnings

2015-12-14 Thread Miles Libbey (JIRA) 
Miles Libbey created TS-4077:


 Summary: Clean up doc build warnings
 Key: TS-4077
 URL: https://issues.apache.org/jira/browse/TS-4077
 Project: Traffic Server
  Issue Type: Bug
  Components: Documentation
Reporter: Miles Libbey


When building the documentation, there are a bunch of warnings about options, 
invalid syntax etc.  We should clean these up.


>From a clean git repo:

trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:160: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:176: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:195: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:281: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:305: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:360: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:413: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:457: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:483: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:520: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:541: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:568: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:584: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:612: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:640: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:672: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:18: 
SEVERE: Problems with "include" directive path:
InputError: [Errno 2] No such file or directory: 'admin-guide/common.defs'.
trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:173: 
WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
option marker - or -- or /
trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:221: 
WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
option marker - or -- or /
trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:265:
 WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
option marker - or -- or /
trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:276:
 WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
option marker - or -- or /
trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:297:
 WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
option marker - or -- or /
trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:321:
 WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
option marker - or -- or /
trafficserver/doc/admin-guide/configuring-traffic-server.en.rst:65: WARNING: 
Malformed :option: u'traffic_ctl config reload', does not contain option marker 
- or -- or /
trafficserver/doc/admin-guide/files/cache.config.en.rst:35: WARNING: Malformed 
:option: u'traffic_ctl config reload', does not contain option marker - or -- 
or /
trafficserver/doc/admin-guide/files/congestion.config.en.rst:24: WARNING: 
Malformed

[jira] [Updated] (TS-3985) TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash

2015-12-14 Thread song (JIRA) 

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

song updated TS-3985:
-
Affects Version/s: 6.0.0
  Environment: Cache Single Fragment
  Description: 
Dear all

In CacheVC::openReadStartHead function, it is unnecessary to calculate the next 
key with a single fragment, because we have already done for a read 
operation.Why do we do this. 

  was:
Dear

ATS cause a crash in how_to_open_connection  while using 
TSHttpTxnCacheLookupStatusSet . In Function 
HttpTransact::HandleCacheOpenReadHit, the hook pending_work was set to 
issue_revalidate function and the variable " s->current.request_to = 
ORIGIN_SERVER". But the hook  only be released while talking to a parent proxy 
in PPDNSLookup function. How to fix it.

thanks

  Component/s: (was: DNS)
   Issue Type: Improvement  (was: Bug)

> TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash
> 
>
> Key: TS-3985
> URL: https://issues.apache.org/jira/browse/TS-3985
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Affects Versions: 6.0.0
> Environment: Cache Single Fragment
>Reporter: song
>  Labels: Review
> Fix For: 6.1.0
>
> Attachments: untitled.diff
>
>
> Dear all
> In CacheVC::openReadStartHead function, it is unnecessary to calculate the 
> next key with a single fragment, because we have already done for a read 
> operation.Why do we do this. 



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

[jira] [Created] (TS-4076) Cache Single Fragment

2015-12-14 Thread song (JIRA) 
song created TS-4076:


 Summary: Cache Single Fragment
 Key: TS-4076
 URL: https://issues.apache.org/jira/browse/TS-4076
 Project: Traffic Server
  Issue Type: Improvement
Reporter: song



Dear all
In CacheVC::openReadStartHead function, it is unnecessary to calculate the next 
key with a single fragment, because we have already done for a read 
operation.Why do we do this.



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

[jira] [Closed] (TS-4076) Cache Single Fragment

2015-12-14 Thread song (JIRA) 

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

song closed TS-4076.

Resolution: Won't Fix

> Cache Single Fragment
> -
>
> Key: TS-4076
> URL: https://issues.apache.org/jira/browse/TS-4076
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: song
> Attachments: AB4B05B1-12BD-4F5A-B6E5-D2B1420826A0.png
>
>
> Dear all
> In CacheVC::openReadStartHead function, it is unnecessary to calculate the 
> next key with a single fragment, because we have already done for a read 
> operation.Why do we do this.



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

[jira] [Created] (TS-4075) segmentation fault due to reenable in SNI Hook for a closed ssl connection

2015-12-14 Thread Oknet Xu (JIRA) 
Oknet Xu created TS-4075:


 Summary: segmentation fault due to reenable in SNI Hook for a 
closed ssl connection
 Key: TS-4075
 URL: https://issues.apache.org/jira/browse/TS-4075
 Project: Traffic Server
  Issue Type: Bug
Reporter: Oknet Xu


I'm writing a ssl hook to look up a cert from mysql database.

the SNI Hook stall at fetch cert from mysql database due to a database dump 
lock every mid night.

the SSL Client got timeout and closing the connection before SNI Hook reenable 
the connection.

Segmentation fault due to the TSVConnSSLConnectionGet() can not get a SSLVC 
during reenable the SSLVC.

{code}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
void*)+0xa2)[0x2b90c9955b22]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b90cc1ea8d0]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(__dynamic_cast+0x60)[0x2b90cc9c3020]
/usr/bin/traffic_server(TSVConnSSLConnectionGet+0x1e)[0x2b90c997832e]
/usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::reenable()+0x8c)[0x2b90d5fe29dc]
/usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::destroy()+0xe5)[0x2b90d5fe2b85]
/usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_content(tsapi_vio*)+0x29b)[0x2b90d5fe34db]
/usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_read(TSEvent,
 tsapi_vio*)+0x36)[0x2b90d5fe3526]
/usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::dispatch(tsapi_cont*,
 TSEvent, void*)+0x95)[0x2b90d5fe35e5]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x366)[0x2b90c998b0a6]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x5a9)[0x2b90c998ba49]
/usr/bin/traffic_server(PluginVC::main_handler(int, 
void*)+0x371)[0x2b90c998e1c1]
/usr/bin/traffic_server(EThread::process_event(Event*, 
int)+0x90)[0x2b90c9bc8620]
/usr/bin/traffic_server(EThread::execute()+0x67f)[0x2b90c9bc922f]
/usr/bin/traffic_server(+0x369a1a)[0x2b90c9bc7a1a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b90cc1e30a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b90cd26704d]
traffic_server: using root directory '/usr'
{code}



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

[jira] [Commented] (TS-4075) segmentation fault due to reenable in SNI Hook for a closed ssl connection

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-4075:


GitHub user oknet opened a pull request:

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

TS-4075: add a state check for sslHandshakeHookState

Add a state check for sslHandshakeHookState after PreAcceptHookState 
checking in sslServerHandShakeEvent().
and modify the codes in reenable() and callHooks() to fit the patch

The Processing:
path A for normal handshake.
path B for ssl session reuse

1. client initial a tcp connection with ATS
2. ATS trigger a PreAccept Hooks
3. PreAccept Hooks Done
4a. client send a "Client Hello with Sever Cert Request"
5a. set handshakestate to CERT from PRE
6a. SSLAccept() got a "Server Cert Request" then trigger callHooks()
7a. set curHooks
8a. if curHook != NULL then set handshakestate to INVOKE and invoke hooks.
9a. reenable in Hooks A
10a. invoke Hook B and next Hooks ... until curHook == NULL
11a. set handshakestate to DONE
12. SSLAccept() handshake finished

4b. client send a "ssl session reuse request"
5b. set handshakestate to CERT from PRE
6b. SSLAccept() got a "ssl session reuse reques" then reuse session 
handshake finished
7b. set handshakestate to DONE from CERT

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

$ git pull https://github.com/oknet/trafficserver patch-2

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

https://github.com/apache/trafficserver/pull/374.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 #374


commit 0de7e196aadac090a412b720df7e5faf9183b5ba
Author: Oknet 
Date:   2015-12-14T12:00:45Z

TS-4075: add a state check for sslHandshakeHookState after 
PreAcceptHookState checking

Add a state check for sslHandshakeHookState after PreAcceptHookState 
checking in sslServerHandShakeEvent().
and modify the codes in reenable() and callHooks() to fit the patch

The Processing:

1. client initial a tcp connection with ATS
2. ATS trigger a PreAccept Hooks
3. PreAccept Hooks Done
4a. client send a "Client Hello with Sever Cert Request"
5a. set handshakestate to CERT from PRE
6a. SSLAccept() got a "Server Cert Request" then trigger callHooks()
7a. set curHooks
8a. if curHook != NULL then set handshakestate to INVOKE and invoke hooks.
9a. reenable in Hooks A
10a. invoke Hook B and next Hooks ... until curHook == NULL
11a. set handshakestate to DONE
12. SSLAccept() handshake finished

4b. client send a "ssl session reuse request"
5b. set handshakestate to CERT from PRE
6b. SSLAccept() got a "ssl session reuse reques" then reuse session 
handshake finished
7b. set handshakestate to DONE from CERT




> segmentation fault due to reenable in SNI Hook for a closed ssl connection
> --
>
> Key: TS-4075
> URL: https://issues.apache.org/jira/browse/TS-4075
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Oknet Xu
>
> I'm writing a ssl hook to look up a cert from mysql database.
> the SNI Hook stall at fetch cert from mysql database due to a database dump 
> lock every mid night.
> the SSL Client got timeout and closing the connection before SNI Hook 
> reenable the connection.
> Segmentation fault due to the TSVConnSSLConnectionGet() can not get a SSLVC 
> during reenable the SSLVC.
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [(nil)])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x2b90c9955b22]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b90cc1ea8d0]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(__dynamic_cast+0x60)[0x2b90cc9c3020]
> /usr/bin/traffic_server(TSVConnSSLConnectionGet+0x1e)[0x2b90c997832e]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::reenable()+0x8c)[0x2b90d5fe29dc]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::destroy()+0xe5)[0x2b90d5fe2b85]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_content(tsapi_vio*)+0x29b)[0x2b90d5fe34db]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_read(TSEvent,
>  tsapi_vio*)+0x36)[0x2b90d5fe3526]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::dispatch(tsapi_cont*,
>  TSEvent, void*)+0x95)[0x2b90d5fe35e5]
> /usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x366)[0x2b90c998b0a6]
> /usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x5a9)[0x2b90c998ba49]
>

[jira] [Resolved] (TS-4055) Segmentation fault

2015-12-14 Thread Bryan Call (JIRA) 

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

Bryan Call resolved TS-4055.

Resolution: Fixed

> Segmentation fault 
> ---
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
>  Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt  traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int, 
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xc8)[0x5c5e38]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
> Event*)+0x4ff)[0x78651f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
> Event*)+0x28d)[0x7789ad]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8a)[0x7bdf5a]
> /usr/bin/traffic_server(EThread::execute()+0xaa5)[0x7bf045]
> /usr/bin/traffic_server[0x7bda25]
> /lib64/libpthread.so.0(+0x7555)[0x2abaac559555]
> /lib64/libc.so.6(clone+0x6d)[0x2abaad67bb9d]
> Dec 05 21:00:12 localhost sendEmail[23289]: Email was sent successfully!
> {code}



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

[jira] [Commented] (TS-3960) traffic_line -x doesn't reload SSL certs content

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-3960:


Github user zizhong commented on the pull request:

https://github.com/apache/trafficserver/pull/301#issuecomment-164656248
  
@jpeach , I noticed you have changed the some details of the last commit. 
Thanks for your help. However, there is a bug that you introduced with the 
changes.
The line below
```if (rb->checkForUserUpdate(rb->isVersioned() ? ROLLBACK_CHECK_ONLY : 
ROLLBACK_CHECK_AND_UPDATE))```
should be
```if (rb->checkForUserUpdate(!rb->isVersioned() ? ROLLBACK_CHECK_ONLY : 
ROLLBACK_CHECK_AND_UPDATE))```.


> traffic_line -x doesn't reload SSL certs content
> 
>
> Key: TS-3960
> URL: https://issues.apache.org/jira/browse/TS-3960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Zhang Zizhong
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> traffic_line -x doesn't reload  when SSL certs change file contents without 
> changing the file names.



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

[jira] [Commented] (TS-4042) Add feature to buffer request body before making downstream requests

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-4042:


Github user sudheerv commented on the pull request:

https://github.com/apache/trafficserver/pull/351#issuecomment-164477130
  
@bgaff - Thanks, I'd have to double check though that the change made 
automatically handles a H2/SPDY upload. There's no Content-Length, nor even a 
TE header in those cases (although, perhaps, ATS implementation may make it 
appear like CHUNKED_ENCODING from FetchSM to HttpSM layer?)


> Add feature to buffer request body before making downstream requests
> 
>
> Key: TS-4042
> URL: https://issues.apache.org/jira/browse/TS-4042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, CPP API, TS API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> We need a way to examine the request body without making a downstream 
> request, this feature has many use cases including:
>   - Ability to buffer the body and ensure a full post is received before 
> committing downstream resources.
>   - Ability to choose an origin based on request body
>   - Ability to do request content filtering such as a WAF might provide 
> before the origin is involved.
> Today you have two options to inspect a request body:
>   1) Transformations: the problem with transformations is that you only start 
> receiving the request bytes after a sink has been established, which in this 
> case is the downstream origin.
>   2) Create an intercept and use fetch apis to then send the downstream 
> request: while this technically works it turns out to be a ton of code and is 
> in general pretty problematic, we actually tried this approach for a while 
> and had nothing but problems with it.
> We feel it would be ideal if we could intercept the body without breaking the 
> normal ATS state flow. There used to exist code (and it's still in the core 
> just #ifdefed out) to drain the request body. I use that code as the basis 
> for this request buffering code. We added APIs to both the C and C++ APIs so 
> that this request buffering can be enabled from a plugin and the plugin can 
> inspect the body as chunks arrive or when it's complete. We've included an 
> example plugin that will error a transaction if a minimum rate of transfer is 
> not maintained.
> I'm confident that this feature will bring plenty of questions / feedback, so 
> let's get that party started.



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

[jira] [Commented] (TS-4042) Add feature to buffer request body before making downstream requests

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-4042:


Github user sudheerv commented on the pull request:

https://github.com/apache/trafficserver/pull/351#issuecomment-164477764
  
Cool, thanks!


> Add feature to buffer request body before making downstream requests
> 
>
> Key: TS-4042
> URL: https://issues.apache.org/jira/browse/TS-4042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, CPP API, TS API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> We need a way to examine the request body without making a downstream 
> request, this feature has many use cases including:
>   - Ability to buffer the body and ensure a full post is received before 
> committing downstream resources.
>   - Ability to choose an origin based on request body
>   - Ability to do request content filtering such as a WAF might provide 
> before the origin is involved.
> Today you have two options to inspect a request body:
>   1) Transformations: the problem with transformations is that you only start 
> receiving the request bytes after a sink has been established, which in this 
> case is the downstream origin.
>   2) Create an intercept and use fetch apis to then send the downstream 
> request: while this technically works it turns out to be a ton of code and is 
> in general pretty problematic, we actually tried this approach for a while 
> and had nothing but problems with it.
> We feel it would be ideal if we could intercept the body without breaking the 
> normal ATS state flow. There used to exist code (and it's still in the core 
> just #ifdefed out) to drain the request body. I use that code as the basis 
> for this request buffering code. We added APIs to both the C and C++ APIs so 
> that this request buffering can be enabled from a plugin and the plugin can 
> inspect the body as chunks arrive or when it's complete. We've included an 
> example plugin that will error a transaction if a minimum rate of transfer is 
> not maintained.
> I'm confident that this feature will bring plenty of questions / feedback, so 
> let's get that party started.



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

[jira] [Commented] (TS-4042) Add feature to buffer request body before making downstream requests

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-4042:


Github user bgaff commented on the pull request:

https://github.com/apache/trafficserver/pull/351#issuecomment-164477595
  
That's correct since both use fetchsm if just works like a normal http 1.1 
request, as that's what fetch sm is. I've verified this functionality.


> Add feature to buffer request body before making downstream requests
> 
>
> Key: TS-4042
> URL: https://issues.apache.org/jira/browse/TS-4042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, CPP API, TS API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> We need a way to examine the request body without making a downstream 
> request, this feature has many use cases including:
>   - Ability to buffer the body and ensure a full post is received before 
> committing downstream resources.
>   - Ability to choose an origin based on request body
>   - Ability to do request content filtering such as a WAF might provide 
> before the origin is involved.
> Today you have two options to inspect a request body:
>   1) Transformations: the problem with transformations is that you only start 
> receiving the request bytes after a sink has been established, which in this 
> case is the downstream origin.
>   2) Create an intercept and use fetch apis to then send the downstream 
> request: while this technically works it turns out to be a ton of code and is 
> in general pretty problematic, we actually tried this approach for a while 
> and had nothing but problems with it.
> We feel it would be ideal if we could intercept the body without breaking the 
> normal ATS state flow. There used to exist code (and it's still in the core 
> just #ifdefed out) to drain the request body. I use that code as the basis 
> for this request buffering code. We added APIs to both the C and C++ APIs so 
> that this request buffering can be enabled from a plugin and the plugin can 
> inspect the body as chunks arrive or when it's complete. We've included an 
> example plugin that will error a transaction if a minimum rate of transfer is 
> not maintained.
> I'm confident that this feature will bring plenty of questions / feedback, so 
> let's get that party started.



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

[jira] [Commented] (TS-3960) traffic_line -x doesn't reload SSL certs content

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-3960:


Github user zizhong commented on the pull request:

https://github.com/apache/trafficserver/pull/301#issuecomment-164642165
  
@jpeach Thanks for the useful comments. I've made a new commit on your 
suggestions. Would you mind having another look?


> traffic_line -x doesn't reload SSL certs content
> 
>
> Key: TS-3960
> URL: https://issues.apache.org/jira/browse/TS-3960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Zhang Zizhong
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> traffic_line -x doesn't reload  when SSL certs change file contents without 
> changing the file names.



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

[jira] [Resolved] (TS-3960) traffic_line -x doesn't reload SSL certs content

2015-12-14 Thread James Peach (JIRA) 

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

James Peach resolved TS-3960.
-
Resolution: Fixed
  Assignee: James Peach  (was: Brian Geffon)

Merged. Note that this makes the 10K certificate configuration a fair but worse.

> traffic_line -x doesn't reload SSL certs content
> 
>
> Key: TS-3960
> URL: https://issues.apache.org/jira/browse/TS-3960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Zhang Zizhong
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> traffic_line -x doesn't reload  when SSL certs change file contents without 
> changing the file names.



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

[jira] [Commented] (TS-3960) traffic_line -x doesn't reload SSL certs content

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-3960:


Github user asfgit closed the pull request at:

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


> traffic_line -x doesn't reload SSL certs content
> 
>
> Key: TS-3960
> URL: https://issues.apache.org/jira/browse/TS-3960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Zhang Zizhong
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> traffic_line -x doesn't reload  when SSL certs change file contents without 
> changing the file names.



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

[jira] [Updated] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin

2015-12-14 Thread Bryan Call (JIRA) 

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

Bryan Call updated TS-4055:
---
Summary: Coredump when closing a transaction with a stalled connection to 
the origin(was: Segmentation fault )

> Coredump when closing a transaction with a stalled connection to the origin  
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
>  Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt  traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int, 
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xc8)[0x5c5e38]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
> Event*)+0x4ff)[0x78651f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
> Event*)+0x28d)[0x7789ad]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8a)[0x7bdf5a]
> /usr/bin/traffic_server(EThread::execute()+0xaa5)[0x7bf045]
> /usr/bin/traffic_server[0x7bda25]
> /lib64/libpthread.so.0(+0x7555)[0x2abaac559555]
> /lib64/libc.so.6(clone+0x6d)[0x2abaad67bb9d]
> Dec 05 21:00:12 localhost sendEmail[23289]: Email was sent successfully!
> {code}



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

Failed: trafficserver (latest)

2015-12-14 Thread Read the Docs 

Build Failed for trafficserver (latest)



Error:
Version locked, retrying in 5 minutes.

You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/3565874/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[jira] [Commented] (TS-4055) Coredump when closing a transaction with a stalled connection to the origin

2015-12-14 Thread bettydramit (JIRA) 

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

bettydramit commented on TS-4055:
-

It works with https://github.com/apache/trafficserver/pull/373.patch(running 
over 48 Hours)

> Coredump when closing a transaction with a stalled connection to the origin  
> -
>
> Key: TS-4055
> URL: https://issues.apache.org/jira/browse/TS-4055
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.0.1
>Reporter: bettydramit
>Assignee: Bryan Call
>  Labels: crash
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> c++filt  traffic_server: Segmentation fault (Address not mapped to object [0x8])
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x8e)[0x4abf4e]
> /lib64/libpthread.so.0(+0x10430)[0x2abaac562430]
> /usr/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x25b)[0x5b5d0b]
> /usr/bin/traffic_server(HttpSM::state_send_server_request_header(int, 
> void*)+0x142)[0x5c0dd2]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xc8)[0x5c5e38]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
> Event*)+0x4ff)[0x78651f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
> Event*)+0x28d)[0x7789ad]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8a)[0x7bdf5a]
> /usr/bin/traffic_server(EThread::execute()+0xaa5)[0x7bf045]
> /usr/bin/traffic_server[0x7bda25]
> /lib64/libpthread.so.0(+0x7555)[0x2abaac559555]
> /lib64/libc.so.6(clone+0x6d)[0x2abaad67bb9d]
> Dec 05 21:00:12 localhost sendEmail[23289]: Email was sent successfully!
> {code}



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

[jira] [Commented] (TS-4056) MemLeak: ～NetAccept() do not free alloc_cache(vc)

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-4056:


Github user asfgit closed the pull request at:

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


> MemLeak: ～NetAccept() do not free alloc_cache(vc)
> -
>
> Key: TS-4056
> URL: https://issues.apache.org/jira/browse/TS-4056
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.0
>Reporter: Oknet Xu
>  Labels: review
> Fix For: 6.1.0
>
>
> NetAccpet::alloc_cache is a void pointor is used in net_accept().
> the alloc_cache does not release after NetAccept canceled.
> I'm looking for all code, believe the "alloc_cache" is a bad idea here.
> I create a pull request on github: 
> https://github.com/apache/trafficserver/pull/366
> also add a condition check for vc==NULL after allocate_vc()



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

[jira] [Commented] (TS-4056) MemLeak: ～NetAccept() do not free alloc_cache(vc)

2015-12-14 Thread ASF subversion and git services (JIRA) 

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

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

Commit f7a0cc9ac1b6b2e4c3710a5208b4caa9a463c959 in trafficserver's branch 
refs/heads/6.0.x from [~oknet]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f7a0cc9 ]

TS-4056: remove alloc_cache from NetAccept

This closes #366

(cherry picked from commit f17e7c6ddf8d771b3dc21b59360e982c55423c46)


> MemLeak: ～NetAccept() do not free alloc_cache(vc)
> -
>
> Key: TS-4056
> URL: https://issues.apache.org/jira/browse/TS-4056
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.0
>Reporter: Oknet Xu
>  Labels: review
> Fix For: 6.1.0
>
>
> NetAccpet::alloc_cache is a void pointor is used in net_accept().
> the alloc_cache does not release after NetAccept canceled.
> I'm looking for all code, believe the "alloc_cache" is a bad idea here.
> I create a pull request on github: 
> https://github.com/apache/trafficserver/pull/366
> also add a condition check for vc==NULL after allocate_vc()



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

[jira] [Resolved] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

2015-12-14 Thread Phil Sorber (JIRA) 

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

Phil Sorber resolved TS-4030.
-
Resolution: Fixed

> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



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

[jira] [Commented] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-4030:


Github user asfgit closed the pull request at:

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


> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



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

[jira] [Commented] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

2015-12-14 Thread ASF subversion and git services (JIRA) 

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

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

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

TS-4030: Add docs for new 'qstring' param in parent.config


> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



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

[jira] [Issue Comment Deleted] (TS-2687) Support for MIPS platform

2015-12-14 Thread Dejan Latinovic (JIRA) 

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

Dejan Latinovic updated TS-2687:

Comment: was deleted

(was: *Current status*: 
* Work on Tizen X11 with openGL drivers
** Usage of PVR OpenGL drivers from Enlightenment windows manager. 
*** Zubair and Brendan King are contacted due to Enlightenment issues with 
OpenGL drivers.
The work on next DDK release is in progress, they could not help us at the 
moment.
*** Running SGX demos on Enlightenment
Enlightenment with software_x11 engine works fine,
SGX demos works slower than if we use Enlightenment with gl_x11 engine.
*** Enlightenment was built against system libGL (instead of PVR libGLES).
 It uses jz4870 PRV driver (as on Debian).
 It uses gl_x11 engine only.
 It behaves the same as with PRV libGLES:
black screen appears on creation of new window.
 Black screen appears in efl (Enlightenment) eglSwapBuffers function.
 Further investigation in progress. 

*Next steps* :
** Work on Tizen X11
*** Continue work on Enlightenment with PVR OpenGL issue.
)

> Support for MIPS platform
> -
>
> Key: TS-2687
> URL: https://issues.apache.org/jira/browse/TS-2687
> Project: Traffic Server
>  Issue Type: New Feature
>Reporter: Dejan Latinovic
>Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
> Attachments: mips-support.patch
>
>
> While trying to build trafficserver on mips architecture,
> build fails with an error:
> {code:borderStyle=solid}
> In file included from ../../lib/ts/libts.h:64:0,
>  from P_EventSystem.h:34,
>  from EventSystem.cc:31:
> ../../lib/ts/ink_queue.h:144:2: error: #error "unsupported processor"
>  #error "unsupported processor"
> {code}



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

[jira] [Commented] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

2015-12-14 Thread ASF subversion and git services (JIRA) 

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

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

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

TS-4030: Allow parent selection to ignore query string

This closes #369.


> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



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

[jira] [Commented] (TS-2687) Support for MIPS platform

2015-12-14 Thread Dejan Latinovic (JIRA) 

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

Dejan Latinovic commented on TS-2687:
-

*Current status*: 
* Work on Tizen X11 with openGL drivers
** Usage of PVR OpenGL drivers from Enlightenment windows manager. 
*** Zubair and Brendan King are contacted due to Enlightenment issues with 
OpenGL drivers.
The work on next DDK release is in progress, they could not help us at the 
moment.
*** Running SGX demos on Enlightenment
Enlightenment with software_x11 engine works fine,
SGX demos works slower than if we use Enlightenment with gl_x11 engine.
*** Enlightenment was built against system libGL (instead of PVR libGLES).
 It uses jz4870 PRV driver (as on Debian).
 It uses gl_x11 engine only.
 It behaves the same as with PRV libGLES:
black screen appears on creation of new window.
 Black screen appears in efl (Enlightenment) eglSwapBuffers function.
 Further investigation in progress. 

*Next steps* :
** Work on Tizen X11
*** Continue work on Enlightenment with PVR OpenGL issue.


> Support for MIPS platform
> -
>
> Key: TS-2687
> URL: https://issues.apache.org/jira/browse/TS-2687
> Project: Traffic Server
>  Issue Type: New Feature
>Reporter: Dejan Latinovic
>Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
> Attachments: mips-support.patch
>
>
> While trying to build trafficserver on mips architecture,
> build fails with an error:
> {code:borderStyle=solid}
> In file included from ../../lib/ts/libts.h:64:0,
>  from P_EventSystem.h:34,
>  from EventSystem.cc:31:
> ../../lib/ts/ink_queue.h:144:2: error: #error "unsupported processor"
>  #error "unsupported processor"
> {code}



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

[jira] [Commented] (TS-4070) RemapProcessor Forward Mapping with Recv Port failing with TS-2157 changes

2015-12-14 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on TS-4070:


GitHub user cschombu opened a pull request:

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

TS-4070 RemapProcessor Forward Mapping with Recv Port failing with TS…

…-2157 changes

During the rework of RemapProcessor.cc, RemapProcessor::setup_for_remap()
as part of the TS-2157 changeset, the port access API appears to have been
incorrectly modified to use the client_info.src_addr.host_order_port() API
[source port, host order] instead of the client_info.dst_addr.port()
[destination/receive port, network order] API. This caused port based
remapping based on the receive port to fail with ATS 6.0.0.

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

$ git pull https://github.com/cschombu/trafficserver TS-4070

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

https://github.com/apache/trafficserver/pull/375.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 #375


commit 83851dc1ee5f147024cca3f5129a1d266f273ecd
Author: Craig Schomburg 
Date:   2015-12-14T18:53:19Z

TS-4070 RemapProcessor Forward Mapping with Recv Port failing with TS-2157 
changes

During the rework of RemapProcessor.cc, RemapProcessor::setup_for_remap()
as part of the TS-2157 changeset, the port access API appears to have been
incorrectly modified to use the client_info.src_addr.host_order_port() API
[source port, host order] instead of the client_info.dst_addr.port()
[destination/receive port, network order] API. This caused port based
remapping based on the receive port to fail with ATS 6.0.0.




> RemapProcessor Forward Mapping with Recv Port failing with TS-2157 changes
> --
>
> Key: TS-4070
> URL: https://issues.apache.org/jira/browse/TS-4070
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Craig Schomburg
>Priority: Critical
>  Labels: regression
> Fix For: 6.1.0
>
> Attachments: TS-4070.patch
>
>
> During the rework of RemapProcessor.cc, RemapProcessor::setup_for_remap() as 
> part of the TS-2157 changeset, the port access API appears to have been 
> incorrectly modified to use the client_info.src_addr.host_order_port() API 
> [source port, host order] instead of the client_info.dst_addr.port() 
> [destination/receive port, network 
> order] API.  This caused port based remapping based on the receive port to 
> fail with ATS 6.0.0.
> Functionality was previously working with ATS 4.0.1.
> See attached patch that was used to restore the ATS 4.0.1 functionality.
> Looking for confirmation that this fix/patch was correct.



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