date:20120202


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

Igor Galić updated TS-1038:
---

Backport to Version: 3.0.3

 TSHttpTxnErrorBodySet() can leak memory (pt 2)
 --

 Key: TS-1038
 URL: https://issues.apache.org/jira/browse/TS-1038
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Brian Geffon
Assignee: Igor Galić
 Fix For: 3.1.2

 Attachments: TSHttpTxnErrorBodySet.patch


 TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that 
 mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 
 which frees internal_msg_buffer_type...it's expected that mimetype was 
 malloced since clearly it's being freed. So that means there is still a 
 memory leak in TSHttpTxnErrorBodySet().
 Patch included.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)


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

Igor Galić reassigned TS-1038:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

 TSHttpTxnErrorBodySet() can leak memory (pt 2)
 --

 Key: TS-1038
 URL: https://issues.apache.org/jira/browse/TS-1038
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Brian Geffon
Assignee: Igor Galić
 Fix For: 3.1.2

 Attachments: TSHttpTxnErrorBodySet.patch


 TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that 
 mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 
 which frees internal_msg_buffer_type...it's expected that mimetype was 
 malloced since clearly it's being freed. So that means there is still a 
 memory leak in TSHttpTxnErrorBodySet().
 Patch included.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed a


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

Igor Galić reassigned TS-1061:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

 TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter 
 (int *bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter 
 needs to be removed as it is not used.
 -

 Key: TS-1061
 URL: https://issues.apache.org/jira/browse/TS-1061
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 3.1.1, 3.0.1
 Environment: Redhat Linux but it is not environment specific
Reporter: Alistair Stevenson
Assignee: Igor Galić
Priority: Minor
  Labels: api-change
 Fix For: 3.1.2

   Original Estimate: 1h
  Remaining Estimate: 1h

 The definitions are:
 ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
 ./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
 txnp);
 The int * bytes parameter is not used and means that the function does not 
 resolve and so cannot be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as


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

Igor Galić updated TS-1061:
---

Backport to Version: 3.0.3

 TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter 
 (int *bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter 
 needs to be removed as it is not used.
 -

 Key: TS-1061
 URL: https://issues.apache.org/jira/browse/TS-1061
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 3.1.1, 3.0.1
 Environment: Redhat Linux but it is not environment specific
Reporter: Alistair Stevenson
Assignee: Igor Galić
Priority: Minor
  Labels: api-change
 Fix For: 3.1.2

   Original Estimate: 1h
  Remaining Estimate: 1h

 The definitions are:
 ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
 ./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
 txnp);
 The int * bytes parameter is not used and means that the function does not 
 resolve and so cannot be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1049) TS hangs (dead lock) on HTTPS POST requests

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

Igor Galić updated TS-1049:
---

Backport to Version: 3.0.3

TS hangs (dead lock) on HTTPS POST requests
---

Key: TS-1049
URL: https://issues.apache.org/jira/browse/TS-1049
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, SSL
Affects Versions: 3.1.1, 3.1.0, 3.0.2
Environment: RedHat Enterprise Linux 6.0, Intel 32-bit
Reporter: Wilson Ho
Assignee: Leif Hedstrom
Priority: Blocker
Fix For: 3.1.2

Attachments: records.config

A very reproducible bug where the body of a HTTPS POST request is never
forwarded to the origin server.
Client submits a HTTPS POST request to TS, which is supposed to forward to
the backend/origin server via HTTP. TS process the HTTP headers and
establishes connection to the origin server, but the body of the HTTPS POST
is never read. This hangs until the client times out and shuts down the
connection.
To reproduce:
1) Client connects to TS using HTTPS (works OK if it is just HTTP).
2) It must be a POST request.
3) TS must use at least 2 worker threads.
4) Easier to reproduce when the connections to the origin server is HTTP (not
HTTPS).
5) POST body must be large enough so that the HTTP request headers and POST
body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
6) I can consistently reproduce this problem using 2 separate clients each
simultaneously submitting 2 requests back to back (i.e., 2 requests from each
client, a total of 4 requests). This gives you a high probability that at
least one of the requests would hang.
Observation:
1) Thread A accepted and processed the HTTP headers, and called
UnixNetProcessor::connect_re to prepare a new connection to the origin
server.
2) Thread A must not have read the body of the POST. Otherwise, it works
fine.
3) Thread B was assigned the task to handle the origin server connection. If
the same thread A was picked, then everything works fine.
4) Apparently, one of the first things that thread B does is to acquire the
mutex for reading from the client. (Why does it do that??)
5) While thread B was holding the mutex, thread A proceeded in
SSLNetVConnection::net_read_io, tried and failed to acquire the mutex.
Thread A typically re-tried calling SSLNetVConnection::net_read_io soon,
but gave up after the second failure. But if thread B released the mutex soon
enough, that thread A could proceed happily and everything works.
6) From this point, the body of the POST is never read from the client, and
there is nothing to be proxy'd to the origin server, and both the consumer
and producer tasks are never scheduled to run again -- or until the client
times out. I tried setting the client-side time out to as long as 3-5
minutes and TS really does not recover by itself until the client closed the
connection.
This is the first time I uses this bug system. Please let me know how I
could produce the configuration files and trace logs, etc. Thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1049) TS hangs (dead lock) on HTTPS POST requests

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

