date:20131008

Uri Shachar created TS-2268:
---

 Summary: Add support for opening protocol traffic sockets through 
the traffic_manager
 Key: TS-2268
 URL: https://issues.apache.org/jira/browse/TS-2268
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins, TS API
Reporter: Uri Shachar


Add a TSPluginDescriptorAccept(contp) function to allow a protocol plugin to 
set a callback for accepting new connections on a socket opened by the 
traffic_manager (that's defined like 2345:plugin in the server_ports 
configuration).

This has two advantages on opening a socket using TSNetAccept:
1) If the traffic_server crashes, new connections won't be rejected while we 
recover
2) Support for all port configuration flags

in the future, support can be added for a named approach, allowing protocol 
plugin A to accept on socket A and protocol plugin B  to accept on socket B



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager


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

Uri Shachar reassigned TS-2268:
---

Assignee: Uri Shachar

 Add support for opening protocol traffic sockets through the traffic_manager
 

 Key: TS-2268
 URL: https://issues.apache.org/jira/browse/TS-2268
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins, TS API
Reporter: Uri Shachar
Assignee: Uri Shachar

 Add a TSPluginDescriptorAccept(contp) function to allow a protocol plugin to 
 set a callback for accepting new connections on a socket opened by the 
 traffic_manager (that's defined like 2345:plugin in the server_ports 
 configuration).
 This has two advantages on opening a socket using TSNetAccept:
 1) If the traffic_server crashes, new connections won't be rejected while we 
 recover
 2) Support for all port configuration flags
 in the future, support can be added for a named approach, allowing protocol 
 plugin A to accept on socket A and protocol plugin B  to accept on socket B



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2267) Leaking file descriptors - no inactivity timeout set


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

Leif Hedstrom updated TS-2267:
--

Fix Version/s: 4.1.0

 Leaking file descriptors - no inactivity timeout set
 

 Key: TS-2267
 URL: https://issues.apache.org/jira/browse/TS-2267
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Network
Affects Versions: 4.0.1
 Environment: RHEL 6.4
Reporter: David Carlin
 Fix For: 4.1.0


 We noticed a problem on two of our *forward proxy* hosts where ATS would run 
 out of file descriptors.  Even after a host was removed from a VIP for hours, 
 ATS would report:
 proxy.process.http.current_server_connections = 0
 proxy.process.http.current_active_client_connections = 43559
 # ss -s
 Total: 43622 (kernel 43688)
 TCP:   43632 (estab 2, closed 39553, orphaned 0, synrecv 0, timewait 87/0), 
 ports 55
 Note that ATS reports 43559 active connections, but there are only 2 
 established connections on the host.  On this particular host, 
 proxy.config.net.connections_throttle was set to 5 so we first noticed 
 the problem because ATS started throttling and never recovered - the host 
 kept flapping as the connection count stayed near the throttling limit. 
 Bryan added some debugging to inactivity cop to create a log entry every time 
 there was a connection with no inactivity timeout set - this helped confirm 
 the issue.  He then made a patch to set a fixed 5 min timeout if there is no 
 inactivity timeout specified - this helped stabilize the issue. 
 The only zero timeout in records.config was 
 proxy.config.http.transaction_active_timeout_out = 0 which is the default.  
 Changing this to something else did not alleviate the problem - we could 
 still see in the debug logs that connections had no inactivity timeout set.
 We downgraded from 4.0.1 to 3.2.0 and the problem still occured in 3.2.0
 Thanks to Bryan Call for troubleshooting/patching!



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2267) Leaking file descriptors - no inactivity timeout set


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

Leif Hedstrom commented on TS-2267:
---

is this easy to reproduce? if so, can you see if you can git bisect this bad 
boy? I know we've done many changes around inactivity timers, so (hopefully) 
this is likely a regression.

 Leaking file descriptors - no inactivity timeout set
 

 Key: TS-2267
 URL: https://issues.apache.org/jira/browse/TS-2267
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Network
Affects Versions: 4.0.1
 Environment: RHEL 6.4
Reporter: David Carlin
 Fix For: 4.1.0


 We noticed a problem on two of our *forward proxy* hosts where ATS would run 
 out of file descriptors.  Even after a host was removed from a VIP for hours, 
 ATS would report:
 proxy.process.http.current_server_connections = 0
 proxy.process.http.current_active_client_connections = 43559
 # ss -s
 Total: 43622 (kernel 43688)
 TCP:   43632 (estab 2, closed 39553, orphaned 0, synrecv 0, timewait 87/0), 
 ports 55
 Note that ATS reports 43559 active connections, but there are only 2 
 established connections on the host.  On this particular host, 
 proxy.config.net.connections_throttle was set to 5 so we first noticed 
 the problem because ATS started throttling and never recovered - the host 
 kept flapping as the connection count stayed near the throttling limit. 
 Bryan added some debugging to inactivity cop to create a log entry every time 
 there was a connection with no inactivity timeout set - this helped confirm 
 the issue.  He then made a patch to set a fixed 5 min timeout if there is no 
 inactivity timeout specified - this helped stabilize the issue. 
 The only zero timeout in records.config was 
 proxy.config.http.transaction_active_timeout_out = 0 which is the default.  
 Changing this to something else did not alleviate the problem - we could 
 still see in the debug logs that connections had no inactivity timeout set.
 We downgraded from 4.0.1 to 3.2.0 and the problem still occured in 3.2.0
 Thanks to Bryan Call for troubleshooting/patching!



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-1776) Range requests not working right in 3.2.4


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

