[jira] [Assigned] (THRIFT-3033) Perl: Support for Multiplexing Services on any Transport, Protocol and Server
[ https://issues.apache.org/jira/browse/THRIFT-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer reassigned THRIFT-3033: -- Assignee: Jens Geyer Perl: Support for Multiplexing Services on any Transport, Protocol and Server - Key: THRIFT-3033 URL: https://issues.apache.org/jira/browse/THRIFT-3033 Project: Thrift Issue Type: Improvement Reporter: Shankar Narayan Assignee: Jens Geyer Attachments: MessageType.pm, MultiplexedProcessor.pm, MultiplexedProtocol.pm, ProtocolDecorator.pm Currently there is no support for mutliplexing services via perl. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request: Multiplexer in Ruby
GitHub user akelmanson opened a pull request: https://github.com/apache/thrift/pull/406 Multiplexer in Ruby You can merge this pull request into a Git repository by running: $ git pull https://github.com/investtools/thrift rb-multiplexer Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/406.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #406 commit f270767ecfa88daf2ac0f85923152f4361bc0376 Author: André Aizim Kelmanson akelman...@gmail.com Date: 2015-03-22T13:14:06Z Multiplexer in Ruby --- 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-1125) Multiplexing support for the Ruby Library
[
https://issues.apache.org/jira/browse/THRIFT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14374927#comment-14374927
]
André Aizim Kelmanson commented on THRIFT-1125:
---
Sure.
https://github.com/apache/thrift/pull/406
Multiplexing support for the Ruby Library
-
Key: THRIFT-1125
URL: https://issues.apache.org/jira/browse/THRIFT-1125
Project: Thrift
Issue Type: Sub-task
Components: Ruby - Library
Affects Versions: 0.6
Reporter: Alex
Priority: Minor
Labels: multiplexing
Attachments: multiplexed.patch, multiplexing_support.diff
Attached are two files which implement multiplexing support in the Ruby
library. I do not consider these implementations complete, however they work
well for my purposes.
On the server side:
mp = Thrift::MultiplexedProcessor.new
mp.register 'SomeService', some_service_processor
mp.register 'SomeOtherService', some_other_service_processor
...
server = Thrift::SimpleServer.new(mp, transport)
On the client side:
some_service = SomeServiceService::Client.new('SomeService',
some_service_protocol)
some_other_service = SomeOtherServiceService::Client.new('SomeOtherService',
some_other_service_protocol)
You only need one transport in both cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-1125) Multiplexing support for the Ruby Library
[
https://issues.apache.org/jira/browse/THRIFT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14374898#comment-14374898
]
Jens Geyer commented on THRIFT-1125:
That's great (really), many thanks for the work, but we need a pull request or
a patch to add it into the Thrift code base. Is that possible?
Multiplexing support for the Ruby Library
-
Key: THRIFT-1125
URL: https://issues.apache.org/jira/browse/THRIFT-1125
Project: Thrift
Issue Type: Sub-task
Components: Ruby - Library
Affects Versions: 0.6
Reporter: Alex
Priority: Minor
Labels: multiplexing
Attachments: multiplexed.patch, multiplexing_support.diff
Attached are two files which implement multiplexing support in the Ruby
library. I do not consider these implementations complete, however they work
well for my purposes.
On the server side:
mp = Thrift::MultiplexedProcessor.new
mp.register 'SomeService', some_service_processor
mp.register 'SomeOtherService', some_other_service_processor
...
server = Thrift::SimpleServer.new(mp, transport)
On the client side:
some_service = SomeServiceService::Client.new('SomeService',
some_service_protocol)
some_other_service = SomeOtherServiceService::Client.new('SomeOtherService',
some_other_service_protocol)
You only need one transport in both cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [DISCUSS] let's switch to C++11 (was Re: [jira] [Commented] (THRIFT-3043) go compiler generator uses non C++98 code)
Agree, makes sense.
-Ursprüngliche Nachricht-
From: Roger Meier
Sent: Saturday, March 21, 2015 9:59 PM
To: dev@thrift.apache.org
Subject: Re: [DISCUSS] let's switch to C++11 (was Re: [jira] [Commented]
(THRIFT-3043) go compiler generator uses non C++98 code)
Yes, let's do a 0.9.3 release as proposed by Jake.
and focus afterwards towards 1.0.0 on the master branch with new
features such as:
- C++11(MSVC, gcc, clang)
- CMake
- Phyton3
- etc.
regards
-roger
Quoting Randy Abernethy randy.aberne...@gmail.com:
+1 for C++11/cmake/Py3 as part of 1.0
On Tue, Mar 17, 2015 at 5:13 PM, Konrad Grochowski hc...@minions.org.pl
wrote:
+1
As you may remember I was working on C++11/cpp_v2 gen/lib -
https://github.com/hcorg/thrift/tree/cpp_v2 yet I had to put it on a
hiatus some time ago... Maybe next month I'll find some time to finish it
(I think I was pretty close to 0.0.1 version of complete generator ;) )
-KG
W dniu 2015-03-18 o 01:05, Jake Farrell pisze:
+1
Thoughts on cutting the 0.9.3 release so we do not have a long delay
between releases again and put this in for a 0.9.4 or we could stop the
point releases and go with 1.0 with full c++11, cmake, py3.0, etc.
-Jake
On Tue, Mar 17, 2015 at 7:41 PM, Roger Meier ro...@bufferoverflow.ch
wrote:
Hi all
We had lot of discussions and issues about C++11 support and I think it
is
time to move the master branch development towards C++11 and set this
as
a
dependency starting wit 0.9.3 of Apache Thrift.
reasons to move forward:
- no feature show stopper due to C++98 dependency
- no backport of patches, it's a nightmare
- master branch should focus towards future
- evolution of compiler and cpp library
- many developers already use C++11 capable compilers
- http://cpprocks.com/c11-compiler-support-shootout-
visual-studio-gcc-clang-intel/
- gcc support -std=c++11 since version 4.7
see https://gcc.gnu.org/projects/cxx0x.html
- clang 3.5
- all recent Linux distros support C++11
- centos 7 uses gcc 4.8.2
- Debian Jessie uses gcc 4.9.2
- Debian Wheezy uses gcc 4.7.2
- RHEL-7.0 uses gcc 4.8.2
- Suse 13.2 uses gcc 4.8.3
- Suse 13.1 uses gcc 4.8.1
- Ubuntu utopic 14.10 uses gcc 4.9.1
- Ubuntu trusty 14.04 LTS uses gcc 4.8.2
- Ubuntu saucy 13.10 uses gcc 4.8.1
- it is 2015 and C++11 is ready to use in the wild
- C++11 compilers can easy be installed on older distros
- no fork of a C++11 library
solution for older environments:
- C++98 can be handled on the 0.9.x branch if required
- install a more recent compiler
- http://www.necessaryandsufficient.net/2014/07/c11-on-centos/
What do you think?
all the best!
-roger
On 17.03.2015 03:49, Randy Abernethy (JIRA) wrote:
[ https://issues.apache.org/jira/browse/THRIFT-3043?page=
com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanelfocusedCommentId=14364464#comment-14364464 ]
Randy Abernethy commented on THRIFT-3043:
-
Hey Jens: looks good, many thanks!
Hey Roger: I agree, we definitely need a Cpp11 generator and lib
ASAP.
The only thing I am suggesting is that we keep the IDL compiler source
Cpp98 until Cpp11 is ubiquitous. My hope is that we can fork the Cpp98
lib
to create a Cpp11 lib and fork the Cpp98 generator to create a Cpp11
generator (which would be written in Cpp98). This way folks can use
Cpp11
or Cpp98 in their user code. I think this was the plan arrived at on
some
other threads. The THeader pull from DJW (https://github.com/apache/
thrift/pull/357.patch) is all lib so should apply fine to a Cpp11 lib
fork.
The IDL compiler is pretty simple and has no bearing on user code. The
path of least resistance there seems to be to keep the source for the
IDL
compiler in Cpp98. That way it will compile under Cpp11 or Cpp98. Win
win.
Rewriting the compiler in Cpp11 (or Java or Go) does not seem like a
good
use of our time and we have precious little of it (as you pointed out
on
the THeader issue). Most of the Cpp98 breaking patches are due to
unsupported variable initialization and the like, seems silly to cut
off a
large chunk of compatibility we already have in place for trivial
stuff
like that.
go compiler generator uses non C++98 code
-
Key: THRIFT-3043
URL: https://issues.apache.org/
jira/browse/THRIFT-3043
Project: Thrift
Issue Type: Bug
Components: Go - Compiler
Affects Versions: 0.9.3
Reporter: Randy Abernethy
Assignee: Jens Geyer
Priority: Blocker
Fix For: 0.9.3
Attachments: THRIFT-3043-go-compiler-
generator-uses-non-C-98-code.patch
go compiler generator uses non C++98 code causing builds to fail in
Centos 6 and other environments.
== default: src/generate/t_go_generator.cc:415: error: in C++98
���commonInitialisms��� must be initialized by constructor, not by
���{...}���
== default:
[GitHub] thrift pull request: Multiplexer in Ruby
Github user Jens-G commented on the pull request: https://github.com/apache/thrift/pull/406#issuecomment-84608877 Tracked in THRIFT-1125 --- 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-1125) Multiplexing support for the Ruby Library
[
https://issues.apache.org/jira/browse/THRIFT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14374938#comment-14374938
]
ASF GitHub Bot commented on THRIFT-1125:
Github user Jens-G commented on the pull request:
https://github.com/apache/thrift/pull/406#issuecomment-84608877
Tracked in THRIFT-1125
Multiplexing support for the Ruby Library
-
Key: THRIFT-1125
URL: https://issues.apache.org/jira/browse/THRIFT-1125
Project: Thrift
Issue Type: Sub-task
Components: Ruby - Library
Affects Versions: 0.6
Reporter: Alex
Priority: Minor
Labels: multiplexing
Attachments: multiplexed.patch, multiplexing_support.diff
Attached are two files which implement multiplexing support in the Ruby
library. I do not consider these implementations complete, however they work
well for my purposes.
On the server side:
mp = Thrift::MultiplexedProcessor.new
mp.register 'SomeService', some_service_processor
mp.register 'SomeOtherService', some_other_service_processor
...
server = Thrift::SimpleServer.new(mp, transport)
On the client side:
some_service = SomeServiceService::Client.new('SomeService',
some_service_protocol)
some_other_service = SomeOtherServiceService::Client.new('SomeOtherService',
some_other_service_protocol)
You only need one transport in both cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-1125) Multiplexing support for the Ruby Library
[
https://issues.apache.org/jira/browse/THRIFT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14374937#comment-14374937
]
Jens Geyer commented on THRIFT-1125:
GitHub user akelmanson opened a pull request:
https://github.com/apache/thrift/pull/406
Multiplexer in Ruby
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/investtools/thrift rb-multiplexer
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/406.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #406
Multiplexing support for the Ruby Library
-
Key: THRIFT-1125
URL: https://issues.apache.org/jira/browse/THRIFT-1125
Project: Thrift
Issue Type: Sub-task
Components: Ruby - Library
Affects Versions: 0.6
Reporter: Alex
Priority: Minor
Labels: multiplexing
Attachments: multiplexed.patch, multiplexing_support.diff
Attached are two files which implement multiplexing support in the Ruby
library. I do not consider these implementations complete, however they work
well for my purposes.
On the server side:
mp = Thrift::MultiplexedProcessor.new
mp.register 'SomeService', some_service_processor
mp.register 'SomeOtherService', some_other_service_processor
...
server = Thrift::SimpleServer.new(mp, transport)
On the client side:
some_service = SomeServiceService::Client.new('SomeService',
some_service_protocol)
some_other_service = SomeOtherServiceService::Client.new('SomeOtherService',
some_other_service_protocol)
You only need one transport in both cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2730) Cocoa coding standards
[ https://issues.apache.org/jira/browse/THRIFT-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14374989#comment-14374989 ] Juan Moreno commented on THRIFT-2730: - Are you saying the generator should adhere to the Cocoa coding standard, or that we should have one for the project? Cocoa coding standards -- Key: THRIFT-2730 URL: https://issues.apache.org/jira/browse/THRIFT-2730 Project: Thrift Issue Type: Sub-task Components: Cocoa - Library Reporter: Konrad Grochowski -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2730) Cocoa coding standards
[ https://issues.apache.org/jira/browse/THRIFT-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375075#comment-14375075 ] Randy Abernethy commented on THRIFT-2730: - The coding standard would apply to code within the library and the code emitted by the IDL Compiler generator. The idea is to keep it simple, leverage existing best practices already in place in the languages community but to offer enough guidance to keep the Apache Thrift code cohesive. A coding standard/style guide has been proposed for each Apache Thrift language. Cocoa coding standards -- Key: THRIFT-2730 URL: https://issues.apache.org/jira/browse/THRIFT-2730 Project: Thrift Issue Type: Sub-task Components: Cocoa - Library Reporter: Konrad Grochowski -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3038) Use of volatile in cpp library
[ https://issues.apache.org/jira/browse/THRIFT-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375066#comment-14375066 ] Roger Meier commented on THRIFT-3038: - Do you already have some patches to be reviewed? Use of volatile in cpp library -- Key: THRIFT-3038 URL: https://issues.apache.org/jira/browse/THRIFT-3038 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.2 Reporter: Adriaan Schmidt In the cpp library there are several member variables which are declared volatile, I believe with the intention of providing some sort of thread-safety. While volatile can be used in this way in Java and C#, in C++ it cannot! It does not provide any guarantees with regard to instruction (re-)ordering, i.e. there are no implied memory barriers like you would get by using explicit locking or atomic variables. This means that all uses of volatile should be examined, the volatile qualifier should be removed and replaced by proper synchronization. The affected member variables are: # NoStarveReadWriteMutex::writerWaiting_ Unprotected read access in acquireRead(). Data race can be seen by running the unit test with Helgrind. # TFileTransport::forceFlush_ Always accessed while holding mutex_. In this case, the volatile can just be removed. # TFileTransport::closing_ Sometimes accessed while holding mutex_ (in combination with the notEmpty_ Monitor), but, e.g., enqueueEvent reads closing_ without any synchronization. # TThreadPoolServer::stop_, TThreadedServer::stop_ Accessed (read and written) without synchronization. These would probably be fine using an atomic data type. Or, use explicit locking or signaling. # TThreadPoolServer::timeout_, TThreadPoolServer::taskExpiration_ Should probably use a lock. # Mutex.cpp has mutexProfilingCounter as static variable. This probably doesn’t break anything, but still the volatile serves no real purpose. While some of the fixes are probably simple, in general I think someone with better knowledge of the code should have a look at this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code
[ https://issues.apache.org/jira/browse/THRIFT-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375080#comment-14375080 ] Randy Abernethy commented on THRIFT-3049: - +1 Patches welcome As an iOS developer, I want a generator and library that produces Swift code Key: THRIFT-3049 URL: https://issues.apache.org/jira/browse/THRIFT-3049 Project: Thrift Issue Type: Epic Components: Cocoa - Compiler, Cocoa - Library, Compiler (General) Reporter: Juan Moreno Swift is slowly replacing the legacy Objective-C. To keep thrift with the times, let's bake it in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code
[ https://issues.apache.org/jira/browse/THRIFT-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375084#comment-14375084 ] Juan Moreno commented on THRIFT-3049: - I made this an epic, as there is likely a multitude of stories encompassing the effort. First I would think is a library in Swift. As an iOS developer, I want a generator and library that produces Swift code Key: THRIFT-3049 URL: https://issues.apache.org/jira/browse/THRIFT-3049 Project: Thrift Issue Type: Epic Components: Cocoa - Compiler, Cocoa - Library, Compiler (General) Reporter: Juan Moreno Swift is slowly replacing the legacy Objective-C. To keep thrift with the times, let's bake it in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code
[ https://issues.apache.org/jira/browse/THRIFT-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375121#comment-14375121 ] Juan Moreno commented on THRIFT-3049: - Thanks [~jensg] I think this will warrant its own components (Swift Library, Swift Compiler) , and should not be hashed in with Cocoa As an iOS developer, I want a generator and library that produces Swift code Key: THRIFT-3049 URL: https://issues.apache.org/jira/browse/THRIFT-3049 Project: Thrift Issue Type: Epic Components: Compiler (General) Reporter: Juan Moreno Swift is slowly replacing the legacy Objective-C. To keep thrift with the times, let's bake it in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code
[ https://issues.apache.org/jira/browse/THRIFT-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375122#comment-14375122 ] Jens Geyer edited comment on THRIFT-3049 at 3/22/15 7:30 PM: - +1 as well. A few tips to make it an easier way for you: * There is [a nice document over here outlining the general process|http://thrift.apache.org/docs/HowToNewLanguage] * Search the mailing lists archives. There has been at least one other request for Swift in the past (I just don't remember who it was). It is a good approach to have at least two knowledgeable people working on new language bindings, in order to review the stuff properly, so if you find out who it was, try to contact him/her. As soon as there is something that looks like a Switft binding, I'll add the components. was (Author: jensg): +1 as well. A few tips to make it an easier way for you: * There is [a nice document over here outlining the general process|http://thrift.apache.org/docs/HowToNewLanguage] * Search the mailing lists archives. There has been at least one other request for Swift in the past (I just don't remember who it was). It is a good approach to have at least two knowledgeable people working on new language bindings, in order to review the stuff properly, so if you find out who it was, try to contact him/her. As an iOS developer, I want a generator and library that produces Swift code Key: THRIFT-3049 URL: https://issues.apache.org/jira/browse/THRIFT-3049 Project: Thrift Issue Type: Epic Components: Compiler (General) Reporter: Juan Moreno Swift is slowly replacing the legacy Objective-C. To keep thrift with the times, let's bake it in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code
[ https://issues.apache.org/jira/browse/THRIFT-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375122#comment-14375122 ] Jens Geyer commented on THRIFT-3049: +1 as well. A few tips to make it an easier way for you: * There is [a nice document over here outlining the general process|http://thrift.apache.org/docs/HowToNewLanguage] * Search the mailing lists archives. There has been at least one other request for Swift in the past (I just don't remember who it was). It is a good approach to have at least two knowledgeable people working on new language bindings, in order to review the stuff properly, so if you find out who it was, try to contact him/her. As an iOS developer, I want a generator and library that produces Swift code Key: THRIFT-3049 URL: https://issues.apache.org/jira/browse/THRIFT-3049 Project: Thrift Issue Type: Epic Components: Compiler (General) Reporter: Juan Moreno Swift is slowly replacing the legacy Objective-C. To keep thrift with the times, let's bake it in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code
[ https://issues.apache.org/jira/browse/THRIFT-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-3049: --- Component/s: (was: Cocoa - Library) (was: Cocoa - Compiler) As an iOS developer, I want a generator and library that produces Swift code Key: THRIFT-3049 URL: https://issues.apache.org/jira/browse/THRIFT-3049 Project: Thrift Issue Type: Epic Components: Compiler (General) Reporter: Juan Moreno Swift is slowly replacing the legacy Objective-C. To keep thrift with the times, let's bake it in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