Igor Galić updated TS-1049:
---

Description:
A very reproducible bug where the body of a HTTPS POST request is never
forwarded to the origin server.

Client submits a HTTPS POST request to TS, which is supposed to forward to the
backend/origin server via HTTP. TS process the HTTP headers and establishes
connection to the origin server, but the body of the HTTPS POST is never read.
This hangs until the client times out and shuts down the connection.

To reproduce:
# Client connects to TS using HTTPS (works OK if it is just HTTP).
# It must be a POST request.
# TS must use at least 2 worker threads.
# Easier to reproduce when the connections to the origin server is HTTP (not
HTTPS).
# POST body must be large enough so that the HTTP request headers and POST body
do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
# I can consistently reproduce this problem using 2 separate clients each
simultaneously submitting 2 requests back to back (i.e., 2 requests from each
client, a total of 4 requests). This gives you a high probability that at
least one of the requests would hang.

Observation:
# Thread A accepted and processed the HTTP headers, and called
UnixNetProcessor::connect_re to prepare a new connection to the origin server.
# Thread A must not have read the body of the POST. Otherwise, it works fine.
# Thread B was assigned the task to handle the origin server connection. If
the same thread A was picked, then everything works fine.
# Apparently, one of the first things that thread B does is to acquire the
mutex for reading from the client. (Why does it do that??)
# While thread B was holding the mutex, thread A proceeded in
SSLNetVConnection::net_read_io, tried and failed to acquire the mutex.
Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, but
gave up after the second failure. But if thread B released the mutex soon
enough, that thread A could proceed happily and everything works.
# From this point, the body of the POST is never read from the client, and
there is nothing to be proxy'd to the origin server, and both the consumer and
producer tasks are never scheduled to run again -- or until the client times
out. I tried setting the client-side time out to as long as 3-5 minutes and TS
really does not recover by itself until the client closed the connection.

This is the first time I uses this bug system. Please let me know how I could
produce the configuration files and trace logs, etc. Thanks!

was:
A very reproducible bug where the body of a HTTPS POST request is never
forwarded to the origin server.

To reproduce:
1) Client connects to TS using HTTPS (works OK if it is just HTTP).
2) It must be a POST request.
3) TS must use at least 2 worker threads.
4) Easier to reproduce when the connections to the origin server is HTTP (not
HTTPS).
5) POST body must be large enough so that the HTTP request headers and POST
body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
6) I can consistently reproduce this problem using 2 separate clients each
simultaneously submitting 2 requests back to back (i.e., 2 requests from each
client, a total of 4 requests). This gives you a high probability that at
least one of the requests would hang.

Observation:
1) Thread A accepted and processed the HTTP headers, and called
UnixNetProcessor::connect_re to prepare a new connection to the origin server.
2) Thread A must not have read the body of the POST. Otherwise, it works fine.
3) Thread B was assigned the task to handle the origin server connection. If
the same thread A was picked, then everything works fine.
4) Apparently, one of the first things that thread B does is to acquire the
mutex for reading from the client. (Why does it do that??)
5) While thread B was holding the mutex, thread A proceeded in
SSLNetVConnection::net_read_io, tried and failed to acquire the mutex.
Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, but
gave up after the second failure. But if thread B released the mutex soon
enough, that thread A could proceed happily and everything works.
6) From this point, the body of the POST is never read from the client, and
there is nothing to be proxy'd to the origin server, and both the consumer and
producer tasks are never scheduled to run again -- or until the client times
out. I tried setting the client-side time out to as long as 3-5 minutes and TS
really does not recover by itself until the client closed the

[jira] [Updated] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP


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

Igor Galić updated TS-1065:
---