Leif Hedstrom updated TS-1776:
--

Fix Version/s: (was: 4.1.0)
   3.2.6

 Range requests not working right in 3.2.4
 -

 Key: TS-1776
 URL: https://issues.apache.org/jira/browse/TS-1776
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.2.4
Reporter: William Bardwell
Assignee: Alan M. Carroll
Priority: Blocker
 Fix For: 3.2.6


 With the patch in 3.2.4 for TS-1575 that tries to turn off the new range 
 code, range requests aren't work right for me.  The responses have all of the 
 multi-part header markings, but the Content-Length and Content-Range headers 
 should be used for single range requests.  Also when I do a range that starts 
  0, the content is wrong.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2143) Refactor and fix the alarms executable invocation and script


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

Leif Hedstrom updated TS-2143:
--

Fix Version/s: (was: 4.1.0)

 Refactor and fix the alarms executable invocation and script
 

 Key: TS-2143
 URL: https://issues.apache.org/jira/browse/TS-2143
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, Core
Reporter: Leif Hedstrom
 Fix For: 5.0.0


 E.g. proxy.config.alarm.admin.admin_user is only used for sending an email 
 address to the alarm script. Instead of passing email address, I think we 
 should pass the alarm_t (type) that generated the alarm.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2227) Make header_rewrite load all pparam's as config files


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

Leif Hedstrom reassigned TS-2227:
-

Assignee: Leif Hedstrom

 Make header_rewrite load all pparam's as config files
 -

 Key: TS-2227
 URL: https://issues.apache.org/jira/browse/TS-2227
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 4.1.0


 Particularly in a remap rule, it'd be useful to do concatenation of config 
 files, e.g.
 {code}
 … @plugin=header_rewrite.so @pparam=set-cache-control.config 
 @pparam=set-id-tag.config ...
 {code}
 This allows certain portions of a config to be shared across multiple remap 
 rules for example.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2226) header_rewrite ought to have a set-header operator


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

Leif Hedstrom reassigned TS-2226:
-

Assignee: Leif Hedstrom

 header_rewrite ought to have a set-header operator
 --

 Key: TS-2226
 URL: https://issues.apache.org/jira/browse/TS-2226
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 4.1.0


 Right now, the expectation is that if you really want to set a header, you 
 have to do
 rm-header Foo-Header
 add-header Foo-Header bar
 Lame. The examples even has a set-header line, but there's no code for it.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Work started] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager


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

Work on TS-2268 started by Uri Shachar.

 Add support for opening protocol traffic sockets through the traffic_manager
 

 Key: TS-2268
 URL: https://issues.apache.org/jira/browse/TS-2268
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins, TS API
Reporter: Uri Shachar
Assignee: Uri Shachar

 Add a TSPluginDescriptorAccept(contp) function to allow a protocol plugin to 
 set a callback for accepting new connections on a socket opened by the 
 traffic_manager (that's defined like 2345:plugin in the server_ports 
 configuration).
 This has two advantages on opening a socket using TSNetAccept:
 1) If the traffic_server crashes, new connections won't be rejected while we 
 recover
 2) Support for all port configuration flags
 in the future, support can be added for a named approach, allowing protocol 
 plugin A to accept on socket A and protocol plugin B  to accept on socket B



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2216) Custom Log %cquup not always initialized properly.


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

Leif Hedstrom commented on TS-2216:
---

Is this with any plugins enabled ?


 Custom Log %cquup not always initialized properly.
 

 Key: TS-2216
 URL: https://issues.apache.org/jira/browse/TS-2216
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Adam Twardowski
 Fix For: 4.1.0


 Noticed this in my log output, it appears that the %cquup log variable is 
 now always initialized properly.
 {code}
 LogFormat
   Name = csv/
   Format = 
 \%cqtn\,\%ttmsf\,\%{X-Forwarded-For}cqh\,\%crc\,\%pssc\,\%cqhl\,\%pscl\,\%cqhm\,\%cquuc\,\%cquuh\,\%cquup\/
 /LogFormat
 12/Sep/2013:17:48:16 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,à
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,1
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,±
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,·
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¤62R
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,r/player.swf
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,!
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:22 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¦62R
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2186) Promote TSHttpTxnOverwriteExpireTime() to ts/ts.h


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

Leif Hedstrom reassigned TS-2186:
-

Assignee: Leif Hedstrom

 Promote TSHttpTxnOverwriteExpireTime() to ts/ts.h
 -

 Key: TS-2186
 URL: https://issues.apache.org/jira/browse/TS-2186
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 4.1.0


 It is currently in ts/experimental.h



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2242) Update plugins in core to have same email address and vendor line


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

Leif Hedstrom updated TS-2242:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 Update plugins in core to have same email address and vendor line
 -

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


 Support email for core plugins should be d...@trafficserver.apache.org.
 Similarly, the vendor should be Apache Software Foundation.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2218) create a standard way of getting the plugin configuration directory

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

Leif Hedstrom updated TS-2218:
--

