[jira] [Created] (TS-3104) traffic_cop can't restart traffic_manager properly

2014-10-01 Thread Victor (JIRA) 
Victor created TS-3104:
--

 Summary: traffic_cop can't restart traffic_manager properly
 Key: TS-3104
 URL: https://issues.apache.org/jira/browse/TS-3104
 Project: Traffic Server
  Issue Type: Bug
  Components: Cop
Reporter: Victor


In some cases traffic_cop can't restart traffic_manager properly. We met these 
issues at Ashmanov and partners (http://en.ashmanov.com/). There are two 
places in code which in my opinion need corrections:

1) The logic which decides whether to kill process or group.

2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
failure and this fact leads to constant attempts to connect to manager using 
socket id == -1. 

I have prepared patches for both issues. Please kindly take a look at them and 
let me know your thoughts.


diff --git lib/ts/lockfile.cc lib/ts/lockfile.cc
index f6e9587..dbd7394 100644
--- lib/ts/lockfile.cc
+++ lib/ts/lockfile.cc
@@ -241,6 +241,7 @@ Lockfile::KillGroup(int sig, int initial_sig, const char 
*pname)
   int err;
   pid_t pid;
   pid_t holding_pid;
+  pid_t self = getpid();
 
   err = Open(holding_pid);
   if (err == 1) // success getting the lock file
@@ -252,12 +253,20 @@ Lockfile::KillGroup(int sig, int initial_sig, const char 
*pname)
   pid = getpgid(holding_pid);
 } while ((pid  0)  (errno == EINTR));
 
