[jira] [Created] (TS-1299) WARNING: Could not set "x.x.x.x:8085" as collation host
bettydramit created TS-1299: --- Summary: WARNING: Could not set "x.x.x.x:8085" as collation host Key: TS-1299 URL: https://issues.apache.org/jira/browse/TS-1299 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.1.4 Environment: centos 6 x86_64 Reporter: bettydramit To configure a Traffic Server node to be a collation server and client when start the client i get follow warning: WARNING: Could not set "x.x.x.x:8085" as collation host my ats log could not send to collation server Refer to the following documents: https://svn.apache.org/repos/asf/trafficserver/site/trunk/content/docs/trunk/admin/working-log-files/index.en.mdtext -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1278) Clang warns: Volatile fields read but results discarded
[
https://issues.apache.org/jira/browse/TS-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1278:
---
Attachment: volatile.patch
A simple patch to move assert to the use of the volatile data
> Clang warns: Volatile fields read but results discarded
> ---
>
> Key: TS-1278
> URL: https://issues.apache.org/jira/browse/TS-1278
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: clang version 3.2 (trunk 157601)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
>Reporter: Igor Galić
> Attachments: volatile.patch
>
>
> {noformat}
> Making all in eventsystem
> make[2]: Entering directory
> `/home/igalic/src/asf/trafficserver/BUILD/iocore/eventsystem'
> CXXEventSystem.o
> In file included from ../../../iocore/eventsystem/EventSystem.cc:31:
> In file included from ../../../iocore/eventsystem/P_EventSystem.h:41:
> In file included from ../../../iocore/eventsystem/I_EventSystem.h:35:
> In file included from ../../../iocore/eventsystem/I_Action.h:30:
> In file included from ../../../iocore/eventsystem/I_Continuation.h:40:
> ../../../iocore/eventsystem/I_Lock.h:404:19: error: expression result unused;
> assign into a variable to force a volatile load
> [-Werror,-Wunused-volatile-lvalue]
> ink_assert(m->thread_holding);
> ~~^~~
> ../../../lib/ts/ink_assert.h:54:31: note: expanded from macro 'ink_assert'
> #define ink_assert(EX) (void)(EX)
> ^
> 1 error generated.
> make[2]: *** [EventSystem.o] Error 1
> {noformat}
> Discussion from {{#llvm}} on IRC:
> {noformat}
> < jMCg> volatile EThreadPtr thread_holding;
> <@baldrick> the clang warning sounds very sensible then
> < jMCg>
> http://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blob;f=iocore/eventsystem/I_Lock.h#l80
> < jMCg> The comment is great. "You must not modify or set this value
> directly." -- that's why it's public!
> < jMCg> baldrick: can you still help me understand it?
> <@baldrick> jMCg: reading a volatile variable may have side-effects (that's
> what volatile is for). For example, if it is mapped to some I/O area, each
> read could fire off a nuclear warhead for example.
> <@baldrick> jMCg: thus it seems sensible to warn if it looks like someone is
> readying it but not using the result.
> < jMCg> Oh. Now I'm back on track. *Reading* a volatile variable may have
> *side-effects* - sometimes I'm slow.
> < jMCg> baldrick: I'll open a Bug in our project. Thank you very much.
> {noformat}
> This is it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1295) make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293749#comment-13293749 ] Leif Hedstrom commented on TS-1295: --- Ah yes, I just s/==/!=/ :). I'll commit this now (with the unchange above), if you agree to the other changes I made? > make install should work as non-root user > - > > Key: TS-1295 > URL: https://issues.apache.org/jira/browse/TS-1295 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Jan-Frode Myklebust >Assignee: Leif Hedstrom >Priority: Trivial > Fix For: 3.3.0 > > Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff > > > "make install" should work as non-root user. Requirng root is bad practice > and causes problems for the fedora build system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1295) make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293870#comment-13293870 ] Jan-Frode Myklebust commented on TS-1295: - Yes, I agree to your superior formatting :-) Didn't know how to do that myself inside Makefile.am's... > make install should work as non-root user > - > > Key: TS-1295 > URL: https://issues.apache.org/jira/browse/TS-1295 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Jan-Frode Myklebust >Assignee: Leif Hedstrom >Priority: Trivial > Fix For: 3.3.0 > > Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff > > > "make install" should work as non-root user. Requirng root is bad practice > and causes problems for the fedora build system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-799) Have AdminClient.pm created from .in file
[ https://issues.apache.org/jira/browse/TS-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-799: - Fix Version/s: (was: 3.3.0) 3.3.1 > Have AdminClient.pm created from .in file > - > > Key: TS-799 > URL: https://issues.apache.org/jira/browse/TS-799 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Igor Galić >Priority: Trivial > Fix For: 3.3.1 > > > AdminClient.pm should be created from an .in file. > @sockets_def = should be extended with @localstatedir@ on top. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293942#comment-13293942 ] Leif Hedstrom commented on TS-993: -- Do we really need two bugs for this? We also have TS-1193. Can we mark one as duplicate, or at least change the subject title on one of them, if it really is a subtask? > Add OpenBSD support. > > > Key: TS-993 > URL: https://issues.apache.org/jira/browse/TS-993 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora > Fix For: 3.3.0 > > Attachments: 0001-Add-OpenBSD-support.patch > > > Add OpenBSD support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1261) enable keepalive/chunking when transforming from cache
[ https://issues.apache.org/jira/browse/TS-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1261: -- Fix Version/s: 3.3.0 Does this need work? Is this something briang needs to look at ? > enable keepalive/chunking when transforming from cache > -- > > Key: TS-1261 > URL: https://issues.apache.org/jira/browse/TS-1261 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.3 >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Labels: patch > Fix For: 3.3.0 > > Attachments: cache_transform_chunking.diff > > > when transforming a document from cache, we will currently either close the > connection, or send a content length header (probably when the full response > is buffered). sending chunked responses could help lowering latencies and > memory requirements in some use cases. > the attached patch has only been lab tested, and has not got any production > mileage yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1300) TSUrlStringGet appears to return incorrect URL for transparent HTTP requests
Domhnall Wildy created TS-1300: -- Summary: TSUrlStringGet appears to return incorrect URL for transparent HTTP requests Key: TS-1300 URL: https://issues.apache.org/jira/browse/TS-1300 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.2 Environment: Centos 6.2 Reporter: Domhnall Wildy We have a plugin that uses the TSUrlStringGet method to retrieve the request URL. When running TS as a non-transparent proxy the value returned by TSUrlStringGet is the full URL for example: http://www.somewebsite.com/something.html However if I send requests transparently the value returned is: http:///something.html So it looks as if the host is ignored when the URL string is initially created. I just wanted to check here to see if this could be an issue? Or could the usage of the method be incorrect? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1261) enable keepalive/chunking when transforming from cache
[ https://issues.apache.org/jira/browse/TS-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294182#comment-13294182 ] Otto van der Schaaf commented on TS-1261: - i think this is ok, and doesnt need work. > enable keepalive/chunking when transforming from cache > -- > > Key: TS-1261 > URL: https://issues.apache.org/jira/browse/TS-1261 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.3 >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Labels: patch > Fix For: 3.3.0 > > Attachments: cache_transform_chunking.diff > > > when transforming a document from cache, we will currently either close the > connection, or send a content length header (probably when the full response > is buffered). sending chunked responses could help lowering latencies and > memory requirements in some use cases. > the attached patch has only been lab tested, and has not got any production > mileage yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