Fix Version/s: (was: 4.1.0)
4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before
the November release of v4.1.0.

create a standard way of getting the plugin configuration directory
---

Key: TS-2218
URL: https://issues.apache.org/jira/browse/TS-2218
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, Plugins
Reporter: Bryan Call
Fix For: 4.2.0

Currently some plugins use TSPluginDirGet()
(/usr/local/libexec/trafficserver) and some have hard coded paths for getting
the directory where the config files are set.
I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in
config.layout and is /usr/local/etc by default) as the default base directory
for the plugin configuration. Under this directory people will have their
config file or a sub directory if there are a lot of config files for a
plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/)
There will be an API to get the plugin config directory called
TSPluginConfigDir() and this will by default pass back
sysconfdir/trafficserver/plugins/. All plugins will use this API to get the
configuration directory.
There will also be a records.config option to override the default plugin
config directory. This option will be called
proxy.config.plugin.plugin_config_dir. This option will be set to NULL by
default and the API will assume sysconfdir/trafficsever/plugins by default.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2241) Add plugin API to see status of remap


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

Leif Hedstrom updated TS-2241:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 Add plugin API to see status of remap
 -

 Key: TS-2241
 URL: https://issues.apache.org/jira/browse/TS-2241
 Project: Traffic Server
  Issue Type: New Feature
Reporter: Phil Sorber
Assignee: Phil Sorber
 Fix For: 4.2.0


 Whether or not a Host header matched something in remap.config is useful to 
 know for a plugin. It's tracked in the state machine, but not exposed. Right 
 now plugins need to look at side effects to decide if it was valid or not. I 
 think we need an API to expose that. TSHttpRemapValid() or similar.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2215) Implement the $r expansion parameter in regex_remap


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

Leif Hedstrom updated TS-2215:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 Implement the $r expansion parameter in regex_remap
 ---

 Key: TS-2215
 URL: https://issues.apache.org/jira/browse/TS-2215
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 4.2.0


 It would expand into the request path, and could be used to e.g. strip out 
 query parameters with a simple rule like
 {code}
 . http://$t/$r
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-1493) TShtrime() returning negative value


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

Leif Hedstrom updated TS-1493:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 TShtrime() returning negative value
 ---

 Key: TS-1493
 URL: https://issues.apache.org/jira/browse/TS-1493
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: bianca cooper
 Fix For: 4.2.0


 calling TShrtime function after TS_EVENT_HTTP_TXN_CLOSE (and before reenable 
 the transaction) sometimes returns negative number 
 calling the same function in other places in code always returns positive 
 number. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2089) one log collation thread is not enough for busy system


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

Leif Hedstrom updated TS-2089:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 one log collation thread is not enough for busy system
 --

 Key: TS-2089
 URL: https://issues.apache.org/jira/browse/TS-2089
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: Zhao Yongming
Assignee: Yunkai Zhang
 Fix For: 4.2.0

 Attachments: 
 0001-TS-2089-introduce-configurable-collation-preproc-thr.patch, 
 0001-TS-2089-introduce-configurable-collation-preproc-thr.patch.V2


 we should make log collation more thread  cpu nice.
  
 {code}
 top - 22:34:22 up  3:37,  1 user,  load average: 1.20, 1.71, 1.66
 Tasks: 979 total,   2 running, 977 sleeping,   0 stopped,   0 zombie
 Cpu(s):  3.5%us,  0.6%sy,  0.0%ni, 95.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
 Mem:  65943744k total, 62536348k used,  3407396k free,90544k buffers
 Swap:  2097144k total,0k used,  2097144k free, 54189788k cached
   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  4651 ats   20   0 12.9g 5.3g 4928 R 100.1  8.5 197:51.78 [LOGGING]
  4460 ats   20   0 12.9g 5.3g 4928 S  7.9  8.5  18:12.57 [ET_NET 44]
  4457 ats   20   0 12.9g 5.3g 4928 S  5.3  8.5   7:32.34 [ET_NET 41]
  4461 ats   20   0 12.9g 5.3g 4928 S  4.3  8.5   6:41.79 [ET_NET 45]
  4453 ats   20   0 12.9g 5.3g 4928 S  3.0  8.5   6:44.52 [ET_NET 37]
  4463 ats   20   0 12.9g 5.3g 4928 S  3.0  8.5   7:54.01 [ET_NET 47]
  3652 root  39  19 000 S  1.0  0.0   2:14.15 kipmi0
  4425 ats   20   0 12.9g 5.3g 4928 S  0.7  8.5   0:19.21 [ET_NET 9]
  4426 ats   20   0 12.9g 5.3g 4928 S  0.7  8.5   0:19.42 [ET_NET 10]
  4430 ats   20   0 12.9g 5.3g 4928 S  0.7  8.5   0:19.55 [ET_NET 14]
   132 root  20   0 000 S  0.3  0.0   0:00.82 events/1
  4417 ats   20   0 12.9g 5.3g 4928 S  0.3  8.5   0:19.82 [ET_NET 1]
  4418 ats   20   0 12.9g 5.3g 4928 S  0.3  8.5   0:20.02 [ET_NET 2]
  4420 ats   20   0 12.9g 5.3g 4928 S  0.3  8.5   0:19.64 [ET_NET 4]
  4422 ats   20   0 12.9g 5.3g 4928 S  0.3  8.5   0:19.84 [ET_NET 6]
  4427 ats   20   0 12.9g 5.3g 4928 S  0.3  8.5   0:19.94 [ET_NET 11]
  4435 ats   20   0 12.9g 5.3g 4928 S  0.3  8.5   0:19.88 [ET_NET 19]
 {code}
 == Update ===
 I have developed a patch to fix this issue. After I rebase it to master 
 branch, I'll attach it to here. Here is the description of my patch:
 ---
 We found that CPU of logging thread could be easy to reach up 100% in
 collation host, but disk IO was low at the same time.
 The bottleneck of logging thread is that some preprocessing job, such as
 convert LogBuffer to ascii text, consume so much CPU time. And more
 worse, the write() operation will block logging thread.
 So this patch try to split logging thread into two parts:
 1) Configurable preproc threads, which are responsiable for processing all