-if ((pid  0) || (pid == getpid()))
+if ((pid  0) || (pid == self)) {
+  // Error getting process group,
+  // or we are the group's owner.
+  // Let's kill just holding_pid
   pid = holding_pid;
-
-if (pid != 0) {
+}
+else if (pid != self) {
+  // We managed to get holding_pid's process group
+  // and this group is not ours.
   // This way, we kill the process_group:
   pid = -pid;
+}
+
+if (pid != 0) {
   // In order to get core files from each process, please
   // set your core_pattern appropriately.
   lockfile_kill_internal(holding_pid, initial_sig, pid, pname, sig);




 diff --git cop/TrafficCop.cc cop/TrafficCop.cc
index 307270e..56bc6d2 100644
--- cop/TrafficCop.cc
+++ cop/TrafficCop.cc
@@ -59,6 +59,7 @@ static const char COP_TRACE_FILE[] = /tmp/traffic_cop.trace;
 
 #define COP_FATALLOG_ALERT
 #define COP_WARNING  LOG_ERR
+#define COP_INFO LOG_INFO
 #define COP_DEBUGLOG_DEBUG
 
 Diags * g_diags; // link time dependency
@@ -131,6 +132,9 @@ static int child_pid = 0;
 static int child_status = 0;
 static int sem_id = 11452;
 
+// manager API is initialized
+static bool mgmt_init = false;
+
 AppVersionInfo appVersionInfo;
 
 static char const localhost[] = 127.0.0.1;
@@ -1142,6 +1146,7 @@ test_mgmt_cli_port()
 
   if (TSRecordGetString(proxy.config.manager_binary, val) !=  TS_ERR_OKAY) {
 cop_log(COP_WARNING, (cli test) unable to retrieve manager_binary\n);
+mgmt_init = false; 
 ret = -1;
   } else {
 if (strcmp(val, manager_binary) != 0) {
@@ -1544,7 +1549,6 @@ check_no_run()
 static void*
 check(void *arg)
 {
-  bool mgmt_init = false;
   cop_log_trace(Entering check()\n);
 
   for (;;) {
@@ -1593,6 +1597,7 @@ check(void *arg)
 
 // We do this after the first round of checks, since the first check 
will spawn traffic_manager
 if (!mgmt_init) {
+  cop_log(COP_INFO, Initializing manager API\n);
   TSInit(Layout::get()-runtimedir, 
static_castTSInitOptionT(TS_MGMT_OPT_NO_EVENTS | TS_MGMT_OPT_NO_SOCK_TESTS));
   mgmt_init = true;
 }




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

[jira] [Updated] (TS-3104) traffic_cop can't restart traffic_manager properly

2014-10-01 Thread Victor (JIRA) 

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

Victor updated TS-3104:
---
Attachment: ts-0023-cop-reinit-mgr-api-on-failure.patch
ts-0022-fix-lockfile-killgroup.patch

Patches for described issues.

 traffic_cop can't restart traffic_manager properly
 --

 Key: TS-3104
 URL: https://issues.apache.org/jira/browse/TS-3104
 Project: Traffic Server
  Issue Type: Bug
  Components: Cop
Reporter: Victor
 Attachments: ts-0022-fix-lockfile-killgroup.patch, 
 ts-0023-cop-reinit-mgr-api-on-failure.patch


 In some cases traffic_cop can't restart traffic_manager properly. We met 
 these issues at Ashmanov and partners (http://en.ashmanov.com/). There are 
 two places in code which in my opinion need corrections:
 1) The logic which decides whether to kill process or group.
 2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
 failure and this fact leads to constant attempts to connect to manager using 
 socket id == -1. 
 I have prepared patches for both issues. Please kindly take a look at them 
 and let me know your thoughts.
 diff --git lib/ts/lockfile.cc lib/ts/lockfile.cc
 index f6e9587..dbd7394 100644
 --- lib/ts/lockfile.cc
 +++ lib/ts/lockfile.cc
 @@ -241,6 +241,7 @@ Lockfile::KillGroup(int sig, int initial_sig, const char 
 *pname)
int err;
pid_t pid;
pid_t holding_pid;
 +  pid_t self = getpid();
  
err = Open(holding_pid);
if (err == 1) // success getting the lock file
 @@ -252,12 +253,20 @@ Lockfile::KillGroup(int sig, int initial_sig, const 
 char *pname)
pid = getpgid(holding_pid);
  } while ((pid  0)  (errno == EINTR));
  
 -if ((pid  0) || (pid == getpid()))
 +if ((pid  0) || (pid == self)) {
 +  // Error getting process group,
 +  // or we are the group's owner.
 +  // Let's kill just holding_pid
pid = holding_pid;
 -
 -if (pid != 0) {
 +}
 +else if (pid != self) {
 +  // We managed to get holding_pid's process group
 +  // and this group is not ours.
// This way, we kill the process_group:
pid = -pid;
 +}
 +
 +if (pid != 0) {
// In order to get core files from each process, please
// set your core_pattern appropriately.
lockfile_kill_internal(holding_pid, initial_sig, pid, pname, sig);
  diff --git cop/TrafficCop.cc cop/TrafficCop.cc
 index 307270e..56bc6d2 100644
 --- cop/TrafficCop.cc
 +++ cop/TrafficCop.cc
 @@ -59,6 +59,7 @@ static const char COP_TRACE_FILE[] = 
 /tmp/traffic_cop.trace;
  
  #define COP_FATALLOG_ALERT
  #define COP_WARNING  LOG_ERR
 +#define COP_INFO LOG_INFO
  #define COP_DEBUGLOG_DEBUG
  
  Diags * g_diags; // link time dependency
 @@ -131,6 +132,9 @@ static int child_pid = 0;
  static int child_status = 0;
  static int sem_id = 11452;
  
 +// manager API is initialized
 +static bool mgmt_init = false;
 +
  AppVersionInfo appVersionInfo;
  
  static char const localhost[] = 127.0.0.1;
 @@ -1142,6 +1146,7 @@ test_mgmt_cli_port()
  
if (TSRecordGetString(proxy.config.manager_binary, val) !=  
 TS_ERR_OKAY) {
  cop_log(COP_WARNING, (cli test) unable to retrieve manager_binary\n);
 +mgmt_init = false; 
  ret = -1;
} else {
  if (strcmp(val, manager_binary) != 0) {
 @@ -1544,7 +1549,6 @@ check_no_run()
  static void*
  check(void *arg)
  {
 -  bool mgmt_init = false;
cop_log_trace(Entering check()\n);
  
for (;;) {
 @@ -1593,6 +1597,7 @@ check(void *arg)
  
  // We do this after the first round of checks, since the first check 
 will spawn traffic_manager
  if (!mgmt_init) {
 +  cop_log(COP_INFO, Initializing manager API\n);
TSInit(Layout::get()-runtimedir, 
 static_castTSInitOptionT(TS_MGMT_OPT_NO_EVENTS | 
 TS_MGMT_OPT_NO_SOCK_TESTS));
mgmt_init = true;
  }



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

[jira] [Updated] (TS-3104) traffic_cop can't restart traffic_manager properly

2014-10-01 Thread Victor (JIRA) 

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

Victor updated TS-3104:
---
Description: 
In some cases traffic_cop can't restart traffic_manager properly. We met these 
issues at Ashmanov and partners (http://en.ashmanov.com/). There are two 
places in code which in my opinion need corrections:

1) The logic which decides whether to kill process or group.

2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
failure and this fact leads to constant attempts to connect to manager using 
socket id == -1. 

I have prepared patches for both issues. Please kindly take a look at them and 
let me know your thoughts.


  was:
In some cases traffic_cop can't restart traffic_manager properly. We met these 
issues at Ashmanov and partners (http://en.ashmanov.com/). There are two 
places in code which in my opinion need corrections:

1) The logic which decides whether to kill process or group.

2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
failure and this fact leads to constant attempts to connect to manager using 
socket id == -1. 

I have prepared patches for both issues. Please kindly take a look at them and 
let me know your thoughts.


diff --git lib/ts/lockfile.cc lib/ts/lockfile.cc
index f6e9587..dbd7394 100644
--- lib/ts/lockfile.cc
+++ lib/ts/lockfile.cc
@@ -241,6 +241,7 @@ Lockfile::KillGroup(int sig, int initial_sig, const char 
*pname)
   int err;
   pid_t pid;
   pid_t holding_pid;
+  pid_t self = getpid();
 
   err = Open(holding_pid);
   if (err == 1) // success getting the lock file
@@ -252,12 +253,20 @@ Lockfile::KillGroup(int sig, int initial_sig, const char 
*pname)
   pid = getpgid(holding_pid);
 } while ((pid  0)  (errno == EINTR));
 
-if ((pid  0) || (pid == getpid()))
+if ((pid  0) || (pid == self)) {
+  // Error getting process group,
+  // or we are the group's owner.
+  // Let's kill just holding_pid
   pid = holding_pid;
-
-if (pid != 0) {
+}
+else if (pid != self) {
+  // We managed to get holding_pid's process group
+  // and this group is not ours.
   // This way, we kill the process_group:
   pid = -pid;
+}
+
+if (pid != 0) {
   // In order to get core files from each process, please
   // set your core_pattern appropriately.
   lockfile_kill_internal(holding_pid, initial_sig, pid, pname, sig);




 diff --git cop/TrafficCop.cc cop/TrafficCop.cc
index 307270e..56bc6d2 100644
--- cop/TrafficCop.cc
+++ cop/TrafficCop.cc
@@ -59,6 +59,7 @@ static const char COP_TRACE_FILE[] = /tmp/traffic_cop.trace;
 
 #define COP_FATALLOG_ALERT
 #define COP_WARNING  LOG_ERR
+#define COP_INFO LOG_INFO
 #define COP_DEBUGLOG_DEBUG
 
 Diags * g_diags; // link time dependency
@@ -131,6 +132,9 @@ static int child_pid = 0;
 static int child_status = 0;
 static int sem_id = 11452;
 
+// manager API is initialized
+static bool mgmt_init = false;
+
 AppVersionInfo appVersionInfo;
 
 static char const localhost[] = 127.0.0.1;
@@ -1142,6 +1146,7 @@ test_mgmt_cli_port()
 
   if (TSRecordGetString(proxy.config.manager_binary, val) !=  TS_ERR_OKAY) {
 cop_log(COP_WARNING, (cli test) unable to retrieve manager_binary\n);
+mgmt_init = false; 
 ret = -1;
   } else {
 if (strcmp(val, manager_binary) != 0) {
@@ -1544,7 +1549,6 @@ check_no_run()
 static void*
 check(void *arg)
 {
-  bool mgmt_init = false;
   cop_log_trace(Entering check()\n);
 
   for (;;) {
@@ -1593,6 +1597,7 @@ check(void *arg)
 
 // We do this after the first round of checks, since the first check 
will spawn traffic_manager
 if (!mgmt_init) {
+  cop_log(COP_INFO, Initializing manager API\n);
   TSInit(Layout::get()-runtimedir, 
static_castTSInitOptionT(TS_MGMT_OPT_NO_EVENTS | TS_MGMT_OPT_NO_SOCK_TESTS));
   mgmt_init = true;
 }



 traffic_cop can't restart traffic_manager properly
 --

 Key: TS-3104
 URL: https://issues.apache.org/jira/browse/TS-3104
 Project: Traffic Server
  Issue Type: Bug
  Components: Cop
Reporter: Victor
 Attachments: ts-0022-fix-lockfile-killgroup.patch, 
 ts-0023-cop-reinit-mgr-api-on-failure.patch


 In some cases traffic_cop can't restart traffic_manager properly. We met 
 these issues at Ashmanov and partners (http://en.ashmanov.com/). There are 
 two places in code which in my opinion need corrections:
 1) The logic which decides whether to kill process or group.
 2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
 failure and this fact leads to constant attempts to connect to manager using 
 socket id == -1. 
 I have prepared patches for both issues. Please kindly take a look at them 
 and let me know your thoughts.



--
This message was sent by Atlassian JIRA

[jira] [Commented] (TS-3104) traffic_cop can't restart traffic_manager properly

2014-10-01 Thread Victor (JIRA) 

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

Victor commented on TS-3104:


Whe the issue was reproduced one could see it in syslog (journalctl): numerous 
messages unable to retrieve manager_binary. After applying the attached 
patches the issue was gone, the processes were restarted correctly by 
traffic_cop. The following tests were made:


* kill `pgrep traffic_manager`
* kill -9 `pgrep traffic_manager`
* kill `pgrep traffic_server`
* kill -9 `pgrep traffic_server`
* kill `pgrep traffic_manager`; kill `pgrep traffic_server`
* kill -9 `pgrep traffic_manager`; kill -9 `pgrep traffic_server`


In all cases both manager and traffic_server were restarted correctly, no 
endless loop of traffic_cop trying to restart manager was seen.

 traffic_cop can't restart traffic_manager properly
 --

 Key: TS-3104
 URL: https://issues.apache.org/jira/browse/TS-3104
 Project: Traffic Server
  Issue Type: Bug
  Components: Cop
Reporter: Victor
 Attachments: ts-0022-fix-lockfile-killgroup.patch, 
 ts-0023-cop-reinit-mgr-api-on-failure.patch


 In some cases traffic_cop can't restart traffic_manager properly. We met 
 these issues at Ashmanov and partners (http://en.ashmanov.com/). There are 
 two places in code which in my opinion need corrections:
 1) The logic which decides whether to kill process or group.
 2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
 failure and this fact leads to constant attempts to connect to manager using 
 socket id == -1. 
 I have prepared patches for both issues. Please kindly take a look at them 
 and let me know your thoughts.



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

[jira] [Comment Edited] (TS-3104) traffic_cop can't restart traffic_manager properly

2014-10-01 Thread Victor (JIRA) 

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

Victor edited comment on TS-3104 at 10/1/14 12:21 PM:
--

When the issue was reproduced one could see it in syslog (journalctl): numerous 
messages unable to retrieve manager_binary. After applying the attached 
patches the issue was gone, the processes were restarted correctly by 
traffic_cop. The following tests were made:


* kill `pgrep traffic_manager`
* kill -9 `pgrep traffic_manager`
* kill `pgrep traffic_server`
* kill -9 `pgrep traffic_server`
* kill `pgrep traffic_manager`; kill `pgrep traffic_server`
* kill -9 `pgrep traffic_manager`; kill -9 `pgrep traffic_server`


In all cases both manager and traffic_server were restarted correctly, no 
endless loop of traffic_cop trying to restart manager was seen.


was (Author: vleschuk):
Whe the issue was reproduced one could see it in syslog (journalctl): numerous 
messages unable to retrieve manager_binary. After applying the attached 
patches the issue was gone, the processes were restarted correctly by 
traffic_cop. The following tests were made:


* kill `pgrep traffic_manager`
* kill -9 `pgrep traffic_manager`
* kill `pgrep traffic_server`
* kill -9 `pgrep traffic_server`
* kill `pgrep traffic_manager`; kill `pgrep traffic_server`
* kill -9 `pgrep traffic_manager`; kill -9 `pgrep traffic_server`


In all cases both manager and traffic_server were restarted correctly, no 
endless loop of traffic_cop trying to restart manager was seen.

 traffic_cop can't restart traffic_manager properly
 --

 Key: TS-3104
 URL: https://issues.apache.org/jira/browse/TS-3104
 Project: Traffic Server
  Issue Type: Bug
  Components: Cop
Reporter: Victor
 Attachments: ts-0022-fix-lockfile-killgroup.patch, 
 ts-0023-cop-reinit-mgr-api-on-failure.patch


 In some cases traffic_cop can't restart traffic_manager properly. We met 
 these issues at Ashmanov and partners (http://en.ashmanov.com/). There are 
 two places in code which in my opinion need corrections:
 1) The logic which decides whether to kill process or group.
 2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
 failure and this fact leads to constant attempts to connect to manager using 
 socket id == -1. 
 I have prepared patches for both issues. Please kindly take a look at them 
 and let me know your thoughts.



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

[jira] [Updated] (TS-3104) traffic_cop can't restart traffic_manager properly

2014-10-01 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom updated TS-3104:
--
Fix Version/s: 5.2.0

 traffic_cop can't restart traffic_manager properly
 --

 Key: TS-3104
 URL: https://issues.apache.org/jira/browse/TS-3104
 Project: Traffic Server
  Issue Type: Bug
  Components: Cop
Reporter: Victor
 Fix For: 5.2.0

 Attachments: ts-0022-fix-lockfile-killgroup.patch, 
 ts-0023-cop-reinit-mgr-api-on-failure.patch


 In some cases traffic_cop can't restart traffic_manager properly. We met 
 these issues at Ashmanov and partners (http://en.ashmanov.com/). There are 
 two places in code which in my opinion need corrections:
 1) The logic which decides whether to kill process or group.
 2) The main traffic_cop loop: it doesn't reinitialize manager API in case of 
 failure and this fact leads to constant attempts to connect to manager using 
 socket id == -1. 
 I have prepared patches for both issues. Please kindly take a look at them 
 and let me know your thoughts.



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

[jira] [Commented] (TS-3044) linux native AIO should use eventfd if available to signal thread

2014-10-01 Thread Phil Sorber (JIRA) 

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

Phil Sorber commented on TS-3044:
-

Ok, you've convinced me. I am +1 on this patch. If you want to commit this as 
is, I will fix the perror() in the AIO_MODE_NATIVE code.

 linux native AIO should use eventfd if available to signal thread
 -

 Key: TS-3044
 URL: https://issues.apache.org/jira/browse/TS-3044
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cache
Reporter: John Plevyak
Assignee: Phil Sorber
 Fix For: 5.2.0

 Attachments: native-aio-eventfd.patch


 linux native AIO has the ability to signal the event thread to get off the 
 poll and service the disk via the io_set_eventfd() call.  linux native AIO 
 scales better than the thread-based IO, but the current implementation can 
 introduce delays on lightly loaded systems because of the thread is waiting 
 on epoll().   This can be remedied by using io_set_eventfd



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

[jira] [Created] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond

2014-10-01 Thread Susan Hinrichs (JIRA) 
Susan Hinrichs created TS-3105:
--

 Summary: Combination of fixes for TS-3084 and TS-3073 causing 
asserts and segfaults on 5.1 and beyond
 Key: TS-3105
 URL: https://issues.apache.org/jira/browse/TS-3105
 Project: Traffic Server
  Issue Type: Bug
Reporter: Susan Hinrichs


These two patches were run in a production environment on top of 5.0.1 without 
problem for several weeks.  Now running with these patches on top of 5.1 causes 
either an assert or a segfault.  Another person has reported the same segfault 
when running master in a production environment.

In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than a 
terminal state which is expected.  I'm assuming either we are being directed 
into the terminal state from a connection that terminates too quickly.  Or an 
event has hung around for too long and is being executed against the state 
machine after it has been recycled.

The event is HTTP_TUNNEL_EVENT_DONE

The assert stack trace is
FATAL: HttpSM.cc:2632: failed assert `0`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197]
/z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef]
/z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad]
/z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18]
/z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae]
/z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, 
EThread*)+0x136e)[0x721d1e]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1]
/z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac]
/z/bin/traffic_server[0x7440ca]
/lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034]
/lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d]

The segfault stack trace is 
/z/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280]
/z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, 
HttpTunnelConsumer*)+0x122)[0x591462]
/z/bin/traffic_server(HttpTunnel::consumer_handler(int, 
HttpTunnelConsumer*)+0x9e)[0x5dd15e]
/z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7]
/z/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
Event*)+0x3f0)[0x725190]
/z/bin/traffic_server(InactivityCop::check_inactivity(int, 
Event*)+0x275)[0x716b75]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab]
/z/bin/traffic_server[0x7440ca]
/lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034]
/lib64/libc.so.6(clone+0x6d)[0x2abccde1475d]



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

