[jira] [Assigned] (TS-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić reassigned TS-1019:
--
Assignee: Igor Galić
> clean up access to librecords and remove wrappers
> -
>
> Key: TS-1019
> URL: https://issues.apache.org/jira/browse/TS-1019
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Bryan Call
>Assignee: Igor Galić
>Priority: Minor
>
> There are unneeded define wrappers around the librecord function calls:
> {noformat}
> [bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
> * | grep define
> iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
> REC_ConfigReadInteger
> proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
> {noformat}
--
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-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1019:
---
23:20:02 <@bcall> I think we should use librecords directly and remove the
#defines
> clean up access to librecords and remove wrappers
> -
>
> Key: TS-1019
> URL: https://issues.apache.org/jira/browse/TS-1019
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Bryan Call
>Priority: Minor
>
> There are unneeded define wrappers around the librecord function calls:
> {noformat}
> [bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
> * | grep define
> iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
> REC_ConfigReadInteger
> proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
> {noformat}
--
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-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1019:
---
Description:
There are unneeded define wrappers around the librecord function calls:
{noformat}
[bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger *
| grep define
iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
REC_ConfigReadInteger
proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
REC_ConfigReadInteger
proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
{noformat}
was:
There are unneeded define wrappers around the librecord function calls:
[bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger *
| grep define
iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
REC_ConfigReadInteger
proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
REC_ConfigReadInteger
proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
> clean up access to librecords and remove wrappers
> -
>
> Key: TS-1019
> URL: https://issues.apache.org/jira/browse/TS-1019
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Bryan Call
>Priority: Minor
>
> There are unneeded define wrappers around the librecord function calls:
> {noformat}
> [bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
> * | grep define
> iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
> REC_ConfigReadInteger
> proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
> {noformat}
--
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-1019) clean up access to librecords and remove wrappers
clean up access to librecords and remove wrappers - Key: TS-1019 URL: https://issues.apache.org/jira/browse/TS-1019 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Bryan Call Priority: Minor There are unneeded define wrappers around the librecord function calls: [bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger * | grep define iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger REC_ConfigReadInteger proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger REC_ConfigReadInteger proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger REC_ConfigReadInteger proxy/logging/LogConfig.h:#define LOG_LocalReadInteger REC_ConfigReadInteger proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger -- 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-462) Support TLS Server Name Indication (SNI) negotiation
[
https://issues.apache.org/jira/browse/TS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148044#comment-13148044
]
Igor Galić commented on TS-462:
---
We've come to the using conclusion that putting the whole thing into
{{remap.config}} is not quite sensible.
However, putting it into {{ssl_multicert.config}} is. e.g.:
{noformat}
src_domain=secure.apache.org ssl_cert_name=secure.a.o.cert
ssl_key_name=secure.a.o.key
src_domain=shop.openoffice.org ssl_cert_name=shop.ooo.cert
ssl_key_name=shop.ooo.key
{noformat}
> Support TLS Server Name Indication (SNI) negotiation
>
>
> Key: TS-462
> URL: https://issues.apache.org/jira/browse/TS-462
> Project: Traffic Server
> Issue Type: New Feature
> Components: SSL
>Affects Versions: 3.0.0
>Reporter: Leif Hedstrom
>Assignee: Igor Galić
>Priority: Minor
> Labels: ssl
> Fix For: 3.1.4
>
>
> We should support TLS Server Name Indication (SNI). This would allow for well
> behaved TLS clients to negotiate the certificate, without requiring a new IP
> for every site / certificate used.
--
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-1013) Allow ssl_multicert.config to support CA chains per host
[
https://issues.apache.org/jira/browse/TS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148040#comment-13148040
]
Igor Galić commented on TS-1013:
No. SNI is a separate issue - but now that I've cleaned those code paths and
got to know the code it's much easier to work on TS-462.
> Allow ssl_multicert.config to support CA chains per host
>
>
> Key: TS-1013
> URL: https://issues.apache.org/jira/browse/TS-1013
> Project: Traffic Server
> Issue Type: New Feature
> Components: SSL
>Affects Versions: 3.1.1, 3.0.1
>Reporter: Igor Galić
>Assignee: Igor Galić
> Labels: ssl
> Attachments: ssl_multi_ca.patch, ssl_multi_ca_trunk.patch
>
>
> Allow ssl_multicert.config to support CA chains per host, i.e.:
> {noformat}
> dst_ip=12.34.24.253 ssl_cert=foo.pem ssl_ca_name=fooCAs.pem ssl_key_name
> {noformat}
--
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] [Work started] (TS-1013) Allow ssl_multicert.config to support CA chains per host
[
https://issues.apache.org/jira/browse/TS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-1013 started by Igor Galić.
> Allow ssl_multicert.config to support CA chains per host
>
>
> Key: TS-1013
> URL: https://issues.apache.org/jira/browse/TS-1013
> Project: Traffic Server
> Issue Type: New Feature
> Components: SSL
>Affects Versions: 3.1.1, 3.0.1
>Reporter: Igor Galić
>Assignee: Igor Galić
> Labels: ssl
> Attachments: ssl_multi_ca.patch, ssl_multi_ca_trunk.patch
>
>
> Allow ssl_multicert.config to support CA chains per host, i.e.:
> {noformat}
> dst_ip=12.34.24.253 ssl_cert=foo.pem ssl_ca_name=fooCAs.pem ssl_key_name
> {noformat}
--
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-857) Crash Report: HttpTunnel::chain_abort_all -> HttpServerSession::do_io_close -> UnixNetVConnection::do_io_close
[
https://issues.apache.org/jira/browse/TS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weijin updated TS-857:
--
Attachment: ts-854.diff
This patch make net_vc::do_io_close thread safe, and it is simple and have no
need to lock vc`s mutex. In my test, the crash did not happen again, I think we
should have more test.
> Crash Report: HttpTunnel::chain_abort_all -> HttpServerSession::do_io_close
> -> UnixNetVConnection::do_io_close
> --
>
> Key: TS-857
> URL: https://issues.apache.org/jira/browse/TS-857
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Affects Versions: 3.1.0
> Environment: in my branch that is something same as 3.0.x
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 3.1.2
>
> Attachments: ts-854.diff
>
>
> here is the bt from the crash, some of the information is missing due to we
> have not enable the --enable-debug configure options.
> {code}
> [New process 7532]
> #0 ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> 68fp = (void **) (*fp);
> (gdb) bt
> #0 ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> #1 0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame= optimized out>) at ink_stack_trace.cc:114
> #2 0x004df020 in signal_handler (sig=) at
> signals.cc:225
> #3
> #4 0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
> alerrno=)
> at ../../iocore/eventsystem/I_Lock.h:297
> #5 0x0051f1d0 in HttpServerSession::do_io_close
> (this=0x2aaab0042c80, alerrno=20600) at HttpServerSession.cc:127
> #6 0x0056d1e9 in HttpTunnel::chain_abort_all (this=0x2aabeeffdd70,
> p=0x2aabeeffdf68) at HttpTunnel.cc:1300
> #7 0x005269ca in HttpSM::tunnel_handler_ua (this=0x2aabeeffc070,
> event=104, c=0x2aabeeffdda8) at HttpSM.cc:2987
> #8 0x00571dfc in HttpTunnel::consumer_handler (this=0x2aabeeffdd70,
> event=104, c=0x2aabeeffdda8) at HttpTunnel.cc:1232
> #9 0x00572032 in HttpTunnel::main_handler (this=0x2aabeeffdd70,
> event=1088608784, data=)
> at HttpTunnel.cc:1456
> #10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0,
> thread=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688,
> event=, e=0x171c1ed0) at UnixNet.cc:405
> #12 0x006cddaf in EThread::process_event (this=0x2b12c010,
> e=0x171c1ed0, calling_code=5) at I_Continuation.h:146
> #13 0x006ce6bc in EThread::execute (this=0x2b12c010) at
> UnixEThread.cc:262
> #14 0x006cd0ee in spawn_thread_internal (a=0x171b58f0) at Thread.cc:88
> #15 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
> #16 0x003c330d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x40e2b790:
> rip = 0x2ba641dccdf3 in ink_stack_trace_get(void**, int, int)
> (ink_stack_trace.cc:68); saved rip 0x2ba641dccef1
> called by frame at 0x40e2bbe0
> source language c++.
> Arglist at 0x40e2b770, args: stack=, len= optimized out>, signalhandler_frame=
> Locals at 0x40e2b770, Previous frame's sp is 0x40e2b790
> Saved registers:
> rbx at 0x40e2b778, rbp at 0x40e2b780, rip at 0x40e2b788
> (gdb)
> {code}
--
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-1013) Allow ssl_multicert.config to support CA chains per host
[
https://issues.apache.org/jira/browse/TS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147587#comment-13147587
]
bettydramit commented on TS-1013:
-
Does it support SNI???
> Allow ssl_multicert.config to support CA chains per host
>
>
> Key: TS-1013
> URL: https://issues.apache.org/jira/browse/TS-1013
> Project: Traffic Server
> Issue Type: New Feature
> Components: SSL
>Affects Versions: 3.1.1, 3.0.1
>Reporter: Igor Galić
>Assignee: Igor Galić
> Labels: ssl
> Attachments: ssl_multi_ca.patch, ssl_multi_ca_trunk.patch
>
>
> Allow ssl_multicert.config to support CA chains per host, i.e.:
> {noformat}
> dst_ip=12.34.24.253 ssl_cert=foo.pem ssl_ca_name=fooCAs.pem ssl_key_name
> {noformat}
--
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
