[jira] [Created] (TS-1106) redirect map generates multiple Via: header entries.
redirect map generates multiple Via: header entries. Key: TS-1106 URL: https://issues.apache.org/jira/browse/TS-1106 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.2 Reporter: Leif Hedstrom Fix For: 3.1.3 It seems using the redirect rule in remap.config, ends up duplicating the entry in the Via: header, e.g. {code} Via: http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p eS:tNc i p s ]), http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p eS:tNc i p s ]) {code} I'm not sure why this happens, if it's duplicating it, or if it's going through the SM twice. I know i'm not proxying twice through the box. -- 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-1105) HttpTransactCache assertion failure: response->status_get() != HTTP_STATUS_RANGE_NOT_SATISFIABLE
[ https://issues.apache.org/jira/browse/TS-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204035#comment-13204035 ] Leif Hedstrom commented on TS-1105: --- Yeah, please keep us informed. And particularly, if it's a regression or new bug, how to reproduce it. > HttpTransactCache assertion failure: response->status_get() != > HTTP_STATUS_RANGE_NOT_SATISFIABLE > - > > Key: TS-1105 > URL: https://issues.apache.org/jira/browse/TS-1105 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.1.2 > Environment: [Feb 8 09:47:05.828] Manager {0x2ae1ee56bcf0} NOTE: > [ClusterCom::ClusterCom] Node running on OS: 'Linux' Release: > '2.6.18-194.3.1.el5' > VMWare VM - 64-bit Centos 5.5 >Reporter: David Eagen > > FATAL: HttpTransactCache.cc:1317: failed assert `response->status_get() != > HTTP_STATUS_RANGE_NOT_SATISFIABLE` > /opt/trafficserver/bin/traffic_server - STACK TRACE: > /opt/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xb6)[0x2b60eecbaebe] > /opt/trafficserver/lib/libtsutil.so.3(ink_fatal+0xe4)[0x2b60eecbb096] > /opt/trafficserver/lib/libtsutil.so.3(_ink_assert+0x37)[0x2b60eecb9357] > /opt/trafficserver/bin/traffic_server(_ZN17HttpTransactCache38match_response_to_request_conditionalsEP7HTTPHdrS1_+0x86)[0x57e504] > /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0xb0)[0x59a426] > /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x112a)[0x59d1e8] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x69)[0x56547d] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x130)[0x57925c] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x39)[0x57d5a3] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x69)[0x5774d1] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x142)[0x565556] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x130)[0x57925c] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x39)[0x57d5a3] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x69)[0x5774d1] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x142)[0x565556] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x360)[0x5748cc] > /opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2fe)[0x572b1a] > /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] > /opt/trafficserver/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1c3)[0x552e39] > /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] > /opt/trafficserver/bin/traffic_server(_ZN7CacheVC8callcontEi+0x87)[0x6b03b7] > /opt/trafficserver/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0xf9b)[0x6aa8c1] > /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] > /opt/trafficserver/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0xae2)[0x6872a8] > /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] > /opt/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x3c)[0x68e2aa] > /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] > /opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x6fcba8] > /opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x94)[0x6fcd9a] > /opt/trafficserver/bin/traffic_server(main+0x1545)[0x5042cd] > /lib64/libc.so.6(__libc_start_main+0xf4)[0x3933c1d994] > /opt/trafficserver/bin/traffic_server[0x4b46d9] > [Feb 8 09:47:04.784] Manager {0x2afb63582cf0} FATAL: > [LocalManager::pollMgmtProcessServer] Error in read (errno: 104) > [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} FATAL: (last system error > 104: Connection reset by peer) > [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} NOTE: > [LocalManager::mgmtShutdown] Executing shutdown request. > [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} NOTE: > [LocalManager::processShutdown] Executing process shutdown request. > [Feb 8 09:47:04.786] Manager {0x2afb63582cf0} ERROR: > [LocalManager::sendMgmtMsgToProcesses] Error writing message > [Feb 8 09:47:04.786] Manager {0x2afb63582cf0} ERROR: (last system error 32: > Broken pipe) > [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/trafficserver' > This crash happened after upgrading 3.1.1 to 3.1.2. > Since it was related to the
[jira] [Updated] (TS-1105) HttpTransactCache assertion failure: response->status_get() != HTTP_STATUS_RANGE_NOT_SATISFIABLE
[ https://issues.apache.org/jira/browse/TS-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eagen updated TS-1105: Description: FATAL: HttpTransactCache.cc:1317: failed assert `response->status_get() != HTTP_STATUS_RANGE_NOT_SATISFIABLE` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xb6)[0x2b60eecbaebe] /opt/trafficserver/lib/libtsutil.so.3(ink_fatal+0xe4)[0x2b60eecbb096] /opt/trafficserver/lib/libtsutil.so.3(_ink_assert+0x37)[0x2b60eecb9357] /opt/trafficserver/bin/traffic_server(_ZN17HttpTransactCache38match_response_to_request_conditionalsEP7HTTPHdrS1_+0x86)[0x57e504] /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0xb0)[0x59a426] /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x112a)[0x59d1e8] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x69)[0x56547d] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x130)[0x57925c] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x39)[0x57d5a3] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x69)[0x5774d1] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x142)[0x565556] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x130)[0x57925c] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x39)[0x57d5a3] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x69)[0x5774d1] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x142)[0x565556] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x360)[0x5748cc] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2fe)[0x572b1a] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1c3)[0x552e39] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC8callcontEi+0x87)[0x6b03b7] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0xf9b)[0x6aa8c1] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0xae2)[0x6872a8] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x3c)[0x68e2aa] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x6fcba8] /opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x94)[0x6fcd9a] /opt/trafficserver/bin/traffic_server(main+0x1545)[0x5042cd] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3933c1d994] /opt/trafficserver/bin/traffic_server[0x4b46d9] [Feb 8 09:47:04.784] Manager {0x2afb63582cf0} FATAL: [LocalManager::pollMgmtProcessServer] Error in read (errno: 104) [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} FATAL: (last system error 104: Connection reset by peer) [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} NOTE: [LocalManager::mgmtShutdown] Executing shutdown request. [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} NOTE: [LocalManager::processShutdown] Executing process shutdown request. [Feb 8 09:47:04.786] Manager {0x2afb63582cf0} ERROR: [LocalManager::sendMgmtMsgToProcesses] Error writing message [Feb 8 09:47:04.786] Manager {0x2afb63582cf0} ERROR: (last system error 32: Broken pipe) [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/trafficserver' This crash happened after upgrading 3.1.1 to 3.1.2. Since it was related to the cache I have stopped ATS, removed the cache.db and host.db files, and started it again. Perhaps that was some sort of incompatability there. We'll see how it runs over the next couple of days. was: FATAL: HttpTransactCache.cc:1317: failed assert `response->status_get() != HTTP_STATUS_RANGE_NOT_SATISFIABLE` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xb6)[0x2b60eecbaebe] /opt/trafficserver/lib/libtsutil.so.3(ink_fatal+0xe4)[0x2b60eecbb096] /opt/trafficserver/lib/libtsutil.so.3(_ink_assert+0x37)[0x2b60eecb9357] /opt/trafficserver/bin/traffic_server(_ZN17HttpTransactCache38match_response_to_request_conditionalsEP7HTTPHdrS1_+0x86)[0x57e504] /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0xb0)[0x59a426] /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEP
[jira] [Created] (TS-1105) HttpTrasactCache assertion failure: response->status_get() != HTTP_STATUS_RANGE_NOT_SATISFIABLE
HttpTrasactCache assertion failure: response->status_get() != HTTP_STATUS_RANGE_NOT_SATISFIABLE Key: TS-1105 URL: https://issues.apache.org/jira/browse/TS-1105 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.2 Environment: [Feb 8 09:47:05.828] Manager {0x2ae1ee56bcf0} NOTE: [ClusterCom::ClusterCom] Node running on OS: 'Linux' Release: '2.6.18-194.3.1.el5' VMWare VM - 64-bit Centos 5.5 Reporter: David Eagen FATAL: HttpTransactCache.cc:1317: failed assert `response->status_get() != HTTP_STATUS_RANGE_NOT_SATISFIABLE` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xb6)[0x2b60eecbaebe] /opt/trafficserver/lib/libtsutil.so.3(ink_fatal+0xe4)[0x2b60eecbb096] /opt/trafficserver/lib/libtsutil.so.3(_ink_assert+0x37)[0x2b60eecb9357] /opt/trafficserver/bin/traffic_server(_ZN17HttpTransactCache38match_response_to_request_conditionalsEP7HTTPHdrS1_+0x86)[0x57e504] /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0xb0)[0x59a426] /opt/trafficserver/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x112a)[0x59d1e8] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x69)[0x56547d] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x130)[0x57925c] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x39)[0x57d5a3] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x69)[0x5774d1] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x142)[0x565556] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x130)[0x57925c] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x39)[0x57d5a3] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x69)[0x5774d1] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x142)[0x565556] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x360)[0x5748cc] /opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2fe)[0x572b1a] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1c3)[0x552e39] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC8callcontEi+0x87)[0x6b03b7] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0xf9b)[0x6aa8c1] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0xae2)[0x6872a8] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x3c)[0x68e2aa] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d5965] /opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x6fcba8] /opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x94)[0x6fcd9a] /opt/trafficserver/bin/traffic_server(main+0x1545)[0x5042cd] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3933c1d994] /opt/trafficserver/bin/traffic_server[0x4b46d9] [Feb 8 09:47:04.784] Manager {0x2afb63582cf0} FATAL: [LocalManager::pollMgmtProcessServer] Error in read (errno: 104) [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} FATAL: (last system error 104: Connection reset by peer) [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} NOTE: [LocalManager::mgmtShutdown] Executing shutdown request. [Feb 8 09:47:04.785] Manager {0x2afb63582cf0} NOTE: [LocalManager::processShutdown] Executing process shutdown request. [Feb 8 09:47:04.786] Manager {0x2afb63582cf0} ERROR: [LocalManager::sendMgmtMsgToProcesses] Error writing message [Feb 8 09:47:04.786] Manager {0x2afb63582cf0} ERROR: (last system error 32: Broken pipe) [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/trafficserver' -- 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-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203647#comment-13203647 ] Leif Hedstrom commented on TS-1102: --- Yeah, all other build-bots are happy. And yes, icc is generally "gcc 4.x" compatible, and I think llvm tries to be as well. Solaris is well, Solaris, so no big surprise there ... I have a Solaris build box I can test it on as well, but, this is why we have the buildbots in the first place. :) I'll probably spend some time next to get both icc and llvm to compile again, and then we should aim to get buildbots for those as well. Thanks for taking the time to work on this, we really appreciate it, and of course, we welcome all new (and old :) committers to work with the project. > Cleanup obsolete debugging code > --- > > Key: TS-1102 > URL: https://issues.apache.org/jira/browse/TS-1102 > Project: Traffic Server > Issue Type: Bug > Components: Core, Logging, Performance >Affects Versions: 3.0.2 > Environment: Any >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.3 > > Attachments: diags_cleanup.patch, remove_prefix_arg.patch, > remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc >= 4.1 > for all compilation environments, and it includes variadic argument macro > support with ##_VA_ARGS_ that deletes the final comma if no arguments are > provided. > Removing the added layer should also improve performance when high volume > debugging is turned on. -- 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-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203646#comment-13203646 ] Uri Shachar commented on TS-1102: - clang/llvm claim to support this out of the box. Intel icc as well, though it might issue a warning about not being strict C99 compatible (depending on compiler version). Solaris has #__VA_ARGS__ which does exactly the same thing (Missing the additional # just to be different :-( ), and might also require a "#pragma error_messages (off, E_ARGUEMENT_MISMATCH)". I'll generate a patch for solaris compiler, but I don't have access to a solaris machine to test it. Could you verify that the other build-bots pass ok before I get to work on this? > Cleanup obsolete debugging code > --- > > Key: TS-1102 > URL: https://issues.apache.org/jira/browse/TS-1102 > Project: Traffic Server > Issue Type: Bug > Components: Core, Logging, Performance >Affects Versions: 3.0.2 > Environment: Any >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.3 > > Attachments: diags_cleanup.patch, remove_prefix_arg.patch, > remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc >= 4.1 > for all compilation environments, and it includes variadic argument macro > support with ##_VA_ARGS_ that deletes the final comma if no arguments are > provided. > Removing the added layer should also improve performance when high volume > debugging is turned on. -- 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-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203624#comment-13203624 ] Leif Hedstrom commented on TS-1102: --- Yeah, sorry. What it really means is that we don't support e.g gcc 3.x and earlier. We still want to support as many "modern" compilers as possible, eg Intel icc and clang/llvm. If you could, fixing this would be great. > Cleanup obsolete debugging code > --- > > Key: TS-1102 > URL: https://issues.apache.org/jira/browse/TS-1102 > Project: Traffic Server > Issue Type: Bug > Components: Core, Logging, Performance >Affects Versions: 3.0.2 > Environment: Any >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.3 > > Attachments: diags_cleanup.patch, remove_prefix_arg.patch, > remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc >= 4.1 > for all compilation environments, and it includes variadic argument macro > support with ##_VA_ARGS_ that deletes the final comma if no arguments are > provided. > Removing the added layer should also improve performance when high volume > debugging is turned on. -- 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
Re: [jira] [Commented] (TS-1102) Cleanup obsolete debugging code
The wiki needs updating then. We can compile with Solaris Studio on Solaris, anyway. Once upon a time we also could compile with llvm/clang (Right now, only Mac OS X' XCode)
[jira] [Commented] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203392#comment-13203392 ] Uri Shachar commented on TS-1102: - Could it be that we aren't compiling with gcc (Seems like it: -errof isn't a gcc flag)? The patch assumes gcc usage (which is what the build wiki page specifies), I can probably get it working on solaris as well with some ifdefs - but it won't look as good... > Cleanup obsolete debugging code > --- > > Key: TS-1102 > URL: https://issues.apache.org/jira/browse/TS-1102 > Project: Traffic Server > Issue Type: Bug > Components: Core, Logging, Performance >Affects Versions: 3.0.2 > Environment: Any >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.3 > > Attachments: diags_cleanup.patch, remove_prefix_arg.patch, > remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc >= 4.1 > for all compilation environments, and it includes variadic argument macro > support with ##_VA_ARGS_ that deletes the final comma if no arguments are > provided. > Removing the added layer should also improve performance when high volume > debugging is turned on. -- 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