[jira] [Updated] (TS-3068) Remove usage of Boost in header_rewrite

2014-10-01 Thread Phil Sorber (JIRA) 

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

Phil Sorber updated TS-3068:

Attachment: TS-3068.patch

 Remove usage of Boost in header_rewrite
 ---

 Key: TS-3068
 URL: https://issues.apache.org/jira/browse/TS-3068
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: Phil Sorber
Assignee: Phil Sorber
 Fix For: 5.2.0

 Attachments: TS-3068.patch


 Remove usage of Boost in header_rewrite that is not already covered by 
 TS-2231.



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

[jira] [Created] (TS-3106) ATS error responses do not flush request body

2014-10-01 Thread Thomas Jackson (JIRA) 
Thomas Jackson created TS-3106:
--

 Summary: ATS error responses do not flush request body
 Key: TS-3106
 URL: https://issues.apache.org/jira/browse/TS-3106
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson


If you send a request to ATS which causes an error page (no remap, blocked HTTP 
method, etc.) with a body, the following request will get a 403 response. This 
is due to ATS not flushing the request body of the first (failed) request. If 
you look in the logs for the second request you will see the URL as POSBODY 
GET / (or something similar). I can easily reproduce this on ATS 5.



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

[jira] [Assigned] (TS-3106) ATS error responses do not flush request body