Backport to Version: 3.0.3

 traffic_cop segment fault when enable TRACE_LOG_COP
 ---

 Key: TS-1065
 URL: https://issues.apache.org/jira/browse/TS-1065
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.1.1, 3.0.2
 Environment: mac os 10.7.2, centos 5.4 64bit
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Minor
 Fix For: 3.1.2

 Attachments: traffic_cop.diff


 When enable traffic_cop's debug log:  #define TRACE_LOG_COP 1 
 Some cop_log invocation will cause segment fault, because va_list object in 
 cop_log is used twice between 'va_start' and 'va_end'.
 {code}
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x
 0x7fff846b64f0 in strlen ()
 (gdb) bt
 #0  0x7fff846b64f0 in strlen ()
 #1  0x7fff846578c3 in __vfprintf ()
 #2  0x7fff846a109b in vsprintf_l ()
 #3  0x00011883 in cop_log (priority=5, format=0x172a8 --- Cop 
 Starting [Version: %s] ---\n) at TrafficCop.cc:172
 #4  0x00012244 in check_lockfile () at TrafficCop.cc:1733
 #5  0x000122c0 in init () at TrafficCop.cc:1894
 #6  0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at 
 TrafficCop.cc:1958
 {code}
 Reference:
 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1055) Wrong implementation of TSHttpSsnArgGet


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

Igor Galić updated TS-1055:
---

Backport to Version: 3.0.3

 Wrong implementation of TSHttpSsnArgGet
 ---

 Key: TS-1055
 URL: https://issues.apache.org/jira/browse/TS-1055
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Assignee: Leif Hedstrom
  Labels: api-change
 Fix For: 3.1.2

   Original Estimate: 24h
  Remaining Estimate: 24h

 There is a different between the interface of TSHttpSsnArgGet and it 
 implemenation.
 In the interface (proxy/api/ts/ts.h.in):
  tsapi void* TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx);
 In the implementation(proxy/InkAPI.cc):
   void * TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
 So, I wrote a simple patch to fix this problem:
 Index: InkAPI.cc
 ===
 --- InkAPI.cc   (revision 1220421)
 +++ InkAPI.cc   (working copy)
 @@ -5500,7 +5500,7 @@
  }
  void *
 -TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
 +TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx)
  {
sdk_assert(sdk_sanity_check_http_ssn(ssnp) == TS_SUCCESS);
sdk_assert(arg_idx = 0  arg_idx  HTTP_SSN_TXN_MAX_USER_ARG);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1055) Wrong implementation of TSHttpSsnArgGet


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

Igor Galić reassigned TS-1055:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

 Wrong implementation of TSHttpSsnArgGet
 ---

 Key: TS-1055
 URL: https://issues.apache.org/jira/browse/TS-1055
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Assignee: Igor Galić
  Labels: api-change
 Fix For: 3.1.2

   Original Estimate: 24h
  Remaining Estimate: 24h

 There is a different between the interface of TSHttpSsnArgGet and it 
 implemenation.
 In the interface (proxy/api/ts/ts.h.in):
  tsapi void* TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx);
 In the implementation(proxy/InkAPI.cc):
   void * TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
 So, I wrote a simple patch to fix this problem:
 Index: InkAPI.cc
 ===
 --- InkAPI.cc   (revision 1220421)
 +++ InkAPI.cc   (working copy)
 @@ -5500,7 +5500,7 @@
  }
  void *
 -TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
 +TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx)
  {
sdk_assert(sdk_sanity_check_http_ssn(ssnp) == TS_SUCCESS);
sdk_assert(arg_idx = 0  arg_idx  HTTP_SSN_TXN_MAX_USER_ARG);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP


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

Igor Galić reassigned TS-1065:
--

Assignee: Igor Galić  (was: Leif Hedstrom)

 traffic_cop segment fault when enable TRACE_LOG_COP
 ---

 Key: TS-1065
 URL: https://issues.apache.org/jira/browse/TS-1065
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.1.1, 3.0.2
 Environment: mac os 10.7.2, centos 5.4 64bit
Reporter: Conan Wang
Assignee: Igor Galić
Priority: Minor
 Fix For: 3.1.2

 Attachments: traffic_cop.diff


 When enable traffic_cop's debug log:  #define TRACE_LOG_COP 1 
 Some cop_log invocation will cause segment fault, because va_list object in 
 cop_log is used twice between 'va_start' and 'va_end'.
 {code}
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x
 0x7fff846b64f0 in strlen ()
 (gdb) bt
 #0  0x7fff846b64f0 in strlen ()
 #1  0x7fff846578c3 in __vfprintf ()
 #2  0x7fff846a109b in vsprintf_l ()
 #3  0x00011883 in cop_log (priority=5, format=0x172a8 --- Cop 
 Starting [Version: %s] ---\n) at TrafficCop.cc:172
 #4  0x00012244 in check_lockfile () at TrafficCop.cc:1733
 #5  0x000122c0 in init () at TrafficCop.cc:1894
 #6  0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at 
 TrafficCop.cc:1958
 {code}
 Reference:
 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP


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

