[jira] [Commented] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630067#comment-13630067 ] weijin commented on TS-608: --- since chenbin is going to handle the session management stuff, assign to him. :) > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Bin Chen > Fix For: 3.3.3 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-608: -- Assignee: Bin Chen > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Bin Chen > Fix For: 3.3.3 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1809) remove HTTP_CACHE build option
James Peach created TS-1809: --- Summary: remove HTTP_CACHE build option Key: TS-1809 URL: https://issues.apache.org/jira/browse/TS-1809 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach The HTTP_CACHE build option is probably not useful anymore. It's almost certainly broken and clutters up a lot of code. Let's remove it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1809) remove HTTP_CACHE build option
[ https://issues.apache.org/jira/browse/TS-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1809: Fix Version/s: 3.3.3 Assignee: Leif Hedstrom I know that Leif wants this one ... > remove HTTP_CACHE build option > -- > > Key: TS-1809 > URL: https://issues.apache.org/jira/browse/TS-1809 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 3.3.3 > > > The HTTP_CACHE build option is probably not useful anymore. It's almost > certainly broken and clutters up a lot of code. Let's remove it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1810) IPv6 for Cluster management
Leif Hedstrom created TS-1810:
-
Summary: IPv6 for Cluster management
Key: TS-1810
URL: https://issues.apache.org/jira/browse/TS-1810
Project: Traffic Server
Issue Type: Improvement
Components: Clustering
Reporter: Leif Hedstrom
It seems the management APIs (at least) for clustering are not IPv6 aware. E.g.
{code}
typedef int TSNodeHandle_t;
typedef void (*TSClusterRPCFunction) (TSNodeHandle_t *node, TSClusterRPCMsg_t
*msg, int msg_data_len);
typedef void (*TSClusterStatusFunction) (TSNodeHandle_t *node, TSNodeStatus_t
s);
* Get the struct in_addr associated with the TSNodeHandle_t.*
tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in);
* Get the TSNodeHandle_t for the local node.*
tsapi void TSGetMyNodeHandle(TSNodeHandle_t *h);
tsapi int TSSendClusterRPC(TSNodeHandle_t *nh, TSClusterRPCMsg_t *msg);
{code}
As far as I can tell, TSNodeHandle_t is also how we represent the IP of the
cluster node. And since it's an int, it can only represent IPv4 addresses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1810) IPv6 for Cluster management
[
https://issues.apache.org/jira/browse/TS-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1810:
--
Fix Version/s: sometime
> IPv6 for Cluster management
> ---
>
> Key: TS-1810
> URL: https://issues.apache.org/jira/browse/TS-1810
> Project: Traffic Server
> Issue Type: Improvement
> Components: Clustering
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> It seems the management APIs (at least) for clustering are not IPv6 aware.
> E.g.
> {code}
> typedef int TSNodeHandle_t;
> typedef void (*TSClusterRPCFunction) (TSNodeHandle_t *node,
> TSClusterRPCMsg_t *msg, int msg_data_len);
> typedef void (*TSClusterStatusFunction) (TSNodeHandle_t *node,
> TSNodeStatus_t s);
>* Get the struct in_addr associated with the TSNodeHandle_t. *
> tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in);
>* Get the TSNodeHandle_t for the local node. *
> tsapi void TSGetMyNodeHandle(TSNodeHandle_t *h);
> tsapi int TSSendClusterRPC(TSNodeHandle_t *nh, TSClusterRPCMsg_t *msg);
> {code}
> As far as I can tell, TSNodeHandle_t is also how we represent the IP of the
> cluster node. And since it's an int, it can only represent IPv4 addresses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1811) Reduce HostDB entry sizes based on SRV being enabled or not
Leif Hedstrom created TS-1811: - Summary: Reduce HostDB entry sizes based on SRV being enabled or not Key: TS-1811 URL: https://issues.apache.org/jira/browse/TS-1811 Project: Traffic Server Issue Type: Improvement Components: DNS Reporter: Leif Hedstrom It seems that reserving the large (~3x or so) amount of space for SRV records in HostDB entries is a bit wasteful. Since SRV records aren't enabled by default, and I'd venture a guess that most people never will use it, we ought to adjust this such that the HostDB is set to a size appropriate for if SRV records are supported or not. This also implies that the HostDB needs to know if it's initialized for SRV records or not. And if we change the config, to reinitialize the HostDB. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1810) IPv6 for Cluster management
[
https://issues.apache.org/jira/browse/TS-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1810:
--
Fix Version/s: (was: sometime)
3.3.3
> IPv6 for Cluster management
> ---
>
> Key: TS-1810
> URL: https://issues.apache.org/jira/browse/TS-1810
> Project: Traffic Server
> Issue Type: Improvement
> Components: Clustering
>Reporter: Leif Hedstrom
> Fix For: 3.3.3
>
>
> It seems the management APIs (at least) for clustering are not IPv6 aware.
> E.g.
> {code}
> typedef int TSNodeHandle_t;
> typedef void (*TSClusterRPCFunction) (TSNodeHandle_t *node,
> TSClusterRPCMsg_t *msg, int msg_data_len);
> typedef void (*TSClusterStatusFunction) (TSNodeHandle_t *node,
> TSNodeStatus_t s);
>* Get the struct in_addr associated with the TSNodeHandle_t. *
> tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in);
>* Get the TSNodeHandle_t for the local node. *
> tsapi void TSGetMyNodeHandle(TSNodeHandle_t *h);
> tsapi int TSSendClusterRPC(TSNodeHandle_t *nh, TSClusterRPCMsg_t *msg);
> {code}
> As far as I can tell, TSNodeHandle_t is also how we represent the IP of the
> cluster node. And since it's an int, it can only represent IPv4 addresses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1810) IPv6 for Cluster management
[
https://issues.apache.org/jira/browse/TS-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1810:
--
Fix Version/s: (was: 3.3.3)
sometime
> IPv6 for Cluster management
> ---
>
> Key: TS-1810
> URL: https://issues.apache.org/jira/browse/TS-1810
> Project: Traffic Server
> Issue Type: Improvement
> Components: Clustering
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> It seems the management APIs (at least) for clustering are not IPv6 aware.
> E.g.
> {code}
> typedef int TSNodeHandle_t;
> typedef void (*TSClusterRPCFunction) (TSNodeHandle_t *node,
> TSClusterRPCMsg_t *msg, int msg_data_len);
> typedef void (*TSClusterStatusFunction) (TSNodeHandle_t *node,
> TSNodeStatus_t s);
>* Get the struct in_addr associated with the TSNodeHandle_t. *
> tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in);
>* Get the TSNodeHandle_t for the local node. *
> tsapi void TSGetMyNodeHandle(TSNodeHandle_t *h);
> tsapi int TSSendClusterRPC(TSNodeHandle_t *nh, TSClusterRPCMsg_t *msg);
> {code}
> As far as I can tell, TSNodeHandle_t is also how we represent the IP of the
> cluster node. And since it's an int, it can only represent IPv4 addresses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1811) Reduce HostDB entry sizes based on SRV being enabled or not
[ https://issues.apache.org/jira/browse/TS-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1811: -- Fix Version/s: 3.3.3 > Reduce HostDB entry sizes based on SRV being enabled or not > --- > > Key: TS-1811 > URL: https://issues.apache.org/jira/browse/TS-1811 > Project: Traffic Server > Issue Type: Improvement > Components: DNS >Reporter: Leif Hedstrom > Fix For: 3.3.3 > > > It seems that reserving the large (~3x or so) amount of space for SRV records > in HostDB entries is a bit wasteful. Since SRV records aren't enabled by > default, and I'd venture a guess that most people never will use it, we ought > to adjust this such that the HostDB is set to a size appropriate for if SRV > records are supported or not. > This also implies that the HostDB needs to know if it's initialized for SRV > records or not. And if we change the config, to reinitialize the HostDB. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1812) remove syslog_thr_init
James Peach created TS-1812: --- Summary: remove syslog_thr_init Key: TS-1812 URL: https://issues.apache.org/jira/browse/TS-1812 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: James Peach The comments in proxy/Main.cc indicate that syslog_thr_init() used to be there to support DEC Alpha. Since Alpha is dead and syslog_thr_init() doesn't actuly o anything any more, let's remove it so that we don't have to put it in silly stubs everywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1812) remove syslog_thr_init
[ https://issues.apache.org/jira/browse/TS-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1812: Fix Version/s: 3.3.2 Assignee: James Peach > remove syslog_thr_init > -- > > Key: TS-1812 > URL: https://issues.apache.org/jira/browse/TS-1812 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > The comments in proxy/Main.cc indicate that syslog_thr_init() used to be > there to support DEC Alpha. Since Alpha is dead and syslog_thr_init() doesn't > actuly o anything any more, let's remove it so that we don't have to put it > in silly stubs everywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-621: - Fix Version/s: (was: 3.3.3) 3.3.2 > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak > Fix For: 3.3.2 > > Attachments: force_empty.diff, > TS-621_cluster_zero_size_objects.patch, ts-621-jp-1.patch, ts-621-jp-2.patch, > ts-621-jp-3.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-621: Assignee: Leif Hedstrom > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: Leif Hedstrom > Fix For: 3.3.2 > > Attachments: force_empty.diff, > TS-621_cluster_zero_size_objects.patch, ts-621-jp-1.patch, ts-621-jp-2.patch, > ts-621-jp-3.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630606#comment-13630606 ] Leif Hedstrom commented on TS-621: -- I'm going to make a few cosmetic changes, and commit this on behalf of binchen. > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: Leif Hedstrom > Fix For: 3.3.2 > > Attachments: force_empty.diff, > TS-621_cluster_zero_size_objects.patch, ts-621-jp-1.patch, ts-621-jp-2.patch, > ts-621-jp-3.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1813) TSTextLogObjects don't roll
Brian Geffon created TS-1813: Summary: TSTextLogObjects don't roll Key: TS-1813 URL: https://issues.apache.org/jira/browse/TS-1813 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Brian Geffon When you create a TextLogObject you're allowed to specify when the log will roll; however, trafficserver never actually rolls the log because it never enumerates the API Managed log objects when rolling. Patch incoming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1813) TSTextLogObjects don't roll
[ https://issues.apache.org/jira/browse/TS-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1813: Assignee: Brian Geffon > TSTextLogObjects don't roll > --- > > Key: TS-1813 > URL: https://issues.apache.org/jira/browse/TS-1813 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Brian Geffon >Assignee: Brian Geffon > > When you create a TextLogObject you're allowed to specify when the log will > roll; however, trafficserver never actually rolls the log because it never > enumerates the API Managed log objects when rolling. Patch incoming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1813) TSTextLogObjects don't roll
[ https://issues.apache.org/jira/browse/TS-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1813: - Fix Version/s: 3.3.2 > TSTextLogObjects don't roll > --- > > Key: TS-1813 > URL: https://issues.apache.org/jira/browse/TS-1813 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.2 > > > When you create a TextLogObject you're allowed to specify when the log will > roll; however, trafficserver never actually rolls the log because it never > enumerates the API Managed log objects when rolling. Patch incoming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1813) TSTextLogObjects don't roll
[ https://issues.apache.org/jira/browse/TS-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1813: - Fix Version/s: (was: 3.3.2) 3.2.5 > TSTextLogObjects don't roll > --- > > Key: TS-1813 > URL: https://issues.apache.org/jira/browse/TS-1813 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.2.5 > > Attachments: LogObject.patch > > > When you create a TextLogObject you're allowed to specify when the log will > roll; however, trafficserver never actually rolls the log because it never > enumerates the API Managed log objects when rolling. Patch incoming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1813) TSTextLogObjects don't roll, backport 3.2.x
[ https://issues.apache.org/jira/browse/TS-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1813: - Summary: TSTextLogObjects don't roll, backport 3.2.x (was: TSTextLogObjects don't roll) > TSTextLogObjects don't roll, backport 3.2.x > --- > > Key: TS-1813 > URL: https://issues.apache.org/jira/browse/TS-1813 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.2.5 > > Attachments: LogObject.patch > > > When you create a TextLogObject you're allowed to specify when the log will > roll; however, trafficserver never actually rolls the log because it never > enumerates the API Managed log objects when rolling. Patch incoming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1813) TSTextLogObjects don't roll, backport 3.2.x
[ https://issues.apache.org/jira/browse/TS-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1813: - Attachment: LogObject.patch > TSTextLogObjects don't roll, backport 3.2.x > --- > > Key: TS-1813 > URL: https://issues.apache.org/jira/browse/TS-1813 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.2.5 > > Attachments: LogObject.patch > > > When you create a TextLogObject you're allowed to specify when the log will > roll; however, trafficserver never actually rolls the log because it never > enumerates the API Managed log objects when rolling. Patch incoming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1813) TSTextLogObjects don't roll, backport 3.2.x
[ https://issues.apache.org/jira/browse/TS-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1813: - Description: When you create a TextLogObject you're allowed to specify when the log will roll; however, trafficserver never actually rolls the log because it never enumerates the API Managed log objects when rolling. (was: When you create a TextLogObject you're allowed to specify when the log will roll; however, trafficserver never actually rolls the log because it never enumerates the API Managed log objects when rolling. Patch incoming.) > TSTextLogObjects don't roll, backport 3.2.x > --- > > Key: TS-1813 > URL: https://issues.apache.org/jira/browse/TS-1813 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.2.5 > > Attachments: LogObject.patch > > > When you create a TextLogObject you're allowed to specify when the log will > roll; however, trafficserver never actually rolls the log because it never > enumerates the API Managed log objects when rolling. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630643#comment-13630643 ] ASF subversion and git services commented on TS-621: Commit e2aff41f8d68144a0e90b1412c6006b784769af4 in branch refs/heads/master from Leif Hedstrom [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e2aff41 ] TS-621 Allow caching of empty docs (currently only if a header Content-Length: 0 is in the response). New config option is named proxy.config.http.cache.allow_empty_doc, and is disabled by default. We are aware this doesn't fully fix the problem, but is "good enough" for now. Reviews and minor cosmetic cleanup changes: James and Leif. > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: Leif Hedstrom > Fix For: 3.3.2 > > Attachments: force_empty.diff, > TS-621_cluster_zero_size_objects.patch, ts-621-jp-1.patch, ts-621-jp-2.patch, > ts-621-jp-3.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1814) We only allow caching zero-length documents if there is an explicit Content-Length: 0 header.
Leif Hedstrom created TS-1814: - Summary: We only allow caching zero-length documents if there is an explicit Content-Length: 0 header. Key: TS-1814 URL: https://issues.apache.org/jira/browse/TS-1814 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom See TS-621 for more details, which has the partial fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1814) We only allow caching zero-length documents if there is an explicit Content-Length: 0 header.
[ https://issues.apache.org/jira/browse/TS-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1814: -- Fix Version/s: sometime > We only allow caching zero-length documents if there is an explicit > Content-Length: 0 header. > - > > Key: TS-1814 > URL: https://issues.apache.org/jira/browse/TS-1814 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom > Fix For: sometime > > > See TS-621 for more details, which has the partial fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630673#comment-13630673 ] Leif Hedstrom commented on TS-745: -- Couple of things with the latest patch: 1) Configuration for this does most certainly not belong in records.config. It should be integrated with storage.config (and perhaps hosting.config and volumes.config as well). 2) I dislike that we use the variable/method/config names with "SSD" in them. The configure option is to enable tiered storage, and I think the code and configs should reflect this as well. > Support ssd > --- > > Key: TS-745 > URL: https://issues.apache.org/jira/browse/TS-745 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: mohan_zl >Assignee: weijin > Fix For: 3.3.4 > > Attachments: ts-745.diff, TS-ssd-2.patch, TS-ssd.patch > > > A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
