date:20130601

[jira] [Commented] (TS-1919) Eliminate CacheLookupHttpConfig

2013-06-01 Thread JIRA

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

Igor Galić commented on TS-1919:

If it breaks binary compatibility between clusters, I'd announce it in 3.4 and
change it in 3.6 (or whatever the version after 3.4 will be).

Eliminate CacheLookupHttpConfig
---

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

We have a notion of creating (and transmitting) a very tiny subset of
HttpConfigParams, in a struct named CacheLookupHttpConfig. As it turns out,
this is generally not used, and as far as I can tell, cluster config provides
the same / similar functionality (assuring that all nodes in the cluster uses
the same config). One complication with this CacheLookupHttpConfig struct is
that it sort of violates modularity, in that the I/O core, clustering and
HTTPSM share this partial HTTP config in a non-opaque way.
I have a patch that eliminates this (I'll post it later), but there are two
thoughts / questions I'd like to discuss.
1) Do we feel it adequate to use the cluster config mechanism of distributing
/ sharing configurations across the cluster? Or do we really think that it's
necessary to transfer the configs as part of every Cluster response message?
2) If we agree to eliminate the CacheLookupHttpConfig in favor of just using
HttpConfigParam's (which are synchronized between cluster nodes), how
important is it to preserve compatibility in the Cluster protocol? Right now,
my patch does not do this (I'd break clustering between e.g. ATS v3.2 and ATS
v3.4).
For 2), we have a few options, the cleanest probably involves knowing the
version of the Cluster message (does that exist today?). Before I go down
that route, I'd like to ask the people using clustering if they feel it
important to retain compatibility such that you can run a cluster with a mix
of v3.2 and v3.4 nodes.

--
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-1932) can not make asf-dist after merge of the docs

2013-06-01 Thread Zhao Yongming (JIRA)

Zhao Yongming created TS-1932:
-

 Summary: can not make asf-dist after merge of the docs
 Key: TS-1932
 URL: https://issues.apache.org/jira/browse/TS-1932
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: Zhao Yongming


{code}
rm -rf -- trafficserver-3.3.3-dev/autom4te.cache trafficserver-3.3.3-dev/.git 
trafficserver-3.3.3-dev/.gitignore
tardir=trafficserver-3.3.3-dev  ${TAR-tar} chof - $tardir | bzip2 -9 -c 
trafficserver-3.3.3-dev.tar.bz2
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/adding-statistics/viewing-statistics-using-traffic-line.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/http-hooks-and-transactions/intercepting-http-transactions.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/plugin-management/reading-trafficserver-settings-and-statistics.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/getting-started/plugin-registration-and-version-checking.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/http-headers/guide-to-trafficserver-http-header-system/release-marshal-buffer-handles.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/http-headers/guide-to-trafficserver-http-header-system/duplicate-mime-fields-are-not-coalesced.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/http-headers/guide-to-trafficserver-http-header-system/mime-fields-always-belong-to-an-associated-mime-header.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/http-transformation-plugin/sample-null-transformation-plugin.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/http-transformation-plugin/sample-buffered-null-transformation-plugin.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/basic-authorization-plugin/working-with-http-headers.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/basic-authorization-plugin/implementing-the-handler-and-getting-a-handle-to-the-transaction.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/basic-authorization-plugin/setting-a-transaction-hook.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/basic-authorization-plugin.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/blacklist-plugin/accessing-the-transaction-being-processed.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/blacklist-plugin/working-with-http-header-functions.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/blacklist-plugin/setting-up-a-transaction-hook.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/header-based-plugin-examples/blacklist-plugin/setting-a-global-hook.en.rst:
 file name is too long (max 99); not dumped
tar: 
trafficserver-3.3.3-dev/doc/source/sdk/how-to-create-trafficserver-plugins/roadmap-for-creating-plugins.en.rst:
 file name is too long (max 99); not dumped
tar: Exiting with failure status due to previous errors
[root@fc18150196 trafficserver]#

{code}

--
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

23 matches

Mail list logo