of prepare work, and then forward the preprocessed buffer to flush thread,
or send them to CollationClient/HostSM.
 2) One Flush thread, it will consume preprocessed buffers and write them to
disk. In our testing, one flush thread is enough for us.
 TODO: This patch supports only one flush thread, we can improve it to
   one flush thread per file/disk in the future.
 == How to configure ==
 The number of preproc threads is 1 by default.
 Please modify proxy.config.log.collation_preproc_threads option to
 change it.
 ---
 ==
 After apply this patch, let's have a look the 'top' output:
 {code}
 [root@test81.cn8 core]# top -H -p 3984 -b -n 1
 top - 15:39:06 up 17:23,  6 users,  load average: 3.37, 3.09, 3.15
 Tasks: 246 total,   6 running, 240 sleeping,   0 stopped,   0 zombie
 Cpu(s):  1.4%us,  0.5%sy,  0.0%ni, 97.6%id,  0.4%wa,  0.0%hi,  0.0%si,  0.0%st
 Mem:  65943744k total, 65763084k used,   180660k free,   136688k buffers
 Swap:  2097144k total,0k used,  2097144k free, 57275428k cached
   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  4237 ats   20   0 8941m 5.2g 5148 R 39.5  8.3  80:46.23 [LOG_PREPROC 2]
  4236 ats   20   0 8941m 5.2g 5148 R 37.5  8.3  80:46.53 [LOG_PREPROC 1]
  4235 ats   20   0 8941m 5.2g 5148 R 35.6  8.3  80:46.71 [LOG_PREPROC 0]
  4238 ats   20   0 8941m 5.2g 5148 R 35.6  8.3  80:48.37 [LOG_PREPROC 3]
  4239 ats   20   0 8941m 5.2g 5148 R 35.6  8.3  80:46.58 [LOG_PREPROC 4]
  4240 ats   20   0 8941m 5.2g 5148 R 11.9  8.3  20:45.28 [LOG_FLUSH]
  4037 ats   20   0 8941m 5.2g 5148 S  7.9  8.3  15:06.60 [ET_NET 38]
  4045 ats   20   0

[jira] [Updated] (TS-2118) memcached plugin is in the source tree but does not build


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

Leif Hedstrom updated TS-2118:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 memcached plugin is in the source tree but does not build
 -

 Key: TS-2118
 URL: https://issues.apache.org/jira/browse/TS-2118
 Project: Traffic Server
  Issue Type: Bug
Reporter: Igor Galić
Assignee: Eric Balsa
 Fix For: 4.2.0


 The memcached_remap plugin is currently in our experimental plugin tree, but 
 doesn't build even with {{--enable-experimental}}.
 This should be fixed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2227) Make header_rewrite load all pparam's as config files


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

Leif Hedstrom updated TS-2227:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 Make header_rewrite load all pparam's as config files
 -

 Key: TS-2227
 URL: https://issues.apache.org/jira/browse/TS-2227
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 4.2.0


 Particularly in a remap rule, it'd be useful to do concatenation of config 
 files, e.g.
 {code}
 … @plugin=header_rewrite.so @pparam=set-cache-control.config 
 @pparam=set-id-tag.config ...
 {code}
 This allows certain portions of a config to be shared across multiple remap 
 rules for example.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2208) LogFilter does not have a way to configure conjunction


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

Leif Hedstrom updated TS-2208:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 LogFilter does not have a way to configure conjunction
 

 Key: TS-2208
 URL: https://issues.apache.org/jira/browse/TS-2208
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Leif Hedstrom
 Fix For: 4.2.0


 In the LogFilter implementation details, there's code to deal with OR and 
 AND such that you can express either
 REJECT if x AND y
 or
 REJECT if x OR y
 However, there's no way to configure this in logs_xml.config, 
 m_does_conjunction is always true afaik (so only the OR case above is 
 supported). So even though the code supports both of the above, there's no 
 way to express it:
 {code}
   bool m_does_conjunction;
   // If m_does_conjunction = true
   // toss_this_entry returns true
   // if ANY filter tosses entry away.
   // If m_does_conjunction = false,
   // toss this entry returns true if
   // ALL filters toss away entry
 {code}
 This seems properly implemented in the LogFilterList::toss_this_entry() 
 method:
 {code}
 bool LogFilterList::toss_this_entry(LogAccess * lad)
 {
   if (m_does_conjunction) {
 // toss if any filter rejects the entry (all filters should accept)
 //
 for (LogFilter * f = first(); f; f = next(f)) {
   if (f-toss_this_entry(lad)) {
 return true;
   }
 }
 return false;
   } else {
 // toss if all filters reject the entry (any filter accepts)
 //
 for (LogFilter * f = first(); f; f = next(f)) {
   if (!f-toss_this_entry(lad)) {
 return false;
   }
 }
 return true;
   }
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2228) Allow header_rewrite to set overridable configurations


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