2014-10-01 Thread Brian Geffon (JIRA) 

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

Brian Geffon reassigned TS-3106:


Assignee: Brian Geffon

 ATS error responses do not flush request body
 -

 Key: TS-3106
 URL: https://issues.apache.org/jira/browse/TS-3106
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson
Assignee: Brian Geffon

 If you send a request to ATS which causes an error page (no remap, blocked 
 HTTP method, etc.) with a body, the following request will get a 403 
 response. This is due to ATS not flushing the request body of the first 
 (failed) request. If you look in the logs for the second request you will see 
 the URL as POSBODY GET / (or something similar). I can easily reproduce 
 this on ATS 5.



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

[jira] [Commented] (TS-3106) ATS error responses do not flush request body

2014-10-01 Thread Brian Geffon (JIRA) 

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

Brian Geffon commented on TS-3106:
--

I'm working with [~jacksontj] on a fix for this.

 ATS error responses do not flush request body
 -

 Key: TS-3106
 URL: https://issues.apache.org/jira/browse/TS-3106
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson
Assignee: Brian Geffon

 If you send a request to ATS which causes an error page (no remap, blocked 
 HTTP method, etc.) with a body, the following request will get a 403 
 response. This is due to ATS not flushing the request body of the first 
 (failed) request. If you look in the logs for the second request you will see 
 the URL as POSBODY GET / (or something similar). I can easily reproduce 
 this on ATS 5.



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