[GitHub] thrift issue #930: THRIFT-3369 : Implement SSL/TLS support on C with c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 Again a problem with code outside the domain area. Can someone help me to fix this? Because it's failing on some places where I never touched. Should I continue doing rebase until everyone fixes their problems? What should I do? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839474#comment-15839474 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 Again a problem with code outside the domain area. Can someone help me to fix this? Because it's failing on some places where I never touched. Should I continue doing rebase until everyone fixes their problems? What should I do? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift issue #930: THRIFT-3369 : Implement SSL/TLS support on C with c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 I'm rebasing again... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839530#comment-15839530 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 I'm rebasing again... > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2945) Implement support for Rust language
[ https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839705#comment-15839705 ] Allen George commented on THRIFT-2945: -- [~anatolikus], [~jensg] - thank you for the kind words, it's really appreciated! I've definitely not completed work on this :) My top three priorities are: * Multi-threaded synchronous client * Multi-threaded synchronous server * JSON protocol Before I make these changes there are some internal house-keeping things I've to do, like adding macros to make it easier to write protocol and transport tests. > Implement support for Rust language > --- > > Key: THRIFT-2945 > URL: https://issues.apache.org/jira/browse/THRIFT-2945 > Project: Thrift > Issue Type: New Feature > Components: Rust - Compiler, Rust - Library >Reporter: Maksim Golov >Assignee: Allen George > Fix For: 0.11.0 > > > Work on implementing support for Rust is in progress: > https://github.com/maximg/thrift by Simon Génier and myself. > It will probably take quite some time to complete. Please keep us updated if > there are changes related to our work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003481 --- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_platform_socket.h --- @@ -0,0 +1,120 @@ +/* --- End diff -- This looks a lot like the platform socket code that already exists in the C++ library. Given their similarity should they be combined and moved into a common location? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003205 --- Diff: lib/c_glib/Makefile.am --- @@ -45,6 +45,7 @@ libthrift_c_glib_la_SOURCES = src/thrift/c_glib/thrift.c \ src/thrift/c_glib/transport/thrift_buffered_transport_factory.c \ src/thrift/c_glib/transport/thrift_framed_transport_factory.c \ src/thrift/c_glib/transport/thrift_socket.c \ + src/thrift/c_glib/transport/thrift_ssl_socket.c \ --- End diff -- Does this need to be conditional on openssl being found? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/930#discussion_r98003634
--- Diff: lib/c_glib/test/CMakeLists.txt ---
@@ -108,13 +108,6 @@ add_test(NAME testoptionalrequired COMMAND
testoptionalrequired)
include_directories("${PROJECT_SOURCE_DIR}/test/c_glib/src"
"${CMAKE_CURRENT_BINARY_DIR}/gen-c_glib")
-add_executable(testthrifttest testthrifttest.c
--- End diff --
Why was the testthrifttest executable removed?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003689 --- Diff: lib/c_glib/test/Makefile.am --- @@ -37,16 +37,17 @@ BUILT_SOURCES = \ gen-c_glib/t_test_thrift_test_types.h AM_CPPFLAGS = -I../src -I./gen-c_glib -AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) \ +AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) $(OPENSSL_INCLUDES) \ @GCOV_CFLAGS@ AM_CXXFLAGS = $(AM_CFLAGS) -AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) @GCOV_LDFLAGS@ +AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) $(OPENSSL_LIBS) @GCOV_LDFLAGS@ check_PROGRAMS = \ testserialization \ testapplicationexception \ testcontainertest \ testtransportsocket \ + testtransportsslsocket \ --- End diff -- Does this need to be conditional on openssl being found? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003039 --- Diff: configure.ac --- @@ -199,6 +196,12 @@ if test "$with_c_glib" = "yes"; then fi AM_CONDITIONAL(WITH_C_GLIB, [test "$have_glib2" = "yes" -a "$have_gobject2" = "yes"]) +echo "OpenSSL check" --- End diff -- There may be other libraries with native builds that need OpenSSL. Why are we making it conditional on cpp and c_glib library support? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98002795 --- Diff: lib/c_glib/test/owncloud.level2crm.pem --- @@ -0,0 +1,59 @@ +-BEGIN CERTIFICATE- +MIIFLDCCBBSgAwIBAgIBAzANBgkqhkiG9w0BAQsFADCBrTELMAkGA1UEBhMCRVMx +DzANBgNVBAgTBk1hZHJpZDEVMBMGA1UEBxMMVG9ycmVsb2RvbmVzMSswKQYDVQQK +EyJMZXZlbDIgU29sdWNpb25lcyBNYXJrZXRpbmcgMzYwIFNMMREwDwYDVQQLEwhT +aXN0ZW1hczEPMA0GA1UEAxMGTGV2ZWwyMSUwIwYJKoZIhvcNAQkBFhZnYWd1aWxh +ckBsZXZlbDJjcm0uY29tMB4XDTE1MDIxMzEyNDY0OVoXDTE3MDIwMjEyNDY0OVow +gaYxCzAJBgNVBAYTAkVTMQ8wDQYDVQQIEwZNYWRyaWQxKzApBgNVBAoTIkxldmVs +MiBTb2x1Y2lvbmVzIE1hcmtldGluZyAzNjAgU0wxETAPBgNVBAsTCFNpc3RlbWFz +MR8wHQYDVQQDExZvd25jbG91ZC5sZXZlbDJjcm0uY29tMSUwIwYJKoZIhvcNAQkB +FhZnYWd1aWxhckBsZXZlbDJjcm0uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A +MIIBCgKCAQEA9BH6ZPghzZQaWKG5Y3o/V41UDzJfkghfxhOzqZehn3dtpylMcA7i +qUi1N3Gf5S53GCl3JOm0sfdMhJr8UYBL1PwRnAo8ZOU678fofU7/2GgqAN+dtOO8 +X8JTar9zbANnJIR89fSXp4wQUbTKt7xbBezv8c/Cel6dlTSC8Dvc50ptksh5yue2 +SEuglFDtf7ru8EidROMgvUw4VAjusZXVirPKjv2rqWamgRsWizq9nkqJ71HjFweo +FYQRIuZ6qSDl3x7ZDV22kZth2LxFHRnv1E/SHbsvs0iEoKr9hF6xkdxyfHmlyd02 +oJOdlxEfHSREtuFDbDP/CcQy5oVbdM2EfQIDAQABo4IBWjCCAVYwCQYDVR0TBAIw +ADARBglghkgBhvhCAQEEBAMCBPAwCwYDVR0PBAQDAgXgMCUGCWCGSAGG+EIBDQQY +FhZMZXZlbDIgQ1JNIENlcnRpZmljYXRlMB0GA1UdDgQWBBTa17QOLz4WqHv0J6LP +KVVPsX721TCB4gYDVR0jBIHaMIHXgBTRF2IG48O6cMjz44Pwk5GbhUWX3aGBs6SB +sDCBrTELMAkGA1UEBhMCRVMxDzANBgNVBAgTBk1hZHJpZDEVMBMGA1UEBxMMVG9y +cmVsb2RvbmVzMSswKQYDVQQKEyJMZXZlbDIgU29sdWNpb25lcyBNYXJrZXRpbmcg +MzYwIFNMMREwDwYDVQQLEwhTaXN0ZW1hczEPMA0GA1UEAxMGTGV2ZWwyMSUwIwYJ +KoZIhvcNAQkBFhZnYWd1aWxhckBsZXZlbDJjcm0uY29tggkAqMKCeCp/2+wwDQYJ +KoZIhvcNAQELBQADggEBACy1UZR674b3yxEYnFPorhbD4CS65AfgLEObpvwbGvF8 +gLxJkxGhcsKEoxiBynnazdPzub8I9e0ZHsPjAyPupLrBeuUIBthmzdW3gUN9zZp1 +mRIurbiT3wlYCxl/cOa7MV7bCZSSqsC0WF9CLicRPFgyc6MDdRjsMufx+JkIdJZa +31jBweG/JzYm9pxdJFfnFcBEM+Kv3BcozoAAHcLHvv4cI4j5SpdzdCEgpgd6/LtI +i/grRayPlbQnqUrEOHLAuhAH+RflRTIFBGRRukLa7yqdY9J+qHDPLkxnLEmtyu4u +6GoZTYFtKnVZfubr+gku9Z8r2gF375InjOAifZH3ITE= +-END CERTIFICATE- +-BEGIN CERTIFICATE- +MIIFBDCCA+ygAwIBAgIJAKjCgngqf9vsMA0GCSqGSIb3DQEBCwUAMIGtMQswCQYD +VQQGEwJFUzEPMA0GA1UECBMGTWFkcmlkMRUwEwYDVQQHEwxUb3JyZWxvZG9uZXMx +KzApBgNVBAoTIkxldmVsMiBTb2x1Y2lvbmVzIE1hcmtldGluZyAzNjAgU0wxETAP +BgNVBAsTCFNpc3RlbWFzMQ8wDQYDVQQDEwZMZXZlbDIxJTAjBgkqhkiG9w0BCQEW +FmdhZ3VpbGFyQGxldmVsMmNybS5jb20wHhcNMTUwMTAxMTQyMDQ1WhcNMjQxMjI5 +MTQyMDQ1WjCBrTELMAkGA1UEBhMCRVMxDzANBgNVBAgTBk1hZHJpZDEVMBMGA1UE +BxMMVG9ycmVsb2RvbmVzMSswKQYDVQQKEyJMZXZlbDIgU29sdWNpb25lcyBNYXJr +ZXRpbmcgMzYwIFNMMREwDwYDVQQLEwhTaXN0ZW1hczEPMA0GA1UEAxMGTGV2ZWwy +MSUwIwYJKoZIhvcNAQkBFhZnYWd1aWxhckBsZXZlbDJjcm0uY29tMIIBIjANBgkq +hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2RJKzAzO8P0GT3FcnFMK3X9t4JE+mHMP +aPX5miBLaKH6rXclrfjYfzK3OESY5DhgZJ+Qzx5GyNl+hsSXpiIlNbWAEeJCIELG +OEz51zR0M2rQTC06UrWTtn2COQo2m91lv+Mwum+LSgqUPJ18dyKsmOFSVCsLOK+s +xZY7F5AF2+99kr1EFv0dcxS1BTRKOAQiMkuZEnFU95zXmm+U+vzenwX2V8XtTLip +e6+MezZTehvSZhbafKwFnw+vc36VGwrfhc+lH/1pc5etp4qcD9L0WvOhTmBUwWl/ +2hOU0XF5UYOkfsS1saot/WIsH6731Q/slYFCLXSrl+8R4+RxR9fozwIDAQABo4IB +IzCCAR8wHQYDVR0OBBYEFNEXYgbjw7pwyPPjg/CTkZuFRZfdMIHiBgNVHSMEgdow +gdeAFNEXYgbjw7pwyPPjg/CTkZuFRZfdoYGzpIGwMIGtMQswCQYDVQQGEwJFUzEP +MA0GA1UECBMGTWFkcmlkMRUwEwYDVQQHEwxUb3JyZWxvZG9uZXMxKzApBgNVBAoT +IkxldmVsMiBTb2x1Y2lvbmVzIE1hcmtldGluZyAzNjAgU0wxETAPBgNVBAsTCFNp +c3RlbWFzMQ8wDQYDVQQDEwZMZXZlbDIxJTAjBgkqhkiG9w0BCQEWFmdhZ3VpbGFy +QGxldmVsMmNybS5jb22CCQCowoJ4Kn/b7DAMBgNVHRMEBTADAQH/MAsGA1UdDwQE +AwIBBjANBgkqhkiG9w0BAQsFAAOCAQEAh2kPzv8jFNQbCrAD770m8T4W/KMhxMOv +Uhm/wSv7/g3Ir1pZ9LgXAWJx1qLQdCcOikBparkUpHIrqDU+wBL6o+CFNWp7WR6g +bft627bL9R3z3fTQHIchjPHQ7S4ID/STWfTqWDJQESBnTp1KTuJ8sMlvACMWZSUc +jZOAQIodNiUUNPkfreurPb9KH/nArwV/yTDoZMhiqoqNwOIY/0sxUJaNUAX3pgDd +FsGMBn4MiyGAw4XaK9LJBh+6DLH5D2Y7h0hXv+AUP3SSC+w5XA/D+SHcAbjtPzMW +cdq9jr1Gu0KO3PSGIAUpI1o+XQeLqgyieFcVF/FlD31MDC152DifNA== +-END CERTIFICATE- --- End diff -- This needs to be removed in favor of existing test keys. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839746#comment-15839746 ] ASF GitHub Bot commented on THRIFT-3369: Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003205 --- Diff: lib/c_glib/Makefile.am --- @@ -45,6 +45,7 @@ libthrift_c_glib_la_SOURCES = src/thrift/c_glib/thrift.c \ src/thrift/c_glib/transport/thrift_buffered_transport_factory.c \ src/thrift/c_glib/transport/thrift_framed_transport_factory.c \ src/thrift/c_glib/transport/thrift_socket.c \ + src/thrift/c_glib/transport/thrift_ssl_socket.c \ --- End diff -- Does this need to be conditional on openssl being found? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[
https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839748#comment-15839748
]
ASF GitHub Bot commented on THRIFT-3369:
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/930#discussion_r98003634
--- Diff: lib/c_glib/test/CMakeLists.txt ---
@@ -108,13 +108,6 @@ add_test(NAME testoptionalrequired COMMAND
testoptionalrequired)
include_directories("${PROJECT_SOURCE_DIR}/test/c_glib/src"
"${CMAKE_CURRENT_BINARY_DIR}/gen-c_glib")
-add_executable(testthrifttest testthrifttest.c
--- End diff --
Why was the testthrifttest executable removed?
> Implement SSL/TLS support on C with c_glib
> --
>
> Key: THRIFT-3369
> URL: https://issues.apache.org/jira/browse/THRIFT-3369
> Project: Thrift
> Issue Type: Improvement
> Components: C glib - Library
>Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0
>Reporter: Gonzalo Aguilar
> Labels: features, patch
>
> Implement SSL/TLS based on plain openssl instead of going through the way
> defined in THRIFT-1016.
> This help us to maintain a reference implementation and later switch over GIO
> or whatever is defined. But also does not add any other dependencies to the
> project. So bare minimum installation for supporting SSL/TLS is there and
> aligned with CPP counterpart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839747#comment-15839747 ] ASF GitHub Bot commented on THRIFT-3369: Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003039 --- Diff: configure.ac --- @@ -199,6 +196,12 @@ if test "$with_c_glib" = "yes"; then fi AM_CONDITIONAL(WITH_C_GLIB, [test "$have_glib2" = "yes" -a "$have_gobject2" = "yes"]) +echo "OpenSSL check" --- End diff -- There may be other libraries with native builds that need OpenSSL. Why are we making it conditional on cpp and c_glib library support? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839749#comment-15839749 ] ASF GitHub Bot commented on THRIFT-3369: Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98002795 --- Diff: lib/c_glib/test/owncloud.level2crm.pem --- @@ -0,0 +1,59 @@ +-BEGIN CERTIFICATE- +MIIFLDCCBBSgAwIBAgIBAzANBgkqhkiG9w0BAQsFADCBrTELMAkGA1UEBhMCRVMx +DzANBgNVBAgTBk1hZHJpZDEVMBMGA1UEBxMMVG9ycmVsb2RvbmVzMSswKQYDVQQK +EyJMZXZlbDIgU29sdWNpb25lcyBNYXJrZXRpbmcgMzYwIFNMMREwDwYDVQQLEwhT +aXN0ZW1hczEPMA0GA1UEAxMGTGV2ZWwyMSUwIwYJKoZIhvcNAQkBFhZnYWd1aWxh +ckBsZXZlbDJjcm0uY29tMB4XDTE1MDIxMzEyNDY0OVoXDTE3MDIwMjEyNDY0OVow +gaYxCzAJBgNVBAYTAkVTMQ8wDQYDVQQIEwZNYWRyaWQxKzApBgNVBAoTIkxldmVs +MiBTb2x1Y2lvbmVzIE1hcmtldGluZyAzNjAgU0wxETAPBgNVBAsTCFNpc3RlbWFz +MR8wHQYDVQQDExZvd25jbG91ZC5sZXZlbDJjcm0uY29tMSUwIwYJKoZIhvcNAQkB +FhZnYWd1aWxhckBsZXZlbDJjcm0uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A +MIIBCgKCAQEA9BH6ZPghzZQaWKG5Y3o/V41UDzJfkghfxhOzqZehn3dtpylMcA7i +qUi1N3Gf5S53GCl3JOm0sfdMhJr8UYBL1PwRnAo8ZOU678fofU7/2GgqAN+dtOO8 +X8JTar9zbANnJIR89fSXp4wQUbTKt7xbBezv8c/Cel6dlTSC8Dvc50ptksh5yue2 +SEuglFDtf7ru8EidROMgvUw4VAjusZXVirPKjv2rqWamgRsWizq9nkqJ71HjFweo +FYQRIuZ6qSDl3x7ZDV22kZth2LxFHRnv1E/SHbsvs0iEoKr9hF6xkdxyfHmlyd02 +oJOdlxEfHSREtuFDbDP/CcQy5oVbdM2EfQIDAQABo4IBWjCCAVYwCQYDVR0TBAIw +ADARBglghkgBhvhCAQEEBAMCBPAwCwYDVR0PBAQDAgXgMCUGCWCGSAGG+EIBDQQY +FhZMZXZlbDIgQ1JNIENlcnRpZmljYXRlMB0GA1UdDgQWBBTa17QOLz4WqHv0J6LP +KVVPsX721TCB4gYDVR0jBIHaMIHXgBTRF2IG48O6cMjz44Pwk5GbhUWX3aGBs6SB +sDCBrTELMAkGA1UEBhMCRVMxDzANBgNVBAgTBk1hZHJpZDEVMBMGA1UEBxMMVG9y +cmVsb2RvbmVzMSswKQYDVQQKEyJMZXZlbDIgU29sdWNpb25lcyBNYXJrZXRpbmcg +MzYwIFNMMREwDwYDVQQLEwhTaXN0ZW1hczEPMA0GA1UEAxMGTGV2ZWwyMSUwIwYJ +KoZIhvcNAQkBFhZnYWd1aWxhckBsZXZlbDJjcm0uY29tggkAqMKCeCp/2+wwDQYJ +KoZIhvcNAQELBQADggEBACy1UZR674b3yxEYnFPorhbD4CS65AfgLEObpvwbGvF8 +gLxJkxGhcsKEoxiBynnazdPzub8I9e0ZHsPjAyPupLrBeuUIBthmzdW3gUN9zZp1 +mRIurbiT3wlYCxl/cOa7MV7bCZSSqsC0WF9CLicRPFgyc6MDdRjsMufx+JkIdJZa +31jBweG/JzYm9pxdJFfnFcBEM+Kv3BcozoAAHcLHvv4cI4j5SpdzdCEgpgd6/LtI +i/grRayPlbQnqUrEOHLAuhAH+RflRTIFBGRRukLa7yqdY9J+qHDPLkxnLEmtyu4u +6GoZTYFtKnVZfubr+gku9Z8r2gF375InjOAifZH3ITE= +-END CERTIFICATE- +-BEGIN CERTIFICATE- +MIIFBDCCA+ygAwIBAgIJAKjCgngqf9vsMA0GCSqGSIb3DQEBCwUAMIGtMQswCQYD +VQQGEwJFUzEPMA0GA1UECBMGTWFkcmlkMRUwEwYDVQQHEwxUb3JyZWxvZG9uZXMx +KzApBgNVBAoTIkxldmVsMiBTb2x1Y2lvbmVzIE1hcmtldGluZyAzNjAgU0wxETAP +BgNVBAsTCFNpc3RlbWFzMQ8wDQYDVQQDEwZMZXZlbDIxJTAjBgkqhkiG9w0BCQEW +FmdhZ3VpbGFyQGxldmVsMmNybS5jb20wHhcNMTUwMTAxMTQyMDQ1WhcNMjQxMjI5 +MTQyMDQ1WjCBrTELMAkGA1UEBhMCRVMxDzANBgNVBAgTBk1hZHJpZDEVMBMGA1UE +BxMMVG9ycmVsb2RvbmVzMSswKQYDVQQKEyJMZXZlbDIgU29sdWNpb25lcyBNYXJr +ZXRpbmcgMzYwIFNMMREwDwYDVQQLEwhTaXN0ZW1hczEPMA0GA1UEAxMGTGV2ZWwy +MSUwIwYJKoZIhvcNAQkBFhZnYWd1aWxhckBsZXZlbDJjcm0uY29tMIIBIjANBgkq +hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2RJKzAzO8P0GT3FcnFMK3X9t4JE+mHMP +aPX5miBLaKH6rXclrfjYfzK3OESY5DhgZJ+Qzx5GyNl+hsSXpiIlNbWAEeJCIELG +OEz51zR0M2rQTC06UrWTtn2COQo2m91lv+Mwum+LSgqUPJ18dyKsmOFSVCsLOK+s +xZY7F5AF2+99kr1EFv0dcxS1BTRKOAQiMkuZEnFU95zXmm+U+vzenwX2V8XtTLip +e6+MezZTehvSZhbafKwFnw+vc36VGwrfhc+lH/1pc5etp4qcD9L0WvOhTmBUwWl/ +2hOU0XF5UYOkfsS1saot/WIsH6731Q/slYFCLXSrl+8R4+RxR9fozwIDAQABo4IB +IzCCAR8wHQYDVR0OBBYEFNEXYgbjw7pwyPPjg/CTkZuFRZfdMIHiBgNVHSMEgdow +gdeAFNEXYgbjw7pwyPPjg/CTkZuFRZfdoYGzpIGwMIGtMQswCQYDVQQGEwJFUzEP +MA0GA1UECBMGTWFkcmlkMRUwEwYDVQQHEwxUb3JyZWxvZG9uZXMxKzApBgNVBAoT +IkxldmVsMiBTb2x1Y2lvbmVzIE1hcmtldGluZyAzNjAgU0wxETAPBgNVBAsTCFNp +c3RlbWFzMQ8wDQYDVQQDEwZMZXZlbDIxJTAjBgkqhkiG9w0BCQEWFmdhZ3VpbGFy +QGxldmVsMmNybS5jb22CCQCowoJ4Kn/b7DAMBgNVHRMEBTADAQH/MAsGA1UdDwQE +AwIBBjANBgkqhkiG9w0BAQsFAAOCAQEAh2kPzv8jFNQbCrAD770m8T4W/KMhxMOv +Uhm/wSv7/g3Ir1pZ9LgXAWJx1qLQdCcOikBparkUpHIrqDU+wBL6o+CFNWp7WR6g +bft627bL9R3z3fTQHIchjPHQ7S4ID/STWfTqWDJQESBnTp1KTuJ8sMlvACMWZSUc +jZOAQIodNiUUNPkfreurPb9KH/nArwV/yTDoZMhiqoqNwOIY/0sxUJaNUAX3pgDd +FsGMBn4MiyGAw4XaK9LJBh+6DLH5D2Y7h0hXv+AUP3SSC+w5XA/D+SHcAbjtPzMW +cdq9jr1Gu0KO3PSGIAUpI1o+XQeLqgyieFcVF/FlD31MDC152DifNA== +-END CERTIFICATE- --- End diff -- This needs to be removed in favor of existing test keys. > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839750#comment-15839750 ] ASF GitHub Bot commented on THRIFT-3369: Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003689 --- Diff: lib/c_glib/test/Makefile.am --- @@ -37,16 +37,17 @@ BUILT_SOURCES = \ gen-c_glib/t_test_thrift_test_types.h AM_CPPFLAGS = -I../src -I./gen-c_glib -AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) \ +AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) $(OPENSSL_INCLUDES) \ @GCOV_CFLAGS@ AM_CXXFLAGS = $(AM_CFLAGS) -AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) @GCOV_LDFLAGS@ +AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) $(OPENSSL_LIBS) @GCOV_LDFLAGS@ check_PROGRAMS = \ testserialization \ testapplicationexception \ testcontainertest \ testtransportsocket \ + testtransportsslsocket \ --- End diff -- Does this need to be conditional on openssl being found? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839745#comment-15839745 ] ASF GitHub Bot commented on THRIFT-3369: Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98003481 --- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_platform_socket.h --- @@ -0,0 +1,120 @@ +/* --- End diff -- This looks a lot like the platform socket code that already exists in the C++ library. Given their similarity should they be combined and moved into a common location? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user gadLinux commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98027454 --- Diff: configure.ac --- @@ -199,6 +196,12 @@ if test "$with_c_glib" = "yes"; then fi AM_CONDITIONAL(WITH_C_GLIB, [test "$have_glib2" = "yes" -a "$have_gobject2" = "yes"]) +echo "OpenSSL check" --- End diff -- But this is the latest I fixed... Maybe I lost the changes when doing the rebase. OpenSSL was not used everyplace when I did the patch. In fact it was not even included for c_glib. C++ had this optionally included. I followed the C++ directions. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839953#comment-15839953 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98027454 --- Diff: configure.ac --- @@ -199,6 +196,12 @@ if test "$with_c_glib" = "yes"; then fi AM_CONDITIONAL(WITH_C_GLIB, [test "$have_glib2" = "yes" -a "$have_gobject2" = "yes"]) +echo "OpenSSL check" --- End diff -- But this is the latest I fixed... Maybe I lost the changes when doing the rebase. OpenSSL was not used everyplace when I did the patch. In fact it was not even included for c_glib. C++ had this optionally included. I followed the C++ directions. > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user gadLinux commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98027723 --- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_platform_socket.h --- @@ -0,0 +1,120 @@ +/* --- End diff -- I tottally agree. It's a reimplementation of the library for c_glib to not mix things. But this can be seen as an upgrade. And start making room for an common library after merge. Don't you think? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[
https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839957#comment-15839957
]
ASF GitHub Bot commented on THRIFT-3369:
Github user gadLinux commented on a diff in the pull request:
https://github.com/apache/thrift/pull/930#discussion_r98027875
--- Diff: lib/c_glib/test/CMakeLists.txt ---
@@ -108,13 +108,6 @@ add_test(NAME testoptionalrequired COMMAND
testoptionalrequired)
include_directories("${PROJECT_SOURCE_DIR}/test/c_glib/src"
"${CMAKE_CURRENT_BINARY_DIR}/gen-c_glib")
-add_executable(testthrifttest testthrifttest.c
--- End diff --
Thrift test should be there. Iif I removed it it was because error. I will
readd it.
> Implement SSL/TLS support on C with c_glib
> --
>
> Key: THRIFT-3369
> URL: https://issues.apache.org/jira/browse/THRIFT-3369
> Project: Thrift
> Issue Type: Improvement
> Components: C glib - Library
>Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0
>Reporter: Gonzalo Aguilar
> Labels: features, patch
>
> Implement SSL/TLS based on plain openssl instead of going through the way
> defined in THRIFT-1016.
> This help us to maintain a reference implementation and later switch over GIO
> or whatever is defined. But also does not add any other dependencies to the
> project. So bare minimum installation for supporting SSL/TLS is there and
> aligned with CPP counterpart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user gadLinux commented on a diff in the pull request:
https://github.com/apache/thrift/pull/930#discussion_r98027875
--- Diff: lib/c_glib/test/CMakeLists.txt ---
@@ -108,13 +108,6 @@ add_test(NAME testoptionalrequired COMMAND
testoptionalrequired)
include_directories("${PROJECT_SOURCE_DIR}/test/c_glib/src"
"${CMAKE_CURRENT_BINARY_DIR}/gen-c_glib")
-add_executable(testthrifttest testthrifttest.c
--- End diff --
Thrift test should be there. Iif I removed it it was because error. I will
readd it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839956#comment-15839956 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98027723 --- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_platform_socket.h --- @@ -0,0 +1,120 @@ +/* --- End diff -- I tottally agree. It's a reimplementation of the library for c_glib to not mix things. But this can be seen as an upgrade. And start making room for an common library after merge. Don't you think? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839959#comment-15839959 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98028242 --- Diff: lib/c_glib/test/Makefile.am --- @@ -37,16 +37,17 @@ BUILT_SOURCES = \ gen-c_glib/t_test_thrift_test_types.h AM_CPPFLAGS = -I../src -I./gen-c_glib -AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) \ +AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) $(OPENSSL_INCLUDES) \ @GCOV_CFLAGS@ AM_CXXFLAGS = $(AM_CFLAGS) -AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) @GCOV_LDFLAGS@ +AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) $(OPENSSL_LIBS) @GCOV_LDFLAGS@ check_PROGRAMS = \ testserialization \ testapplicationexception \ testcontainertest \ testtransportsocket \ + testtransportsslsocket \ --- End diff -- I think so. But since I don't have yet detection code for ssl there's no opt-out code. I think it will not work without the openssl library. So we have to choices. Require OpenSSL as you recommended above. Or make the code conditional, something is not ready yet. What do you think? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user gadLinux commented on a diff in the pull request: https://github.com/apache/thrift/pull/930#discussion_r98028242 --- Diff: lib/c_glib/test/Makefile.am --- @@ -37,16 +37,17 @@ BUILT_SOURCES = \ gen-c_glib/t_test_thrift_test_types.h AM_CPPFLAGS = -I../src -I./gen-c_glib -AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) \ +AM_CFLAGS = -g -Wall -Wextra -pedantic $(GLIB_CFLAGS) $(GOBJECT_CFLAGS) $(OPENSSL_INCLUDES) \ @GCOV_CFLAGS@ AM_CXXFLAGS = $(AM_CFLAGS) -AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) @GCOV_LDFLAGS@ +AM_LDFLAGS = $(GLIB_LIBS) $(GOBJECT_LIBS) $(OPENSSL_LIBS) @GCOV_LDFLAGS@ check_PROGRAMS = \ testserialization \ testapplicationexception \ testcontainertest \ testtransportsocket \ + testtransportsslsocket \ --- End diff -- I think so. But since I don't have yet detection code for ssl there's no opt-out code. I think it will not work without the openssl library. So we have to choices. Require OpenSSL as you recommended above. Or make the code conditional, something is not ready yet. What do you think? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (THRIFT-4039) Update of Apache Thrift .Net Core lib
[ https://issues.apache.org/jira/browse/THRIFT-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Gotra closed THRIFT-4039. --- Thank you > Update of Apache Thrift .Net Core lib > -- > > Key: THRIFT-4039 > URL: https://issues.apache.org/jira/browse/THRIFT-4039 > Project: Thrift > Issue Type: New Feature > Components: .NETCore - Library, Build Process, Documentation, > Tutorial >Reporter: Volodymyr Gotra >Assignee: Volodymyr Gotra > Fix For: 0.11.0 > > > Changes to library: > Updated tutorial (added samples of usage of multiplexed protocol to > server and client side and other) > Added framed transport to client side and implementation of framed > transport to server > Updated information related to build of thrift application with CMake, > Visual Studio 2017, XCode > Updated information related to build and usage of Thrift .Net Core library > Added SDK versions to project for easy usage of different versions of > .NET Core SDK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request #1081: THRIFT-3854 add a way in java to clear TFramedTra...
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1081#discussion_r98086075
--- Diff:
lib/java/test/org/apache/thrift/transport/TestTFastFramedTransport.java ---
@@ -19,6 +19,8 @@
package org.apache.thrift.transport;
public class TestTFastFramedTransport extends TestTFramedTransport {
+ protected final static int INITIAL_CAPACITY = 50;
+
@Override
protected TTransport getTransport(TTransport underlying) {
return new TFastFramedTransport(underlying, 50, 10 * 1024 * 1024);
--- End diff --
I think 50 was supposed to be changed to ``INITIAL_CAPACITY`` here,
something I could do as part of the merge.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (THRIFT-3854) allow users to clear read buffers
[
https://issues.apache.org/jira/browse/THRIFT-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840401#comment-15840401
]
ASF GitHub Bot commented on THRIFT-3854:
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1081#discussion_r98086075
--- Diff:
lib/java/test/org/apache/thrift/transport/TestTFastFramedTransport.java ---
@@ -19,6 +19,8 @@
package org.apache.thrift.transport;
public class TestTFastFramedTransport extends TestTFramedTransport {
+ protected final static int INITIAL_CAPACITY = 50;
+
@Override
protected TTransport getTransport(TTransport underlying) {
return new TFastFramedTransport(underlying, 50, 10 * 1024 * 1024);
--- End diff --
I think 50 was supposed to be changed to ``INITIAL_CAPACITY`` here,
something I could do as part of the merge.
> allow users to clear read buffers
> -
>
> Key: THRIFT-3854
> URL: https://issues.apache.org/jira/browse/THRIFT-3854
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
>Reporter: Chris Lockfort
>Priority: Minor
> Attachments: thrift-3854-clearable-read-buffers.patch
>
>
> My use case (which I believe many others would share):
> - I have a large number of Thrift connections in a connection pool
> - Upon return of the used connection to the pool I would like to eagerly
> clean up the read buffer because I know it will not be used again until the
> connection is checked out and a new read puts a new buffer in its place.
> - Eagerly clearing the read buffers of idle connections saves a considerable
> amount of heap memory in my application, vs. having all of the idle
> connections keep all of their read buffers allocated.
> - Currently, it looks like someone thought about this and there is a
> TMemoryInputTransport#clear() , but it isn't callable from people with a
> TFramedTransport which uses a TMemoryInputTransport for its read buffer
> (unless you count doing gross and brittle reflection magic).
> I've included a patch, but I'm very flexible / open to opinions of how
> someone more familiar to this project would want to implement a feature like
> this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
THRIFT-3854 (Java) - Please Review
I'd like someone more familiar with the Java runtime to review the change before I merge it. It passed CI and has a nice unit test. https://github.com/apache/thrift/pull/1081 [Description: Description: simplivity-lg-xsmall] James E. King, III Architect 8 Technology Drive, 2nd Floor Westborough, MA 01581-1756 Ph: 855-SVT-INFO --- PRIVACY STATEMENT: This message is a PRIVATE communication. This message and all attachments are a private communication sent by SimpliVity and are considered to be confidential or protected by privilege. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. ---
[GitHub] thrift pull request #1081: THRIFT-3854 add a way in java to clear TFramedTra...
Github user jsirois commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1081#discussion_r98087986
--- Diff:
lib/java/src/org/apache/thrift/transport/TFastFramedTransport.java ---
@@ -164,6 +166,10 @@ public void consumeBuffer(int len) {
readBuffer.consumeBuffer(len);
}
+ public void clear() {
+readBuffer = new
AutoExpandingBufferReadTransport(initialBufferCapacity, 1.5);
--- End diff --
It would be nice to share the initialization code on line 110 above in the
constructor - consider factoring out a factory or calling reset from the
constructor to initialize `readBuffer` for the 1st time.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] thrift pull request #1081: THRIFT-3854 add a way in java to clear TFramedTra...
Github user jsirois commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1081#discussion_r98087206
--- Diff: lib/java/src/org/apache/thrift/transport/TFramedTransport.java ---
@@ -123,6 +123,12 @@ public void consumeBuffer(int len) {
readBuffer_.consumeBuffer(len);
}
+ public void clear() {
+if (readBuffer_ != null) {
--- End diff --
`readBuffer_` is declared `private TMemoryInputTransport readBuffer_ = new
TMemoryInputTransport(new byte[0]);` and never re-assigned in this class.
Unless there is known code re-assigning via reflection, this should just be
promoted to final and all the null checks - like the one added here - dispensed
with.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
Re: THRIFT-3854 (Java) - Please Review
I noted a few minor things, but not bugs - looks good to me. On Thu, Jan 26, 2017 at 1:38 PM, Jim King wrote: > I’d like someone more familiar with the Java runtime to review the change > before I merge it. It passed CI and has a nice unit test. > > https://github.com/apache/thrift/pull/1081 > > > > [image: Description: Description: simplivity-lg-xsmall] > > James E. King, III > > Architect > > 8 Technology Drive, 2nd Floor > Westborough, MA 01581-1756 > > Ph: 855-SVT-INFO > > > > > -- > PRIVACY STATEMENT: > This message is a PRIVATE communication. This message and all attachments > are a private communication sent by SimpliVity and are considered to be > confidential or protected by privilege. If you are not the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of the information contained in or attached to this > message is strictly prohibited. Please notify the sender of the delivery > error by replying to this message, and then delete it from your system. > For more information please visit http://www.simplivity.com > -- >
[jira] [Commented] (THRIFT-3854) allow users to clear read buffers
[
https://issues.apache.org/jira/browse/THRIFT-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840423#comment-15840423
]
ASF GitHub Bot commented on THRIFT-3854:
Github user jsirois commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1081#discussion_r98087206
--- Diff: lib/java/src/org/apache/thrift/transport/TFramedTransport.java ---
@@ -123,6 +123,12 @@ public void consumeBuffer(int len) {
readBuffer_.consumeBuffer(len);
}
+ public void clear() {
+if (readBuffer_ != null) {
--- End diff --
`readBuffer_` is declared `private TMemoryInputTransport readBuffer_ = new
TMemoryInputTransport(new byte[0]);` and never re-assigned in this class.
Unless there is known code re-assigning via reflection, this should just be
promoted to final and all the null checks - like the one added here - dispensed
with.
> allow users to clear read buffers
> -
>
> Key: THRIFT-3854
> URL: https://issues.apache.org/jira/browse/THRIFT-3854
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
>Reporter: Chris Lockfort
>Priority: Minor
> Attachments: thrift-3854-clearable-read-buffers.patch
>
>
> My use case (which I believe many others would share):
> - I have a large number of Thrift connections in a connection pool
> - Upon return of the used connection to the pool I would like to eagerly
> clean up the read buffer because I know it will not be used again until the
> connection is checked out and a new read puts a new buffer in its place.
> - Eagerly clearing the read buffers of idle connections saves a considerable
> amount of heap memory in my application, vs. having all of the idle
> connections keep all of their read buffers allocated.
> - Currently, it looks like someone thought about this and there is a
> TMemoryInputTransport#clear() , but it isn't callable from people with a
> TFramedTransport which uses a TMemoryInputTransport for its read buffer
> (unless you count doing gross and brittle reflection magic).
> I've included a patch, but I'm very flexible / open to opinions of how
> someone more familiar to this project would want to implement a feature like
> this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3854) allow users to clear read buffers
[
https://issues.apache.org/jira/browse/THRIFT-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840422#comment-15840422
]
ASF GitHub Bot commented on THRIFT-3854:
Github user jsirois commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1081#discussion_r98087986
--- Diff:
lib/java/src/org/apache/thrift/transport/TFastFramedTransport.java ---
@@ -164,6 +166,10 @@ public void consumeBuffer(int len) {
readBuffer.consumeBuffer(len);
}
+ public void clear() {
+readBuffer = new
AutoExpandingBufferReadTransport(initialBufferCapacity, 1.5);
--- End diff --
It would be nice to share the initialization code on line 110 above in the
constructor - consider factoring out a factory or calling reset from the
constructor to initialize `readBuffer` for the 1st time.
> allow users to clear read buffers
> -
>
> Key: THRIFT-3854
> URL: https://issues.apache.org/jira/browse/THRIFT-3854
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
>Reporter: Chris Lockfort
>Priority: Minor
> Attachments: thrift-3854-clearable-read-buffers.patch
>
>
> My use case (which I believe many others would share):
> - I have a large number of Thrift connections in a connection pool
> - Upon return of the used connection to the pool I would like to eagerly
> clean up the read buffer because I know it will not be used again until the
> connection is checked out and a new read puts a new buffer in its place.
> - Eagerly clearing the read buffers of idle connections saves a considerable
> amount of heap memory in my application, vs. having all of the idle
> connections keep all of their read buffers allocated.
> - Currently, it looks like someone thought about this and there is a
> TMemoryInputTransport#clear() , but it isn't callable from people with a
> TFramedTransport which uses a TMemoryInputTransport for its read buffer
> (unless you count doing gross and brittle reflection magic).
> I've included a patch, but I'm very flexible / open to opinions of how
> someone more familiar to this project would want to implement a feature like
> this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-4042) ExtractionError when using accelerated thrift in a multiprocess test
Chandler May created THRIFT-4042:
Summary: ExtractionError when using accelerated thrift in a
multiprocess test
Key: THRIFT-4042
URL: https://issues.apache.org/jira/browse/THRIFT-4042
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.10.0
Reporter: Chandler May
We recently switched to thrift 0.10.0 with accelerated protocols and started
getting sporadic errors in tests that use the multiprocessing module of the
form:
{code}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib64/python2.7/multiprocessing/pool.py:250: in map
return self.map_async(func, iterable, chunksize).get()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , timeout = None
def get(self, timeout=None):
self.wait(timeout)
if not self._ready:
raise TimeoutError
if self._success:
return self._value
else:
> raise self._value
E ExtractionError: Can't extract file(s) to egg cache
E
E The following error occurred while trying to extract file(s) to the
Python egg
E cache:
E
E [Errno 17] File exists: '/home/concrete/.cache/Python-Eggs'
E
E The Python egg cache directory is currently set to:
E
E /home/concrete/.cache/Python-Eggs
E
E Perhaps your account does not have write access to this directory?
You can
E change the cache directory by setting the PYTHON_EGG_CACHE
environment
E variable to point to an accessible directory.
/usr/lib64/python2.7/multiprocessing/pool.py:554: ExtractionError
{code}
This particular error arose from a test we wrote to isolate the issue. It is
of the form:
{code}
from multiprocessing import Pool
input_path = '/path/to/thrift_serialized_data'
num_trials = 100
num_procs = 2
num_tasks = 4
for i in xrange(num_trials):
pool = Pool(num_procs)
results = pool.map(_deserialize, [input_path] * num_tasks)
for result in results:
assert result is True
{code}
where {{_deserialize}} is a function that reads thrift serialized objects from
a file and returns {{True}} on success. I can provide MWE if necessary but it
would take some time on my part.
I want to stress that this only happens when using the new accelerated protocol
in thrift 0.10.0 and only happens in {{python setup.py test}} in our project
when thrift is *not* installed already on the system. We are using pytest but
I'm not sure whether that's important. At test time thrift gets
installed/unpacked as an egg in a local directory and gets a locking error. I
believe this is the same error as:
http://dev.list.galaxyproject.org/python-egg-cache-exists-error-td4656276.html
http://www.georgevreilly.com/blog/2015/01/28/PythonEggCache.html
I believe the documentation indicates this problem can be worked around by
setting {{zip_safe}} to {{False}} in {{setup.py}}:
http://setuptools.readthedocs.io/en/latest/setuptools.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-4042) ExtractionError when using accelerated thrift in a multiprocess test
[
https://issues.apache.org/jira/browse/THRIFT-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandler May updated THRIFT-4042:
-
Description:
We recently switched to thrift 0.10.0 with accelerated protocols and started
getting sporadic errors in tests that use the multiprocessing module of the
form:
{code}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib64/python2.7/multiprocessing/pool.py:250: in map
return self.map_async(func, iterable, chunksize).get()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , timeout = None
def get(self, timeout=None):
self.wait(timeout)
if not self._ready:
raise TimeoutError
if self._success:
return self._value
else:
> raise self._value
E ExtractionError: Can't extract file(s) to egg cache
E
E The following error occurred while trying to extract file(s) to the
Python egg
E cache:
E
E [Errno 17] File exists: '/home/concrete/.cache/Python-Eggs'
E
E The Python egg cache directory is currently set to:
E
E /home/concrete/.cache/Python-Eggs
E
E Perhaps your account does not have write access to this directory?
You can
E change the cache directory by setting the PYTHON_EGG_CACHE
environment
E variable to point to an accessible directory.
/usr/lib64/python2.7/multiprocessing/pool.py:554: ExtractionError
{code}
This particular error arose from a test we wrote to isolate the issue. It is
of the form:
{code}
from multiprocessing import Pool
input_path = '/path/to/thrift_serialized_data'
num_trials = 100
num_procs = 2
num_tasks = 4
for i in xrange(num_trials):
pool = Pool(num_procs)
results = pool.map(_deserialize, [input_path] * num_tasks)
for result in results:
assert result is True
{code}
where {{_deserialize}} is a function that reads thrift serialized objects from
a file and returns {{True}} on success. I can provide MWE if necessary but it
would take some time on my part.
I want to stress that this only happens when using the new accelerated protocol
in thrift 0.10.0 and only happens in {{python setup.py test}} in our project
when thrift has not been installed via *pip* (but has been installed by
{{python setup.py install}} in our project, which depends on thrift). We are
using pytest but I'm not sure whether that's important. At test time thrift
gets installed/unpacked as an egg in a local directory and gets a locking
error. I believe this is the same error as:
http://dev.list.galaxyproject.org/python-egg-cache-exists-error-td4656276.html
http://www.georgevreilly.com/blog/2015/01/28/PythonEggCache.html
I believe the documentation indicates this problem can be worked around by
setting {{zip_safe}} to {{False}} in {{setup.py}}:
http://setuptools.readthedocs.io/en/latest/setuptools.html
was:
We recently switched to thrift 0.10.0 with accelerated protocols and started
getting sporadic errors in tests that use the multiprocessing module of the
form:
{code}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib64/python2.7/multiprocessing/pool.py:250: in map
return self.map_async(func, iterable, chunksize).get()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , timeout = None
def get(self, timeout=None):
self.wait(timeout)
if not self._ready:
raise TimeoutError
if self._success:
return self._value
else:
> raise self._value
E ExtractionError: Can't extract file(s) to egg cache
E
E The following error occurred while trying to extract file(s) to the
Python egg
E cache:
E
E [Errno 17] File exists: '/home/concrete/.cache/Python-Eggs'
E
E The Python egg cache directory is currently set to:
E
E /home/concrete/.cache/Python-Eggs
E
E Perhaps your account does not have write access to this directory?
You can
E change the cache directory by setting the PYTHON_EGG_CACHE
environment
E variable to point to an accessible directory.
/usr/lib64/python2.7/multiprocessing/pool.py:554: ExtractionError
[jira] [Commented] (THRIFT-4042) ExtractionError when using accelerated thrift in a multiprocess test
[
https://issues.apache.org/jira/browse/THRIFT-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840532#comment-15840532
]
Chandler May commented on THRIFT-4042:
--
Clarified that the bug occurs when thrift is installed via setuptools, as a
dependency of our project---but not when thrift is installed beforehand via pip.
> ExtractionError when using accelerated thrift in a multiprocess test
>
>
> Key: THRIFT-4042
> URL: https://issues.apache.org/jira/browse/THRIFT-4042
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.10.0
>Reporter: Chandler May
>
> We recently switched to thrift 0.10.0 with accelerated protocols and started
> getting sporadic errors in tests that use the multiprocessing module of the
> form:
> {code}
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> /usr/lib64/python2.7/multiprocessing/pool.py:250: in map
> return self.map_async(func, iterable, chunksize).get()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = , timeout = None
> def get(self, timeout=None):
> self.wait(timeout)
> if not self._ready:
> raise TimeoutError
> if self._success:
> return self._value
> else:
> > raise self._value
> E ExtractionError: Can't extract file(s) to egg cache
> E
> E The following error occurred while trying to extract file(s) to
> the Python egg
> E cache:
> E
> E [Errno 17] File exists: '/home/concrete/.cache/Python-Eggs'
> E
> E The Python egg cache directory is currently set to:
> E
> E /home/concrete/.cache/Python-Eggs
> E
> E Perhaps your account does not have write access to this
> directory? You can
> E change the cache directory by setting the PYTHON_EGG_CACHE
> environment
> E variable to point to an accessible directory.
> /usr/lib64/python2.7/multiprocessing/pool.py:554: ExtractionError
> {code}
> This particular error arose from a test we wrote to isolate the issue. It is
> of the form:
> {code}
> from multiprocessing import Pool
> input_path = '/path/to/thrift_serialized_data'
>
> num_trials = 100
>
> num_procs = 2
>
> num_tasks = 4
>
>
>
> for i in xrange(num_trials):
>
> pool = Pool(num_procs)
>
> results = pool.map(_deserialize, [input_path] * num_tasks)
> for result in results:
> assert result is True
> {code}
> where {{_deserialize}} is a function that reads thrift serialized objects
> from a file and returns {{True}} on success. I can provide MWE if necessary
> but it would take some time on my part.
> I want to stress that this only happens when using the new accelerated
> protocol in thrift 0.10.0 and only happens in {{python setup.py test}} in our
> project when thrift has not been installed via *pip* (but has been installed
> by {{python setup.py install}} in our project, which depends on thrift). We
> are using pytest but I'm not sure whether that's important. At test time
> thrift gets installed/unpacked as an egg in a local directory and gets a
> locking error. I believe this is the same error as:
> http://dev.list.galaxyproject.org/python-egg-cache-exists-error-td4656276.html
> http://www.georgevreilly.com/blog/2015/01/28/PythonEggCache.html
> I believe the documentation indicates this problem can be worked around by
> setting {{zip_safe}} to {{False}} in {{setup.py}}:
> http://setuptools.readthedocs.io/en/latest/setuptools.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