Leif Hedstrom updated TS-2228:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 Allow header_rewrite to set overridable configurations 
 ---

 Key: TS-2228
 URL: https://issues.apache.org/jira/browse/TS-2228
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 4.2.0


 It'd be swell to be able to do e.g.
 cond %{READ_REQUEST_HDR_HOOK} [AND]
 cond %{CLIENT-HEADER:Foo-bar} =1
   set-config proxy.config.http.insert_response_via_str 1



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2069) Regression tests fails on OSX


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

Leif Hedstrom updated TS-2069:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 Regression tests fails on OSX
 -

 Key: TS-2069
 URL: https://issues.apache.org/jira/browse/TS-2069
 Project: Traffic Server
  Issue Type: Bug
  Components: Quality
Reporter: Leif Hedstrom
 Fix For: 4.2.0


 I get
 {code}
 [SDK_API_HttpAltInfo] TSHttpAltInfo : [All] FAIL { Test not executed even 
 once }
 REGRESSION_RESULT SDK_API_HttpAltInfo:  FAILED
 REGRESSION TEST SDK_API_HttpTxnTransform started
 Regression test(SDK_API_HttpTxnTransform) still in progress
 [SDK_API_HttpTxnTransform] TSHttpTxnUntransformedResponseCache : [TestCase1] 
 FAIL { Value's Mismatch }
 [SDK_API_HttpTxnTransform] TSHttpTxnTransformedResponseCache : [TestCase1] 
 FAIL { Value's Mismatch }
 [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] FAIL { did not 
 pass transformed_resp_cache }
 [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] FAIL { did not 
 pass untransformed_resp_cache }
 [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] FAIL { did not 
 pass transform_create }
 REGRESSION_RESULT SDK_API_HttpTxnTransform: FAILED
 REGRESSION TEST SDK_API_HttpTxnCache started
 Regression test(SDK_API_HttpTxnCache) still in progress
 REGRESSION_RESULT SDK_API_HttpTxnCache: FAILED
 REGRESSION TEST SDK_API_HttpSsn started
 Regression test(SDK_API_HttpSsn) still in progress
 REGRESSION_RESULT SDK_API_HttpSsn:  FAILED
 REGRESSION TEST SDK_API_HttpHookAdd started
 Regression test(SDK_API_HttpHookAdd) still in progress
 [SDK_API_HttpHookAdd] TSHttpHookAdd : [TestCase1] FAIL { Hooks not called 
 or request failure. Hook mask = 0
  HTTP/1.0 200 OK
 X-Response-ID: 1
 Content-Type: text/html
 Cache-Control: no-cache
 Date: Sat, 27 Jul 2013 16:22:45 GMT
 Age: 0
 Via: http/1.0 heimdall.local (ApacheTrafficServer/3.3.5-dev)
 Server: ATS/3.3.5-dev
 Body for response 1: }
 [SDK_API_HttpHookAdd] TSHttpTxnReenable : [TestCase1] FAIL { Txn not 
 re-enabled properly }
 REGRESSION_RESULT SDK_API_HttpHookAdd:  FAILED
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2230) header_rewrite should support the same hook-management that header_filter does for remap rules


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

Leif Hedstrom updated TS-2230:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 header_rewrite should support the same hook-management that header_filter 
 does for remap rules
 --

 Key: TS-2230
 URL: https://issues.apache.org/jira/browse/TS-2230
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 4.2.0


 In header_filter, you can use the per-remap rules, yet specify that a rule 
 should apply to a specific hook. We should try to support the same in 
 header_rewrite
 This requires that we also allow header_rewrite to be invoked without a 
 global configuration. This is to allow the support for only remap.config use.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2223) Incorrect timezone offset when using %cqtn


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

Leif Hedstrom updated TS-2223:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 Incorrect timezone offset when using %cqtn
 

 Key: TS-2223
 URL: https://issues.apache.org/jira/browse/TS-2223
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Adam Twardowski
 Fix For: 4.2.0


 My logs are showing the incorrect timezone offset for EDT (Eastern Daylight 
 time).  ATS logs are showing -0500 when it should be -0400.  Apache returns 
 the correct timezone.
 It looks like the problem is somewhere in the 
 LogUtils::timestamp_to_netscape_str function.
 ATS:
 {code}
 13/Sep/2013:13:08:36 -0500...
 {code}
 Apache:
 {code}
 [13/Sep/2013:13:07:59 -0400]
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified


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

Leif Hedstrom updated TS-965:
-

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 cache.config can't deal with both revalidate= and ttl-in-cache= specified
 -

 Key: TS-965
 URL: https://issues.apache.org/jira/browse/TS-965
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Affects Versions: 3.1.0, 3.0.1
Reporter: Igor Galić
  Labels: A
 Fix For: 4.2.0


 If both of these options are specified (with the same time?), nothing is 
 cached at all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2220) add proxy.config.http.insert_client_ip


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