Igor Galić reopened TS-1065:



reopen for backport

 traffic_cop segment fault when enable TRACE_LOG_COP
 ---

 Key: TS-1065
 URL: https://issues.apache.org/jira/browse/TS-1065
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.1.1, 3.0.2
 Environment: mac os 10.7.2, centos 5.4 64bit
Reporter: Conan Wang
Assignee: Igor Galić
Priority: Minor
 Fix For: 3.1.2

 Attachments: traffic_cop.diff


 When enable traffic_cop's debug log:  #define TRACE_LOG_COP 1 
 Some cop_log invocation will cause segment fault, because va_list object in 
 cop_log is used twice between 'va_start' and 'va_end'.
 {code}
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x
 0x7fff846b64f0 in strlen ()
 (gdb) bt
 #0  0x7fff846b64f0 in strlen ()
 #1  0x7fff846578c3 in __vfprintf ()
 #2  0x7fff846a109b in vsprintf_l ()
 #3  0x00011883 in cop_log (priority=5, format=0x172a8 --- Cop 
 Starting [Version: %s] ---\n) at TrafficCop.cc:172
 #4  0x00012244 in check_lockfile () at TrafficCop.cc:1733
 #5  0x000122c0 in init () at TrafficCop.cc:1894
 #6  0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at 
 TrafficCop.cc:1958
 {code}
 Reference:
 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.


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

Igor Galić reopened TS-1074:



reopen for backport

 PluginVC should schedule to the local queue instead of the external queue.
 --

 Key: TS-1074
 URL: https://issues.apache.org/jira/browse/TS-1074
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.1
Reporter: Brian Geffon
Assignee: Igor Galić
 Fix For: 3.1.2

 Attachments: PluginVC.patch


 In TS-867 a patch was introduced to resolve a crash that was appearing w/ 
 TSFetchURL, the patch would schedule events on the same thread if it is a net 
 thread, if not it will only then schedule with the event processor. If you're 
 scheduling on the same thread, wouldn't it be more efficient to place the 
 event directly on the local queue? It turns out that going to the 
 ExternalQueue under low load it would cause the event to become delayed. 
 Patch Attached.
 To best see the symptoms see complaints in (TS-912 and TS-1043). 
 I have verified that this patch fixes the 10ms symptom seen in TS-912 and 
 TS-1043.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.


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

Igor Galić reassigned TS-1074:
--

Assignee: Igor Galić  (was: Brian Geffon)

 PluginVC should schedule to the local queue instead of the external queue.
 --

 Key: TS-1074
 URL: https://issues.apache.org/jira/browse/TS-1074
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.1
Reporter: Brian Geffon
Assignee: Igor Galić
 Fix For: 3.1.2

 Attachments: PluginVC.patch


 In TS-867 a patch was introduced to resolve a crash that was appearing w/ 
 TSFetchURL, the patch would schedule events on the same thread if it is a net 
 thread, if not it will only then schedule with the event processor. If you're 
 scheduling on the same thread, wouldn't it be more efficient to place the 
 event directly on the local queue? It turns out that going to the 
 ExternalQueue under low load it would cause the event to become delayed. 
 Patch Attached.
 To best see the symptoms see complaints in (TS-912 and TS-1043). 
 I have verified that this patch fixes the 10ms symptom seen in TS-912 and 
 TS-1043.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1004) transformation plugins cause connection close when content length is not known ahead


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

Igor Galić reassigned TS-1004:
--

Assignee: Igor Galić  (was: Brian Geffon)

 transformation plugins cause connection close when content length is not 
 known ahead
 

 Key: TS-1004
 URL: https://issues.apache.org/jira/browse/TS-1004
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, Plugins
Affects Versions: 3.0.1
Reporter: Otto van der Schaaf
Assignee: Igor Galić
 Fix For: 3.1.1

 Attachments: chunk_transform_response.diff


 whenever the null transform plugin (or gzip) is executed, ATS will force the 
 ua connection closed. 
 when the user agent supports it, sending a chunked response w/ keepalive 
 enabled would be preferred i guess
 i'll add a patch for review.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (TS-1049) TS hangs (dead lock) on HTTPS POST requests

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

