[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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