Leif Hedstrom updated TS-2220:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 add proxy.config.http.insert_client_ip
 --

 Key: TS-2220
 URL: https://issues.apache.org/jira/browse/TS-2220
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP
Affects Versions: 4.0.1
Reporter: Zhao Yongming
 Fix For: 4.2.0


 this is for V4 branch changes, add the new proxy.config.http.insert_client_ip.
 we should name proxy.config.http.anonymize_insert_client_ip as 
 'proxy.config.http.insert_request_client_ip' or just 
 'proxy.config.http.insert_client_ip'
 and the current implement of the insert client ip works only if the client 
 request do not have a 'Client-ip' header, but sometimes we need to replace it 
 even if someone send us a fake 'Client-ip':
 proxy.config.http.insert_client_ip
 INT
 1
 When disabled(0), do nothing.
 When enabled (1), Traffic Server inserts Client-IP headers to retain the 
 client IP address, if there is no such headers. 
 When forced (2), Traffic Server inserts Client-IP, or replace the origin 
 Client-IP header if it is already there.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2250) No timestamps in traffic.out


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

Leif Hedstrom updated TS-2250:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 No timestamps in traffic.out
 

 Key: TS-2250
 URL: https://issues.apache.org/jira/browse/TS-2250
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: David Carlin
 Fix For: 4.2.0


 There are no timestamps in traffic.out.  This makes it hard to know when 
 things happened, or to correlate logs.  Some example output:
 [E. Mgmt] log == [TrafficManager] using root directory '/usr/local'
 FATAL: Can't acquire manager lockfile '/var/run/trafficserver/manager.lock' 
 (No space left on device)
 [E. Mgmt] log == [TrafficManager] using root directory '/usr/local'
 [example_prep.sh] Checking/Moving old cores...
 [TrafficServer] using root directory '/usr/local'
 [example_alarm_bin.sh] sent alarm: hostname [TrafficManager] Traffic Server 
 process was reset.
 [example_prep.sh] Checking/Moving old cores...
 [TrafficServer] using root directory '/usr/local'
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0(+0x383480f4a0)[0x2b67ccf414a0]
 [...]



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2216) Custom Log %cquup not always initialized properly.


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

Adam Twardowski commented on TS-2216:
-

In my specific setup, I've got a bunch of servers sending logs to a collation 
server.  The collation server doesn't have any plugins enabled, and the other 
servers just have stats_over_http.so enabled.

 Custom Log %cquup not always initialized properly.
 

 Key: TS-2216
 URL: https://issues.apache.org/jira/browse/TS-2216
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Adam Twardowski
 Fix For: 4.1.0


 Noticed this in my log output, it appears that the %cquup log variable is 
 now always initialized properly.
 {code}
 LogFormat
   Name = csv/
   Format = 
 \%cqtn\,\%ttmsf\,\%{X-Forwarded-For}cqh\,\%crc\,\%pssc\,\%cqhl\,\%pscl\,\%cqhm\,\%cquuc\,\%cquuh\,\%cquup\/
 /LogFormat
 12/Sep/2013:17:48:16 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,à
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,1
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,±
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,·
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¤62R
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,r/player.swf
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,!
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:22 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¦62R
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2211) SSL client connections hang and a aborted due to inactivity


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

Leif Hedstrom reassigned TS-2211:
-

Assignee: Theo Schlossnagle

 SSL client connections hang and a aborted due to inactivity
 ---

 Key: TS-2211
 URL: https://issues.apache.org/jira/browse/TS-2211
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, SSL
Reporter: Theo Schlossnagle
Assignee: Theo Schlossnagle
 Fix For: 4.1.0

 Attachments: 
 0001-TS-2211-SSL-client-connections-hang-and-a-aborted-du.patch, 
 0002-TS-2211-SSL-client-connections-hang-and-a-aborted-du.patch


 Test setup:
 ATS in reverse proxy mode. Terminating SSL for clients, remap to non-SSL for 
 origin.  Origin delays 10s before sending any data (including headers), then 
 dumps a non-chunked response (Content-Length) of about 3Mbytes.
 Over slow client connections, the client session freezes mid download (around 
 256k in my tests)... hangs until the inactivity timer fires and snips all the 
 connections.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag


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

Leif Hedstrom updated TS-1606:
--

Fix Version/s: (was: 5.0.0)
   4.1.0

 Log buffers are not flushed periodically when TS is launched with 
 NO_REMOTE_MANAGEMENT flag
 ---

 Key: TS-1606
 URL: https://issues.apache.org/jira/browse/TS-1606
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
Assignee: Yunkai Zhang
 Fix For: 4.1.0

 Attachments: trafficserver-periodic-tasks.patch


 When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when 
 launched not as a daemon but directly - this is extremely convenient for 
 debugging), the PeriodicWakeup event is not scheduled.
 As a result, Log::flush_thread_main() does not wake up periodically, but only 
 on log buffer overflow. Coupled with a horribly wrong activation check in 
 Log::flush_thread_main():
 {code}
 if (now  last_time) {
   if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
   // We run only when waken up at the moment which is exact
   // multiple of PERIODIC_TASKS_INTERVAL!
 {code}
 this leads to that probability of any log output is low.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-1584) Exposing client SSL certificate verification result in plugin API


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