Igor Galić reopened TS-1049:

reopen for backport

TS hangs (dead lock) on HTTPS POST requests
---

Attachments: records.config

A very reproducible bug where the body of a HTTPS POST request is never
forwarded to the origin server.
Client submits a HTTPS POST request to TS, which is supposed to forward to
the backend/origin server via HTTP. TS process the HTTP headers and
establishes connection to the origin server, but the body of the HTTPS POST
is never read. This hangs until the client times out and shuts down the
connection.
To reproduce:
# Client connects to TS using HTTPS (works OK if it is just HTTP).
# It must be a POST request.
# TS must use at least 2 worker threads.
# Easier to reproduce when the connections to the origin server is HTTP (not
HTTPS).
# POST body must be large enough so that the HTTP request headers and POST
body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
# I can consistently reproduce this problem using 2 separate clients each
simultaneously submitting 2 requests back to back (i.e., 2 requests from each
client, a total of 4 requests). This gives you a high probability that at
least one of the requests would hang.
Observation:
# Thread A accepted and processed the HTTP headers, and called
UnixNetProcessor::connect_re to prepare a new connection to the origin
server.
# Thread A must not have read the body of the POST. Otherwise, it works fine.
# Thread B was assigned the task to handle the origin server connection. If
the same thread A was picked, then everything works fine.
# Apparently, one of the first things that thread B does is to acquire the
mutex for reading from the client. (Why does it do that??)
# While thread B was holding the mutex, thread A proceeded in
SSLNetVConnection::net_read_io, tried and failed to acquire the mutex.
Thread A typically re-tried calling SSLNetVConnection::net_read_io soon,
but gave up after the second failure. But if thread B released the mutex soon
enough, that thread A could proceed happily and everything works.
# From this point, the body of the POST is never read from the client, and
there is nothing to be proxy'd to the origin server, and both the consumer
and producer tasks are never scheduled to run again -- or until the client
times out. I tried setting the client-side time out to as long as 3-5
minutes and TS really does not recover by itself until the client closed the
connection.
This is the first time I uses this bug system. Please let me know how I
could produce the configuration files and trace logs, etc. Thanks!

[jira] [Reopened] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed a


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

Igor Galić reopened TS-1061:



reopen for backport

 TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter 
 (int *bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter 
 needs to be removed as it is not used.
 -

 Key: TS-1061
 URL: https://issues.apache.org/jira/browse/TS-1061
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 3.1.1, 3.0.1
 Environment: Redhat Linux but it is not environment specific
Reporter: Alistair Stevenson
Assignee: Igor Galić
Priority: Minor
  Labels: api-change
 Fix For: 3.1.2

   Original Estimate: 1h
  Remaining Estimate: 1h

 The definitions are:
 ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
 ./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
 txnp);
 The int * bytes parameter is not used and means that the function does not 
 resolve and so cannot be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-876) forward map based on request receive port


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

Igor Galić reassigned TS-876:
-

Assignee: Igor Galić  (was: Brian Geffon)

 forward map based on request receive port
 -

 Key: TS-876
 URL: https://issues.apache.org/jira/browse/TS-876
 Project: Traffic Server
  Issue Type: New Feature
  Components: Remap API
Reporter: Manjesh Nilange
Assignee: Igor Galić
 Fix For: 3.1.0

 Attachments: TS876.fixed.patch, map_with_recv_port.patch


 Currently the port in the from fields of all remap rules are compared 
 against the port in the request (explicitly in the request or implicitly 
 deduced from the protocol). TS supports listening on multiple ports, so there 
 is a use case for a remap rule that uses the TS port at which the request is 
 received instead of the request port.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (TS-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)


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

Igor Galić reopened TS-1038:



reopen for backport

 TSHttpTxnErrorBodySet() can leak memory (pt 2)
 --

 Key: TS-1038
 URL: https://issues.apache.org/jira/browse/TS-1038
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Brian Geffon
Assignee: Igor Galić
 Fix For: 3.1.2

 Attachments: TSHttpTxnErrorBodySet.patch


 TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that 
 mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 
 which frees internal_msg_buffer_type...it's expected that mimetype was 
 malloced since clearly it's being freed. So that means there is still a 
 memory leak in TSHttpTxnErrorBodySet().
 Patch included.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1095) 3.0.x ts.h.in has incorrect declaration for TSFetchURL