Leif Hedstrom commented on TS-1584:
---

[~jpe...@apache.org]What's the appropriate target fix version for this? 

 Exposing client SSL certificate verification result in plugin API 
 --

 Key: TS-1584
 URL: https://issues.apache.org/jira/browse/TS-1584
 Project: Traffic Server
  Issue Type: Improvement
  Components: SSL, TS API
Affects Versions: 3.3.4
Reporter: Thach Tran
Assignee: James Peach
Priority: Minor
  Labels: patch
 Fix For: 5.0.0

 Attachments: 
 0001-Exposing-client-ssl-certificate-verification-result-.patch, 
 0001-TS-1584-Retaining-some-info-from-client-certificate-.patch


 I'm writing an authentication plugin for traffic server and would like to 
 implement the following logic:
   * If the client supplies valid certificate over ssl, allow the transaction 
 to proceed with no further authentication.
   * Otherwise challenge the client with username/password authentication.
 Currently if I turn on client certificate checking in TS 
 (proxy.config.ssl.client.certification_level  0), the result of the client 
 certificate verification happens at the SSLNetVConnection level and plugin 
 hooks have no knowledge of this. This makes implementing the aforementioned 
 logic not possible.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2119) mysql_remap plugin is in the source tree but does not build


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

Leif Hedstrom updated TS-2119:
--

Fix Version/s: (was: 4.1.0)
   4.2.0

Moving these to v4.2.0, please move any bugs back that will be worked on before 
the November release of v4.1.0.

 mysql_remap plugin is in the source tree but does not build
 ---

 Key: TS-2119
 URL: https://issues.apache.org/jira/browse/TS-2119
 Project: Traffic Server
  Issue Type: Bug
  Components: Build, Plugins
Reporter: Igor Galić
Assignee: Eric Balsa
 Fix For: 4.2.0


 The mysql_remap plugin plugin is currently in our experimental plugin tree, 
 but doesn't build even with {{--enable-experimental}}.
 This should be fixed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2216) Custom Log %cquup not always initialized properly.


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

Leif Hedstrom commented on TS-2216:
---

Are those log entries by chance from the stats_over_http.so plugin? The reason 
I'm asking is that I've run into this myself, but only when using a server 
intercept plugin (and stats_over_http is such a plugin).

 Custom Log %cquup not always initialized properly.
 

 Key: TS-2216
 URL: https://issues.apache.org/jira/browse/TS-2216
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Adam Twardowski
 Fix For: 4.1.0


 Noticed this in my log output, it appears that the %cquup log variable is 
 now always initialized properly.
 {code}
 LogFormat
   Name = csv/
   Format = 
 \%cqtn\,\%ttmsf\,\%{X-Forwarded-For}cqh\,\%crc\,\%pssc\,\%cqhl\,\%pscl\,\%cqhm\,\%cquuc\,\%cquuh\,\%cquup\/
 /LogFormat
 12/Sep/2013:17:48:16 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,à
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,1
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,±
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,·
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¤62R
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,r/player.swf
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,!
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:22 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¦62R
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-1981) Url remap method filtering is broken with invalid method


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

Leif Hedstrom commented on TS-1981:
---

[~amc][~thachtran]Any updates on this ?

 Url remap method filtering is broken with invalid method
 

 Key: TS-1981
 URL: https://issues.apache.org/jira/browse/TS-1981
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration, Security
Reporter: Thach Tran
Assignee: Alan M. Carroll
 Fix For: 4.2.0

 Attachments: 
 0001-TS-1981-Fix-method-filtering-to-deny-invalid-methods.patch


 ACL filtering based on HTTP's method is ignored if method received from 
 client is invalid.
 To reproduce, with the default 8080 {{server_ports}} configure the 
 {{remap.conf}} as follows.
 {noformat}
 map http://localhost:8080/ http://www.google.com/ @method=GET
 {noformat}
 Then run the following curl command.
 {noformat}
 $ curl -v -X AA http://localhost:8080/
 {noformat}
 Notice that a 200 OK response is received by the client with some (empty) 
 HTML from google.com.
 If the following curl command is issued instead
 {noformat}
 $ curl -v -X PUT http://localhost:8080/
 {noformat}
 One will see that TS sends back a 403 Access Denied as expected.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2216) Custom Log %cquup not always initialized properly.


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

Adam Twardowski commented on TS-2216:
-

I have the plugin loaded, but I rarely ever access the stats page unless 
there's some issue, and there are many thousands of lines like that in my 
access logs.  I don't know if that answers your question or not.  I guess it's 
possible that something odd is happening under the hood that could be causing 
the plugin to generate spontaneous log messages.

Would you suggest that I try disabling the stats module everywhere and see if I 
still get the error?

 Custom Log %cquup not always initialized properly.
 

 Key: TS-2216
 URL: https://issues.apache.org/jira/browse/TS-2216
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Adam Twardowski
 Fix For: 4.1.0


 Noticed this in my log output, it appears that the %cquup log variable is 
 now always initialized properly.
 {code}
 LogFormat
   Name = csv/
   Format = 
 \%cqtn\,\%ttmsf\,\%{X-Forwarded-For}cqh\,\%crc\,\%pssc\,\%cqhl\,\%pscl\,\%cqhm\,\%cquuc\,\%cquuh\,\%cquup\/
 /LogFormat
 12/Sep/2013:17:48:16 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,à
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,1
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,±
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,·
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¤62R
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,r/player.swf
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,!
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:22 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¦62R
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2216) Custom Log %cquup not always initialized properly.


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

Adam Twardowski commented on TS-2216:
-

I have the plugin loaded, but I rarely ever access the stats page unless 
there's some issue, and there are many thousands of lines like that in my 
access logs.  I don't know if that answers your question or not.  I guess it's 
possible that something odd is happening under the hood that could be causing 
the plugin to generate spontaneous log messages.

Would you suggest that I try disabling the stats module everywhere and see if I 
still get the error?

 Custom Log %cquup not always initialized properly.
 

 Key: TS-2216
 URL: https://issues.apache.org/jira/browse/TS-2216
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Adam Twardowski
 Fix For: 4.1.0


 Noticed this in my log output, it appears that the %cquup log variable is 
 now always initialized properly.
 {code}
 LogFormat
   Name = csv/
   Format = 
 \%cqtn\,\%ttmsf\,\%{X-Forwarded-For}cqh\,\%crc\,\%pssc\,\%cqhl\,\%pscl\,\%cqhm\,\%cquuc\,\%cquuh\,\%cquup\/
 /LogFormat
 12/Sep/2013:17:48:16 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,à
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,1
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,±
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,·
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¤62R
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,r/player.swf
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,!
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:22 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¦62R
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager


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

Uri Shachar resolved TS-2268.
-

Resolution: Fixed

 Add support for opening protocol traffic sockets through the traffic_manager
 

 Key: TS-2268
 URL: https://issues.apache.org/jira/browse/TS-2268
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins, TS API
Reporter: Uri Shachar
Assignee: Uri Shachar

 Add a TSPluginDescriptorAccept(contp) function to allow a protocol plugin to 
 set a callback for accepting new connections on a socket opened by the 
 traffic_manager (that's defined like 2345:plugin in the server_ports 
 configuration).
 This has two advantages on opening a socket using TSNetAccept:
 1) If the traffic_server crashes, new connections won't be rejected while we 
 recover
 2) Support for all port configuration flags
 in the future, support can be added for a named approach, allowing protocol 
 plugin A to accept on socket A and protocol plugin B  to accept on socket B



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2216) Custom Log %cquup not always initialized properly.

2013-10-08 Thread ASF subversion and git services (JIRA)


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

Leif Hedstrom commented on TS-2216:
---

Well, what you see is not what I see (I get -), but it suspiciously similar. 
For me, changing it to log the mapped URL fixes it, such that requests served 
by the server intercept plugins.

If you could test disabling the plugin, it'd be great, but I don't know if 
it'll tell us much (I'm not certain at all that you are triggering the same 
problem I am).

 Custom Log %cquup not always initialized properly.
 

 Key: TS-2216
 URL: https://issues.apache.org/jira/browse/TS-2216
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Adam Twardowski
 Fix For: 4.1.0


 Noticed this in my log output, it appears that the %cquup log variable is 
 now always initialized properly.
 {code}
 LogFormat
   Name = csv/
   Format = 
 \%cqtn\,\%ttmsf\,\%{X-Forwarded-For}cqh\,\%crc\,\%pssc\,\%cqhl\,\%pscl\,\%cqhm\,\%cquuc\,\%cquuh\,\%cquup\/
 /LogFormat
 12/Sep/2013:17:48:16 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,à
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,1
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,±
 12/Sep/2013:17:48:17 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:18 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¢62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,£62R
 12/Sep/2013:17:48:19 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,·
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¤62R
 12/Sep/2013:17:48:20 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,r/player.swf
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¡
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,!
 12/Sep/2013:17:48:21 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¥62R
 12/Sep/2013:17:48:22 
 -0500,0.000,-,ERROR_UNKNOWN(90),000,15,0,-,-,-,¦62R
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager


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

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

Commit 3c0c835c1b06cb5c76ae8dba5add9a8ffc07495d in branch refs/heads/master 
from [~ushachar]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3c0c835 ]

TS-2268 Add support for opening protocol traffic sockets through the
traffic_manager.


 Add support for opening protocol traffic sockets through the traffic_manager
 

 Key: TS-2268
 URL: https://issues.apache.org/jira/browse/TS-2268
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins, TS API
Reporter: Uri Shachar
Assignee: Uri Shachar

 Add a TSPluginDescriptorAccept(contp) function to allow a protocol plugin to 
 set a callback for accepting new connections on a socket opened by the 
 traffic_manager (that's defined like 2345:plugin in the server_ports 
 configuration).
 This has two advantages on opening a socket using TSNetAccept:
 1) If the traffic_server crashes, new connections won't be rejected while we 
 recover
 2) Support for all port configuration flags
 in the future, support can be added for a named approach, allowing protocol 
 plugin A to accept on socket A and protocol plugin B  to accept on socket B



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2216) Custom Log %cquup not always initialized properly.