[jira] [Commented] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335060#comment-17335060
 ] 

Randy Abernethy commented on THRIFT-5405:
-

Patch attached. Anyone want to review?

> netstd TSocketTransport(IPAddress host, ...) constructor fails to init 
> TcpClient
> 
>
> Key: THRIFT-5405
> URL: https://issues.apache.org/jira/browse/THRIFT-5405
> Project: Thrift
>  Issue Type: Bug
>  Components: netstd - Library
>Affects Versions: 0.14.1
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
> Attachments: 
> 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch
>
>
> netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
> timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-5405:
---

Assignee: Randy Abernethy

> netstd TSocketTransport(IPAddress host, ...) constructor fails to init 
> TcpClient
> 
>
> Key: THRIFT-5405
> URL: https://issues.apache.org/jira/browse/THRIFT-5405
> Project: Thrift
>  Issue Type: Bug
>  Components: netstd - Library
>Affects Versions: 0.14.1
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
> Attachments: 
> 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch
>
>
> netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
> timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-5405:

Attachment: 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch

> netstd TSocketTransport(IPAddress host, ...) constructor fails to init 
> TcpClient
> 
>
> Key: THRIFT-5405
> URL: https://issues.apache.org/jira/browse/THRIFT-5405
> Project: Thrift
>  Issue Type: Bug
>  Components: netstd - Library
>Affects Versions: 0.14.1
>Reporter: Randy Abernethy
>Priority: Minor
> Attachments: 
> 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch
>
>
> netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
> timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

Randy Abernethy created THRIFT-5405:
---

 Summary: netstd TSocketTransport(IPAddress host, ...) constructor 
fails to init TcpClient
 Key: THRIFT-5405
 URL: https://issues.apache.org/jira/browse/THRIFT-5405
 Project: Thrift
  Issue Type: Bug
  Components: netstd - Library
Affects Versions: 0.14.1
Reporter: Randy Abernethy


netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Randy Abernethy (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971461#comment-16971461
 ] 

Randy Abernethy commented on THRIFT-4710:
-

+1

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4815) Golang thrift and Python don't write the same messages

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16789596#comment-16789596
 ] 

Randy Abernethy commented on THRIFT-4815:
-

Also want to add that Apache Thrift has no concern for field order. You can 
pass fields and/or parameters in any order on the wire and a correctly built 
Apache Thrift counter party will receive them without error.

> Golang thrift and Python don't write the same messages
> --
>
> Key: THRIFT-4815
> URL: https://issues.apache.org/jira/browse/THRIFT-4815
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler, Go - Library, Python - Compiler, Python - 
> Library
>Affects Versions: 0.11.0, 0.12.0
> Environment: Python:
> Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 
> bit (AMD64)] on win32
> Thrift version 0.11.0 tested.
> Golang:
> Thrift versions 0.12.0 and 0.11.0 tested
> go version go1.11.4 windows/amd64
> go env:
> set GOARCH=amd64
> set GOBIN=
> set GOCACHE=C:\Users\BUNNY\AppData\Local\go-build
> set GOEXE=.exe
> set GOFLAGS=
> set GOHOSTARCH=amd64
> set GOHOSTOS=windows
> set GOOS=windows
> set GOPATH=C:\Users\BUNNY\go
> set GOPROXY=
> set GORACE=
> set GOROOT=C:\Go
> set GOTMPDIR=
> set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
> set GCCGO=gccgo
> set CC=gcc
> set CXX=g++
> set CGO_ENABLED=1
> set GOMOD=
> set CGO_CFLAGS=-g -O2
> set CGO_CPPFLAGS=
> set CGO_CXXFLAGS=-g -O2
> set CGO_FFLAGS=-g -O2
> set CGO_LDFLAGS=-g -O2
> set PKG_CONFIG=pkg-config
> set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=C:\Users\BUNNY\AppData\Local\Temp\go-build552047466=/tmp/go-build
>  -gno-record-gcc-switches
>Reporter: Jack Flecher
>Assignee: James E. King III
>Priority: Blocker
>  Labels: newbie
> Attachments: bunny.thrift
>
>
> I'm trying to port a tool that relies on Thrift from Python to Golang, it is 
> a client not a server.
> The thrift protocol behaves inconsistent when comparing Python and Golang and 
> it results in breaking applications.
> What it boils down to is I have a struct called Message with a certain amount 
> of fields and I have a sendMessage method that takes that message and sends 
> it to a server which then processes that.
> In Python I can simply make a Message object, set some user's userId as 
> receiver and the text after which I can send the message using sendMessage()
> In Golang I can do the exact same but I run into error responses from the 
> server saying another field that isn't required cannot be found.
> In Python this is the generated POST body sent to the server:
> b'\x82!\x00\x0bsendMessage\x15\x00\x1c(!u218891b1a7af4d21ffe4918acbeb9a73\x88\x04test\x00\x00'
> b'\x82!\x00\x0bsendMessage\x15\x00\x1c(!u218891b1a7af4d21ffe4918acbeb9a73\x88\x05test2\x00\x00'
> In Golang the generated POST body sent to the server:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c(\x04test\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> b'\x82!\x02\x0bsendMessage\x15\x00\x1c(\x05test2\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> As demonstrated above therre are two differences in the generated POST bodies 
> but the one causing the error is the fact that the fields are in a different 
> order than they are supposed to.
> In Golang trying to reverse the order of the fields causes this POST body to 
> be generated:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c\xa8!u218891b1a7af4d21ffe4918acbeb9a73\x08\x04\x04test\x00\x00'
> When commenting out all the fields I actually don't want to be written and 
> then only reversing the functions that are actually writing data, the ones 
> for the receiver and text fields the POST body looks like this:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c(\x04test\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> To summarize, the Thrift protocol on Golang is broken in certain cases 
> because fields are not written in the right order causing other 
> implementatings of Thrift to stop serving Golang Thrift clients.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4801) Take ownership of node-int64 JS module

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16767700#comment-16767700
 ] 

Randy Abernethy commented on THRIFT-4801:
-

[~Kieffer] could you perhaps provide a patch/pull that integrates the 
node-int64 code directly in the js lib? That would give us autonomy without a 
breaking change. [~jking3] Then we could go down the bignum path as needed.

> Take ownership of node-int64 JS module
> --
>
> Key: THRIFT-4801
> URL: https://issues.apache.org/jira/browse/THRIFT-4801
> Project: Thrift
>  Issue Type: Task
>  Components: JavaScript - Library
>Reporter: Robert
>Priority: Major
>
> Hey gang, I wrote/maintain the node-int64. I no longer have an interest in 
> maintaining it, however.
> As Thrift (and various thrift-related projects) seem to be the primary 
> dependents on this module, I thought I'd reach out to see if there was any 
> interest in taking ownership of this code.  Let me know if so.  Otherwise I 
> plan on npm-deprecating it at some future date.
> Cheers!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-1018) Add support for idempotent service requests

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760184#comment-16760184
 ] 

Randy Abernethy commented on THRIFT-1018:
-

Indeed, this would be complex to implement, particularly so in a generic way. 
Completely valid to want impotence but I concur with Allen, it should be an 
application layer concern.

> Add support for idempotent service requests
> ---
>
> Key: THRIFT-1018
> URL: https://issues.apache.org/jira/browse/THRIFT-1018
> Project: Thrift
>  Issue Type: New Feature
>  Components: Wish List
> Environment: NA
>Reporter: Tony Kinnis
>Priority: Major
>
> I would like to be able to flag service methods as idempotent and allow the 
> transport to replay idempotent requests in certain failure cases. I think 
> this would be a valuable feature for Thrift and its community of users.
> High-Level Feature Description:
> Owners of services should be able to flag a service method as idempotent in 
> the IDL. This metadata will need to make its way into the code generated by 
> the compiler. Exactly how that shows up is probably language dependent.
> The transport can then transparently replay the idempotent requests for 
> typical errors, such as connect timeout, interrupted connections, no response 
> received in timeout interval, etc. 
> The replaying of idempotent requests can be disabled/enabled via the 
> transport. In addition to enabling/disabling, the configuration could allow 
> for the number of allowed retries to be specified or even provide a delegate 
> method that decides if the retry is allowed based on the error that occurred 
> and other context. 
> In some cases retries are not desired, even if the method allows for it. In 
> this case the caller can simply disable retries. Likewise, the caller can 
> decide to only retry on a subset of the possible errors by providing a 
> delegate to the transport.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758384#comment-16758384
 ] 

Randy Abernethy commented on THRIFT-4710:
-

If we can make the web/build tooling work I agree that a one repo approach is a 
big win.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4405) Proper use of sequence IDs in all clients and servers

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754603#comment-16754603
 ] 

Randy Abernethy commented on THRIFT-4405:
-

I would reword #3 and 4 a bit but otherwise sounds great.

#3 A server must return the exact seqid received in a request with the response 
to that request.

#4 A server should make no assumptions about the value or semantics of the 
seqid.

 

> Proper use of sequence IDs in all clients and servers
> -
>
> Key: THRIFT-4405
> URL: https://issues.apache.org/jira/browse/THRIFT-4405
> Project: Thrift
>  Issue Type: Improvement
>  Components: Test Suite
>Affects Versions: 0.10.0
> Environment: docker ubuntu-xenial
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Create a feature test that verifies sequence numbers are used properly.  
> Write a server that verifies clients are generating unique sequence IDs.  
> Write a client that makes sure servers return the same sequence ID that was 
> given.
> To do this, I enhanced the C++ TProcessorEventHandler class to include a 
> preReadSeq, which is like preRead but carries the sequence ID.
> In the C++ TestServer, I check to see if the sequence numbers are unique and 
> do not repeat; if any of them do, the cpp test fails.
> The following languages properly send sequence IDs (for the binary protocol):
> * dart
> * go
> * nodejs
> * java
> * rs
> The rest of the languages do not.  Now, one could argue that unless a 
> language has a concurrent-safe client and server, sequence IDs are 
> unnecessary.  While that is true, all languages should respect that the 
> protocol has a sequence ID and there could be future implementations that 
> will require all clients are well-behaved, which is why I am putting this 
> test in.
> Languages fixed up so unique sequence IDs are sent by the client, and 
> verified by the tests:
> * cpp (was only sending unique sequence IDs for Concurrent clients, now it 
> does for the regular one too)
> * csharp (seqid_ was not bring incremented with each use)
> * lua (seqid_ was not bring incremented with each use)
> * perl (seqid_ was not bring incremented with each use)
> * ruby (seqid_ was not bring incremented with each use and a unit test was 
> updated to no longer be pending)
> Languages left to do:
> * c_glib
> * erlang
> * haskell
> * php
> * python
> * python3
> * any non-cross tested languages



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754572#comment-16754572
 ] 

Randy Abernethy commented on THRIFT-2426:
-

Hey Mario,

Yes, would be surprised to get the FB nod to handing over the whole fbthrift 
repo, though it would be great. In the past the FB folks providing the code 
bits have built the pull requests. 

 

--Randy 

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753429#comment-16753429
 ] 

Randy Abernethy commented on THRIFT-2426:
-

The issue is that the Apache 2 lic  requires preservation of copyright. Code in 
the Apache repo can not have copyright Facebook 2014 or whatever (which AFAIK 
all of the fbthrift code is). If fb staff contribute it w/o copyright then it's 
ok. If they blanket grant the fbthrift code to apache then anyone contributing 
it would be ok. As it is, it is not ok.

What can you do?
 # Create a patch and get them to contrib it
 # Get them to provide blanket auth for their entire fbthrift repo to be 
contributed

1 has been done but is a headache for them (and us really). 2 has been rejected 
by them in the past but if you can get it done that would be great.

 

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745602#comment-16745602
 ] 

Randy Abernethy commented on THRIFT-3055:
-

Bummer. Still like the second one from the bottom of the previous list.

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoProposal.pptx, 
> ApacheThriftLogoWip3.pptx, ThriftLogo-UMLConnection.JPG, 
> ThriftLogoUmlIdeas.JPG, screenshot-1.png, screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741605#comment-16741605
 ] 

Randy Abernethy commented on THRIFT-3055:
-

My vote goes to the Candara font version. The Tempus is cool too but, to my 
eye, maybe a bit too stylized and not as versatile as Candara. Just my 2 cents, 
both are great and you are doing the work so either works for me!

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoProposal.pptx, 
> ApacheThriftLogoWip3.pptx, ThriftLogo-UMLConnection.JPG, 
> ThriftLogoUmlIdeas.JPG, screenshot-1.png, screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740966#comment-16740966
 ] 

Randy Abernethy commented on THRIFT-3055:
-

My firm will happily fund the $35 for the image if that's easier. A logo would 
be super awesome.

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoWip3.pptx, 
> ThriftLogo-UMLConnection.JPG, ThriftLogoUmlIdeas.JPG, screenshot-1.png, 
> screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740928#comment-16740928
 ] 

Randy Abernethy commented on THRIFT-3055:
-

>From your 28/Apr/17 07:32 post I like the second from the last one. Funky, 
>cool simple.

 

I also like the puzzle piece one you just posted above with the Apache Thrift. 
Big +1 for either of those.

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoWip3.pptx, 
> ThriftLogo-UMLConnection.JPG, ThriftLogoUmlIdeas.JPG, screenshot-1.png, 
> screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3924) Make C++ library build on SunOS with the Sun compiler

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740447#comment-16740447
 ] 

Randy Abernethy commented on THRIFT-3924:
-

+1 to close this and let any Solaris users in the community reopen if they can 
jump in and help

> Make C++ library build on SunOS with the Sun compiler
> -
>
> Key: THRIFT-3924
> URL: https://issues.apache.org/jira/browse/THRIFT-3924
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
> Environment: 1.upgrade thrift from 0.9.0 to 0.9.2
> 2.SunOS
> 3./opt/SUNWspro/prod/include/CC/Cstd
> 4.CC compiler
>Reporter: Guoguang Lan
>Priority: Minor
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> when Both Clang and GNUC are not define , there is an error!
> 1.upgrade thrift from 0.9.0 to 0.9.2
> 2.SunOS
> 3./opt/SUNWspro/prod/include/CC/Cstd
> compile: CC -DHAVE_CONFIG_H -I. -I../.. -I../../lib/cpp/src/thrift 
> -I/CBB_3rdTools/server/OpenSource/src/thrift/thrift-0.9.2/boost_1_57_0//include
>  -I./src -D_POSIX_PTHREAD_SEMANTICS -D_SUN_ -DSUN 
> -I/CBB_3rdTools/server/OpenSource/src/thrift/thrift-0.9.2/openssl/include 
> -I/CBB_3rdTools/server/OpenSource/src/thrift/thrift-0.9.2/boost_1_57_0/include/boost/tr1
>  -Wextra -pedantic -g -c src/thrift/transport/TFileTransport.cpp -KPIC -DPIC 
> -o src/thrift/transport/.libs/TFileTransport.o CC: Warning: Option -Wextra 
> passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option 
> -pedantic passed to ld, if ld is invoked, ignored otherwise 
> "./src/thrift/cxxfunctional.h", line 124: Error: stdcxx is not a member of 
> apache::thrift.
> when i modify the code like this:
> `#ifdef clang
> /* Clang has two options, depending on standard library:
> - no -stdlib or -stdlib=libstdc++ set; uses GNU libstdc++.
> - -stdlib=libc++; uses LLVM libc++.
> , no 'std::tr1'. *
> The compiler itself doesn't define anything differently
> depending on the value of -stdlib, but the library headers
> will set different preprocessor options. In order to check,
> though, we have to pull in some library header.
> */
> #include
> /* With LLVM libc++, utility pulls in __config, which sets
> _LIBCPP_VERSION. */
> #if defined(_LIBCPP_VERSION)
> #define _THRIFT_USING_CLANG_LIBCXX 1
> /* With GNU libstdc++, utility pulls in bits/c++config.h,
> which sets GLIBCXX. */
> #elif defined(GLIBCXX)
> #define _THRIFT_USING_GNU_LIBSTDCXX 1
> /* No idea. /
> #else
> #error Unable to detect which C++ standard library is in use.
> #endif
> #elif GNUC
> #define _THRIFT_USING_GNU_LIBSTDCXX 1
> / No idea. */
> #else
> #error Unable to detect which C++ standard library is in use. Both Clang and 
> GNUC are not define!
> #endif`
> output:
> "./src/thrift/cxxfunctional.h", line 71: Error: #error Unable to detect which 
> C++ standard library is in use. Both Clang and GNUC are not define!.
> Thank you!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2242) Generate C++11 code

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736267#comment-16736267
 ] 

Randy Abernethy commented on THRIFT-2242:
-

I just want to shout this loudly, Thrift Sets [at the IDL level] are unordered. 
You can implement them in a server or client with ordered sets or unordered 
sets (in C++ using the hack James mentions or with annotations in Java). 
However on the wire, you must not expect a set or map to be ordered, only a 
list.

> Generate C++11 code
> ---
>
> Key: THRIFT-2242
> URL: https://issues.apache.org/jira/browse/THRIFT-2242
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.1
>Reporter: Vitali Lovich
>Priority: Major
>
> unordered_map instead of map, unordered_set instead of set, noexcept instead 
> of throw() (unless the exact semantics of throw() are needed which seems 
> unlikely).
> It should use the shared_ptr implementation that the library is configured 
> with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4156) Using boost spirit instead of lex and yacc

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736250#comment-16736250
 ] 

Randy Abernethy commented on THRIFT-4156:
-

While it strikes me as a cool project, to [~jking3] 's point, it is the kind of 
thing that is not going to add a ton of value to end users and it will create a 
knowledge gap for existing committers. This means we spend less time actually 
adding value for the end users in the community. If Thrift IDL was in dynamic 
development the hit might amortize well, however, if that were the case I might 
vote for a move to Python. As it is I am a -1 on this ticket.

> Using boost spirit instead of lex and yacc
> --
>
> Key: THRIFT-4156
> URL: https://issues.apache.org/jira/browse/THRIFT-4156
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Reporter: Mike Gresens
>Priority: Major
> Attachments: MyService.hpp, MyService.thrift, ast.hpp, 
> doxygen_enum.png, doxygen_service.png, doxygen_struct.png, parser.cpp
>
>
> As a developer I want to use boost spirit to get rid of lex and yacc.
> This kicks dependency to lex, flex, yacc, bison or what ever.
> This makes building easier, because only c++ code must be compiled.
> All grammar is inside the code - all c++. No need to learn ll and yy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4723) Consolidate C# and netcore into new netstd language target and finally deprecate both C# and netcore bindings

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734969#comment-16734969
 ] 

Randy Abernethy commented on THRIFT-4723:
-

+1

> Consolidate C# and netcore into new netstd language target and finally 
> deprecate both C# and netcore bindings
> -
>
> Key: THRIFT-4723
> URL: https://issues.apache.org/jira/browse/THRIFT-4723
> Project: Thrift
>  Issue Type: Umbrella
>  Components: C# - Compiler, C# - Library, netcore - Compiler, netcore 
> - Library
> Environment: .NET and Mono
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
>  Labels: Umbrella
>
> There are too many differences to get C# effectively merged into netcore. 
> Because also the name is/would be misleading, the proposal is to have a new 
> *netstd* target which users can migrate to at will, not by force. The end 
> goal is of course to deprecate and remove both the existing C# as well as the 
> existing netcore bindings and only maintain netstd bindings.
> *Purpose of this umbrella ticket is only to host all sub-tasks.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4639) Sequence numbering for multiplexed protocol broken

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734959#comment-16734959
 ] 

Randy Abernethy commented on THRIFT-4639:
-

[~jking3], Thrift JavaScript does and always has depended on seq nums. It is an 
asyn language by nature and if you make multiple requests, while they will be 
returned in order, there is no way for the callback dispatcher to know which 
call back to call without the seq num. 

All servers should return whatever is passed in the seq num field back to the 
client in the response. There is a reason the C++  readMessageBegin(fname, 
mtype, seqid) signature includes seqid. While JavaScript requires sequence 
numbers many languages could benefit from seq numbers in their async impls. You 
are right though we have work to do (though each fix is trivial) to comply with 
this maxim.

I think it would be better said that:
 # Thrift Clients should not require sequence numbers, though they may use them 
 # Thrift Servers must return the seq num they receive with a request with the 
response (n.b. this is work in progress)

 

> Sequence numbering for multiplexed protocol broken
> --
>
> Key: THRIFT-4639
> URL: https://issues.apache.org/jira/browse/THRIFT-4639
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.11.0, 0.12.0
>Reporter: PH Lundblom
>Priority: Critical
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Handling of client sequence numbering for multiplexed protocol is broken.
> Current implementation uses client internal variable "seqid" which should be 
> "_seqid"
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2464) Transition cpp_type and cpp_include keywords to compiler annotations

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733529#comment-16733529
 ] 

Randy Abernethy commented on THRIFT-2464:
-

I have a different view, it is a feature I use and find elegant and chaos free  
!/jira/images/icons/emoticons/smile.png! .

Clearly if you use an implementation type that is incompatible with the 
abstract IDL type or protocol interface you will have problems, just like if 
you don't eat you will starve, I don't think we need to police this. To your 
point, type substitution is not a feature anyone should reach for at the 
outset, rather a feature that allows Thrift to easily accommodate needs related 
to performance, version changes and customization. Many languages have multiple 
IDL-type compatible implementation-types, yet with no specific one being the 
fastest/best for all use cases (lists, vectors, ints, boxed ints, hashmaps, 
treemaps, dictionaries, counters, etc.). Also new types (especially container 
types) can show up over time (v1, v2, v3) making "the best" default hard to 
specify. This feature also allows custom types to be implemented. In none of 
these cases does the impl complexity leak into Thrift, the Thrift IDL types and 
wire serialization are unimpacted.

What is a mess is the implementation we have. We have annotations for "final", 
and Java map types then these crazy keyword impls for C++. The cpp_* kws 
predate annotations and should have been moved over with the introduction of 
annotations.

I also think we should rigorously reject new Thrift IDL types as they break the 
world and spawn huge amounts of work throughout the platform (every lib, every 
protocol) [I am not a fan of the self referential types we have half 
implemented]. In a tool chain used for cross platform compatibility, changing 
the IDL type support is the worst thing we can do and should really only happen 
when extreme benefits are present. This view makes me that much more interested 
in living with the simple and elegant Thrift IDL types yet having the option to 
choose or create my own implementations without impacting client or having to 
modify Thrift at all.

 

 

> Transition cpp_type and cpp_include keywords to compiler annotations
> 
>
> Key: THRIFT-2464
> URL: https://issues.apache.org/jira/browse/THRIFT-2464
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Affects Versions: 0.9.2
> Environment: C++
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> The cpp_type and cpp_include keywords provide a useful feature but are 
> language specific. In keeping with the trend of moving the interface language 
> to a clean cross implementation language abstraction, these two keywords 
> should be transitioned to annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2927) Statistic function support (call analytics: duration, success-count, failure-count, etc..)

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733495#comment-16733495
 ] 

Randy Abernethy commented on THRIFT-2927:
-

Sounds like consensus. Should we close this?

> Statistic function support (call analytics: duration, success-count, 
> failure-count, etc..)
> --
>
> Key: THRIFT-2927
> URL: https://issues.apache.org/jira/browse/THRIFT-2927
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.2
> Environment: linux c++
>Reporter: Shi Jun
>Priority: Major
>
> As a RPC framework, Thrift should support some statistic function, such as 
> latency、call times、failure rate and so on. And all these things can be done 
> by the framework, applications just need to use a make argument to open the 
> statistic function switch or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2927) Statistic function support (call analytics: duration, success-count, failure-count, etc..)

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733394#comment-16733394
 ] 

Randy Abernethy commented on THRIFT-2927:
-

There are a lot of external solutions for observability. For example, the 
service mesh model often used in cloud native systems provides 
monitoring/metering access points at each service ingress/egress (e.g. 
[https://istio.io/).]  There are also cross platform tracing solutions that 
offer some of these features (e.g. [https://opentracing.io/,] 
[https://www.jaegertracing.io/).] To Jens' point leaving these concerns as a 
choice external to thrift makes it optional and allows people to make choices 
that will work for all of their platform elements (Thrift, messaging, REST, 
custom, etc.).

> Statistic function support (call analytics: duration, success-count, 
> failure-count, etc..)
> --
>
> Key: THRIFT-2927
> URL: https://issues.apache.org/jira/browse/THRIFT-2927
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.2
> Environment: linux c++
>Reporter: Shi Jun
>Priority: Major
>
> As a RPC framework, Thrift should support some statistic function, such as 
> latency、call times、failure rate and so on. And all these things can be done 
> by the framework, applications just need to use a make argument to open the 
> statistic function switch or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2464) Transition cpp_type and cpp_include keywords to compiler annotations

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733271#comment-16733271
 ] 

Randy Abernethy commented on THRIFT-2464:
-

This is covered pretty thoroughly in chapter 5 of the Programmer's Guide to 
Apache Thrift. I agree Thrift should supply standard cross platform types that 
work across all languages. However there are multiple layers of abstraction in 
Thrift:
 # IDL - the conceptual types
 # wire - the protocol based serialization of the types
 # language - the language specific implementation of the types

It is in #3 that the impl may need to be (or could benefit from) being tweaked. 
The IDL compiler might generate a Java TreeMap for a Thrift Map or it might 
generate a HashMap. We can not say which is the right answer without a use case.

It is also important to note that the language impl has (must have) no impact 
on the wire or conceptual type representations. Adding types to the IDL or wire 
layers is a breaking Thrift wide interface change and I think should be avoided 
unless tremendous benefit is imparted. On the other hand, changing impl types 
is by definition an implementation detail that no one on the other side of the 
RPC should care about.

In short, I agree with [~jking3] that the cpp_type and cpp_include keywords 
should be removed but the functionality should be preserved through Thrift 
annotations. So my vote is that until we have the annotations working we do not 
remove the keywords.

The annotation solution would look something like this:

{{(cpp.include = "unordered_map")}}

{{exception BadFishes {}}
{{    1: map (cpp.type "std::unordered_map")   
fish_errors}}
{{}}}

Should be an easy change.

 

> Transition cpp_type and cpp_include keywords to compiler annotations
> 
>
> Key: THRIFT-2464
> URL: https://issues.apache.org/jira/browse/THRIFT-2464
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Affects Versions: 0.9.2
> Environment: C++
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> The cpp_type and cpp_include keywords provide a useful feature but are 
> language specific. In keeping with the trend of moving the interface language 
> to a clean cross implementation language abstraction, these two keywords 
> should be transitioned to annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4710) Move all website content to markdown within the project

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732252#comment-16732252
 ] 

Randy Abernethy commented on THRIFT-4710:
-

In my experience putting docs and code together is a good way of reducing 
duplicate effort, keeping code/docs in sync and keeping related things in the 
same place. These principles are the reasons for Javadoc, Pydoc, etc. The 
humans create the docs as they code and commit both together and then the 
automation renders the content into whatever format(s) required (html, pdf, 
etc.).

I think the above suggestion of a single pull request is a really important 
feature we should try to enable. The PR should include the code, the tests and 
the docs.

Another thought is, as a developer, when I clone a repo, getting the code and 
docs together is an uptick not an inconvenience. The MDs are small and there 
should probably be only one/zero (readme.md?) per directory. I don't think 
we'll need to worry about images as our doc images will be mainly code snippets.

 

My 2 cents

> Move all website content to markdown within the project
> ---
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4710) Abandon Apache CMS in favor of a different website content management system

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731676#comment-16731676
 ] 

Randy Abernethy commented on THRIFT-4710:
-

Per mail list disc., big +1 for all github style MD based docs. In tree would 
be my pref.

> Abandon Apache CMS in favor of a different website content management system
> 
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Priority: Blocker
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4705) Update packages and maintainer list on nuget

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731656#comment-16731656
 ] 

Randy Abernethy commented on THRIFT-4705:
-

Just added you. It is pending (thinking you'll be active once you respond to 
the invite email but can't remember the exact process flow). LMK if you need 
anything else on this.

> Update packages and maintainer list on nuget
> 
>
> Key: THRIFT-4705
> URL: https://issues.apache.org/jira/browse/THRIFT-4705
> Project: Thrift
>  Issue Type: Task
>  Components: C# - Library
>Affects Versions: 0.10.0, 0.11.0, 0.12.0
>Reporter: James E. King III
>Assignee: Jake Farrell
>Priority: Critical
>
> [~jfarrell] [~codesf] please update the list of maintainers on nuget to 
> include other release managers.  My account username on nuget is "jking3".  
> The latest package on nuget is 0.9.3 - I can upload 0.10.0 through 0.12.0 
> once I have permission.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4697) Create updated release procedures

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16730817#comment-16730817
 ] 

Randy Abernethy commented on THRIFT-4697:
-

Discussion on another thread suggested moving the web site (docs for the 
project) to pure markdown. I think it would simplify things, and thus, 
incentivize more documentation. One suggestion was to create a separate docs 
repo, personally i think it would be easiest to keep it in tree if pos.

 

Any thoughts on this?

> Create updated release procedures
> -
>
> Key: THRIFT-4697
> URL: https://issues.apache.org/jira/browse/THRIFT-4697
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
>
> During the 0.12.0 release cycle I took a lot of notes.  This needs to be 
> codified and checked in as markdown, so the web site can pull it in.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4678) add noexcept cpp generator option

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726234#comment-16726234
 ] 

Randy Abernethy commented on THRIFT-4678:
-

Big +1 for removing all dependencies on boost. Love boost but given all of the 
possible environments people might want to use Thrift in and how fundamental a 
utility it is for people, I think we should aggressively, across the board, 
keep deps to a min. Thrift should work with boost but not require it.

The one problem area is tests. Our C++ solution right now is boost/test and it 
is probably best to leave it in place but of course this does not impact the 
runtime lib or sources.

> add noexcept cpp generator option
> -
>
> Key: THRIFT-4678
> URL: https://issues.apache.org/jira/browse/THRIFT-4678
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.11.0
>Reporter: yuanyuan chen
>Priority: Minor
>
> The C++11 standard has deprecated the usage of throw() to express 
> exceptions,so to avoid warnings from the compiler,I think this option is 
> useful.
> I have a pull request in github,this issue is created to track it.
> Some questions remain:
> 1.Should we change the runtime c++ library to use BOOST_NOEXCEPT_OR_NOTHROW?
> 2.Should we add an control option to enable all c++11 options like 
> moveable_types .etc?
> 3.Should we begin to support C+17 features? I think std::optional should be 
> used to implement optional keyword,but this is clearly an API breaking 
> change,so we need an c+17 control option.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4574) Add NanoPb-like support

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489649#comment-16489649
 ] 

Randy Abernethy commented on THRIFT-4574:
-

I agree, It would be nice to have a pure C implementation of Thrift. Patches 
welcome!

> Add NanoPb-like support
> ---
>
> Key: THRIFT-4574
> URL: https://issues.apache.org/jira/browse/THRIFT-4574
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Anatol Pomozov
>Priority: Minor
>
> Thrift has a support for C language called c_glib. This generator creates a 
> stub for C language that uses quite glib library. glib library is quite heavy 
> dependency and for some cases (like low level software) is not acceptable. 
> One need a generator that does not have any dependencies to third-party libs 
> and ideally neither to libc.
> nanopb project tries to achieve it for Protobufs. It would be great to see 
> something similar for Thrift. Here is more information about nanopb 
> [http://jpa.kapsi.fi/nanopb/docs/concepts.html]
> There is an attempt to implement such generator 
> [https://github.com/markrileybot/thrift-nano] but it might require additional 
> efforts to make the implementation up-to-date and complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4574) Add NanoPb-like support

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-4574:

Issue Type: Improvement  (was: Bug)

> Add NanoPb-like support
> ---
>
> Key: THRIFT-4574
> URL: https://issues.apache.org/jira/browse/THRIFT-4574
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Anatol Pomozov
>Priority: Minor
>
> Thrift has a support for C language called c_glib. This generator creates a 
> stub for C language that uses quite glib library. glib library is quite heavy 
> dependency and for some cases (like low level software) is not acceptable. 
> One need a generator that does not have any dependencies to third-party libs 
> and ideally neither to libc.
> nanopb project tries to achieve it for Protobufs. It would be great to see 
> something similar for Thrift. Here is more information about nanopb 
> [http://jpa.kapsi.fi/nanopb/docs/concepts.html]
> There is an attempt to implement such generator 
> [https://github.com/markrileybot/thrift-nano] but it might require additional 
> efforts to make the implementation up-to-date and complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4280) Add async nonblocking ssl support in java client

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-4280:
---

 Summary: Add async nonblocking ssl support in java client
 Key: THRIFT-4280
 URL: https://issues.apache.org/jira/browse/THRIFT-4280
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.10.0
Reporter: Randy Abernethy
Priority: Minor
 Fix For: 0.10.0


Add async nonblocking ssl support in java client



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-4276.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

committed 

> Add SSL support to the C++ Nonblocking Server
> -
>
> Key: THRIFT-4276
> URL: https://issues.apache.org/jira/browse/THRIFT-4276
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.11.0
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
> Fix For: 0.10.0
>
>
> This patch adds SSL support to the C++ noblocking server and cleans up some 
> of its monolithic integrated transport, moving to a more flexible and typical 
> Apache Thrift Transport model.
> Many thanks to Divya and James for the work on this
> GitHub user dthaluru opened a pull request:
> https://github.com/apache/thrift/pull/1251
> Added support for C++ Nonblocking SSL Server
> You can merge this pull request into a Git repository by running:
> $ git pull https://github.com/dthaluru/cpp-nonblocking1 master
> Alternatively you can review and apply these changes as the patch at:
> https://github.com/apache/thrift/pull/1251.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 #1251
> 
> 
> commit 6351c2c112affbe4ca7677236605030e72ffa057
> Author: Divya Thaluru 
> Date:   2017-04-20T17:35:10Z
> Added support for C++ Nonblocking SSL Server
> 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-4276:

Description: 
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this


GitHub user dthaluru opened a pull request:

https://github.com/apache/thrift/pull/1251

Added support for C++ Nonblocking SSL Server

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dthaluru/cpp-nonblocking1 master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1251.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 #1251


commit 6351c2c112affbe4ca7677236605030e72ffa057
Author: Divya Thaluru 
Date:   2017-04-20T17:35:10Z

Added support for C++ Nonblocking SSL Server






  was:
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this


GitHub user dthaluru opened a pull request:

https://github.com/apache/thrift/pull/1251

Added support for C++ Nonblocking SSL Server

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dthaluru/cpp-nonblocking1 master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1251.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 #89


commit 6351c2c112affbe4ca7677236605030e72ffa057
Author: Divya Thaluru 
Date:   2017-04-20T17:35:10Z

Added support for C++ Nonblocking SSL Server







> Add SSL support to the C++ Nonblocking Server
> -
>
> Key: THRIFT-4276
> URL: https://issues.apache.org/jira/browse/THRIFT-4276
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.11.0
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> This patch adds SSL support to the C++ noblocking server and cleans up some 
> of its monolithic integrated transport, moving to a more flexible and typical 
> Apache Thrift Transport model.
> Many thanks to Divya and James for the work on this
> GitHub user dthaluru opened a pull request:
> https://github.com/apache/thrift/pull/1251
> Added support for C++ Nonblocking SSL Server
> You can merge this pull request into a Git repository by running:
> $ git pull https://github.com/dthaluru/cpp-nonblocking1 master
> Alternatively you can review and apply these changes as the patch at:
> https://github.com/apache/thrift/pull/1251.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 #1251
> 
> 
> commit 6351c2c112affbe4ca7677236605030e72ffa057
> Author: Divya Thaluru 
> Date:   2017-04-20T17:35:10Z
> Added support for C++ Nonblocking SSL Server
> 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-4276:

Description: 
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this


GitHub user dthaluru opened a pull request:

https://github.com/apache/thrift/pull/1251

Added support for C++ Nonblocking SSL Server

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dthaluru/cpp-nonblocking1 master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1251.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 #89


commit 6351c2c112affbe4ca7677236605030e72ffa057
Author: Divya Thaluru 
Date:   2017-04-20T17:35:10Z

Added support for C++ Nonblocking SSL Server






  was:
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this

https://github.com/apache/thrift/pull/1251


> Add SSL support to the C++ Nonblocking Server
> -
>
> Key: THRIFT-4276
> URL: https://issues.apache.org/jira/browse/THRIFT-4276
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.11.0
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> This patch adds SSL support to the C++ noblocking server and cleans up some 
> of its monolithic integrated transport, moving to a more flexible and typical 
> Apache Thrift Transport model.
> Many thanks to Divya and James for the work on this
> GitHub user dthaluru opened a pull request:
> https://github.com/apache/thrift/pull/1251
> Added support for C++ Nonblocking SSL Server
> You can merge this pull request into a Git repository by running:
> $ git pull https://github.com/dthaluru/cpp-nonblocking1 master
> Alternatively you can review and apply these changes as the patch at:
> https://github.com/apache/thrift/pull/1251.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 #89
> 
> 
> commit 6351c2c112affbe4ca7677236605030e72ffa057
> Author: Divya Thaluru 
> Date:   2017-04-20T17:35:10Z
> Added support for C++ Nonblocking SSL Server
> 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-4276:
---

 Summary: Add SSL support to the C++ Nonblocking Server
 Key: THRIFT-4276
 URL: https://issues.apache.org/jira/browse/THRIFT-4276
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Library
Affects Versions: 0.11.0
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor


This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this

https://github.com/apache/thrift/pull/1251



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4176) Implement a threaded and threadpool server type for Rust

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972684#comment-15972684
 ] 

Randy Abernethy commented on THRIFT-4176:
-

I would argue for a single great rust server. Multiple servers confuse users, 
they don't want to have to figure out which server to use and in most cases 
there is one server model that performs best or close enough in the vast 
majority of cases. If users need hyper performance or special cases they will 
probably write their own anyway. One server will reduce testing burden and 
focus all improvements iin one place. Some of our languages (Java/c++) look 
like a server science project and have caused users to waste huge sums of time 
trying to compare performance and features (often without the necessary 
context).. just my 2 cents



> Implement a threaded and threadpool server type for Rust
> 
>
> Key: THRIFT-4176
> URL: https://issues.apache.org/jira/browse/THRIFT-4176
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>
> Currently the Rust client library only provides a single-threaded server. Add 
> both a multi-threaded server and a threadpool-based server and add the 
> relevant options to the cross-test code as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (THRIFT-4175) ts and with_ns options added to js generator with no help text

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy closed THRIFT-4175.
---
Resolution: Invalid

user error

> ts and with_ns options added to js generator with no help text
> --
>
> Key: THRIFT-4175
> URL: https://issues.apache.org/jira/browse/THRIFT-4175
> Project: Thrift
>  Issue Type: Improvement
>  Components: JavaScript - Compiler
>Affects Versions: 0.10.0
>Reporter: Randy Abernethy
>Priority: Minor
>
> thrift -help says nothing about js:ts or js:with_ns



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (THRIFT-4175) ts and with_ns options added to js generator with no help text

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-4175:
---

 Summary: ts and with_ns options added to js generator with no help 
text
 Key: THRIFT-4175
 URL: https://issues.apache.org/jira/browse/THRIFT-4175
 Project: Thrift
  Issue Type: Improvement
  Components: JavaScript - Compiler
Affects Versions: 0.10.0
Reporter: Randy Abernethy
Priority: Minor


thrift -help says nothing about js:ts or js:with_ns



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (THRIFT-4131) Javascript with WebSocket handles oneway methods wrong

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-4131:

Attachment: 0001-js-WebSocket-Fix-handling-oneway-methods.patch

proposed patch

> Javascript with WebSocket handles oneway methods wrong
> --
>
> Key: THRIFT-4131
> URL: https://issues.apache.org/jira/browse/THRIFT-4131
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.10.0
> Environment: all
>Reporter: Martin Hejnfelt
>Assignee: Randy Abernethy
>Priority: Blocker
> Attachments: 0001-js-WebSocket-Fix-handling-oneway-methods.patch
>
>
> When using the WebSocket transport all client->server calls install a 
> callback, and we depend on these callbacks being push()'ed and shift()'ed 
> sequentially, however, oneway methods never gets a reply, and therefore the 
> installed callback doesn't get removed, causing the callback array to get 
> "out of synchronization" so to speak, and subsequent calls, now deal with the 
> wrong callbacks, as data comes in.
> To remedy this I changed the compiler/generator to send a null callback to 
> the transport->flush method for oneway methods, and then in the WebSocket 
> transport code, make a null check and only install defined callbacks. This 
> seem to fix it for me. I can send in patches if necessary.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4131) Javascript with WebSocket handles oneway methods wrong

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15938478#comment-15938478
 ] 

Randy Abernethy commented on THRIFT-4131:
-

Would be great to get the patch, please attach (or if you prefer a pull request 
is fine too).

> Javascript with WebSocket handles oneway methods wrong
> --
>
> Key: THRIFT-4131
> URL: https://issues.apache.org/jira/browse/THRIFT-4131
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.10.0
> Environment: all
>Reporter: Martin Hejnfelt
>Assignee: Randy Abernethy
>Priority: Blocker
>
> When using the WebSocket transport all client->server calls install a 
> callback, and we depend on these callbacks being push()'ed and shift()'ed 
> sequentially, however, oneway methods never gets a reply, and therefore the 
> installed callback doesn't get removed, causing the callback array to get 
> "out of synchronization" so to speak, and subsequent calls, now deal with the 
> wrong callbacks, as data comes in.
> To remedy this I changed the compiler/generator to send a null callback to 
> the transport->flush method for oneway methods, and then in the WebSocket 
> transport code, make a null check and only install defined callbacks. This 
> seem to fix it for me. I can send in patches if necessary.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (THRIFT-4131) Javascript with WebSocket handles oneway methods wrong

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-4131:
---

Assignee: Randy Abernethy

> Javascript with WebSocket handles oneway methods wrong
> --
>
> Key: THRIFT-4131
> URL: https://issues.apache.org/jira/browse/THRIFT-4131
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.10.0
> Environment: all
>Reporter: Martin Hejnfelt
>Assignee: Randy Abernethy
>Priority: Blocker
>
> When using the WebSocket transport all client->server calls install a 
> callback, and we depend on these callbacks being push()'ed and shift()'ed 
> sequentially, however, oneway methods never gets a reply, and therefore the 
> installed callback doesn't get removed, causing the callback array to get 
> "out of synchronization" so to speak, and subsequent calls, now deal with the 
> wrong callbacks, as data comes in.
> To remedy this I changed the compiler/generator to send a null callback to 
> the transport->flush method for oneway methods, and then in the WebSocket 
> transport code, make a null check and only install defined callbacks. This 
> seem to fix it for me. I can send in patches if necessary.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (THRIFT-4123) Add support for .Net Core

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-4123:
---

 Summary: Add support for .Net Core
 Key: THRIFT-4123
 URL: https://issues.apache.org/jira/browse/THRIFT-4123
 Project: Thrift
  Issue Type: Improvement
  Components: C# - Compiler, C# - Library
Affects Versions: 0.10.0
 Environment: C#
Reporter: Randy Abernethy
Priority: Minor


Presently the thrift compiler C# generator includes the line:

{code}
using System.Runtime.Serialization;
{code}

And uses the annotation:

{code}
#if !SILVERLIGHT
[Serializable]
#endif
{code}

Binary serialization was dropped from .Net Core. As .Net Core is the "go 
forward" cross platform engine for .Net it would be great if we could improve 
the C# impl such that it runs on .Net Framework and .Net Core.

Ref:   
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-3546) NodeJS code should not be namespaced (and is currently not strict-mode compliant)

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568897#comment-15568897
 ] 

Randy Abernethy commented on THRIFT-3546:
-

+1

> NodeJS code should not be namespaced (and is currently not strict-mode 
> compliant)
> -
>
> Key: THRIFT-3546
> URL: https://issues.apache.org/jira/browse/THRIFT-3546
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Compiler
>Affects Versions: 0.9.3
>Reporter: Yunchi Luo
>
> Code generated for NodeJS, whether with a js namespace specified or not, 
> seems to fail strict mode. Specifically, it doesn't always generate "var" 
> when needed. This might not sound like a big issue but it's quite a pain to 
> deal with...
> It is standard nowadays to enable strict mode for Javascript code 
> (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode).
>  And babel, which is one of most popular ES6 => ES5 transpilers, while does 
> not force strict mode, does seem to break when you don't use "var".
> I think the best solution here is really to just stop using namespaces in 
> node code. Every type will be declared with "var", and if exported, also 
> assigned to "module.exports".
> I don't believe namespaces currently generated in the node code is directly 
> used anywhere or is even accessible outside the file?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3787) Node.js Connection object doesn't handle errors correctly

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3787.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

committed, thanks for the patch!

missed the attrib on this one, apologies. You are in the patch field. Will get 
you in the author field next go.

> Node.js Connection object doesn't handle errors correctly
> -
>
> Key: THRIFT-3787
> URL: https://issues.apache.org/jira/browse/THRIFT-3787
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
>Priority: Minor
> Fix For: 0.10.0
>
>
> There are a handful of operation-ordering problems in the 
> Connection.prototype.connection_gone() method and its friends.
> See the pull request for more details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3787) Node.js Connection object doesn't handle errors correctly

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273565#comment-15273565
 ] 

Randy Abernethy commented on THRIFT-3787:
-

Hey James,

Regarding this particular hunk, from the Node docs:

"For all EventEmitter objects, if an 'error' event handler is not provided, the 
error will be thrown, causing the Node.js process to report an unhandled 
exception and crash unless either: The domain module is used appropriately or a 
handler has been registered for the process.on('uncaughtException') event."

So while this code predates me I think it was trying to protect user code from 
spurious exceptions. Unless you have a different view I'd rather leave this 
hunk in place (until we get your deep refactor!). 

The other changes look good (particularly the ssl test below). Let me know if 
you want to commit the other hunks. 

-Randy 


> Node.js Connection object doesn't handle errors correctly
> -
>
> Key: THRIFT-3787
> URL: https://issues.apache.org/jira/browse/THRIFT-3787
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
>Priority: Minor
>
> There are a handful of operation-ordering problems in the 
> Connection.prototype.connection_gone() method and its friends.
> See the pull request for more details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3789) Node.js lacks ability to destroy connection

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3789.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

committed

> Node.js lacks ability to destroy connection
> ---
>
> Key: THRIFT-3789
> URL: https://issues.apache.org/jira/browse/THRIFT-3789
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
>Priority: Trivial
> Fix For: 0.10.0
>
>
> At present, there is no means for destroying the socket underlying a Node.js 
> Thrift Connection. When using TLS, If the socket fails to connect, calling 
> end() is insufficient to release its resources. (end() sends a FIN packet, 
> which is never acknowledged, holding the socket open.) This unreleased socket 
> will prevent Node.js from exiting cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3789) Node.js lacks ability to destroy connection

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-3789:
---

Assignee: Randy Abernethy

> Node.js lacks ability to destroy connection
> ---
>
> Key: THRIFT-3789
> URL: https://issues.apache.org/jira/browse/THRIFT-3789
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
>Priority: Trivial
>
> At present, there is no means for destroying the socket underlying a Node.js 
> Thrift Connection. When using TLS, If the socket fails to connect, calling 
> end() is insufficient to release its resources. (end() sends a FIN packet, 
> which is never acknowledged, holding the socket open.) This unreleased socket 
> will prevent Node.js from exiting cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3787) Node.js Connection object doesn't handle errors correctly

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-3787:
---

Assignee: Randy Abernethy

> Node.js Connection object doesn't handle errors correctly
> -
>
> Key: THRIFT-3787
> URL: https://issues.apache.org/jira/browse/THRIFT-3787
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
>Priority: Minor
>
> There are a handful of operation-ordering problems in the 
> Connection.prototype.connection_gone() method and its friends.
> See the pull request for more details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-2821) Enable the use of custom HTTP-Header in the Transport

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-2821.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

Committed, thanks for the patch David.

> Enable the use of custom HTTP-Header in the Transport
> -
>
> Key: THRIFT-2821
> URL: https://issues.apache.org/jira/browse/THRIFT-2821
> Project: Thrift
>  Issue Type: Improvement
>  Components: JavaScript - Library
>Affects Versions: 0.9.2
> Environment: Browser
>Reporter: David Sautter
>Assignee: Randy Abernethy
>Priority: Trivial
>  Labels: features
> Fix For: 0.10.0
>
> Attachments: 
> 0001-THRIFT-2821-Enable-the-use-of-custom-HTTP-Header-in-.patch, javascript 
> http header support.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Several Thrift server implementations (for example csharp) enable to read 
> custom HTTP Headers, but the JavaScript Client is not yet able to provide 
> them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-2821) Enable the use of custom HTTP-Header in the Transport

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-2821:

Attachment: javascript http header support.patch

updated patch

> Enable the use of custom HTTP-Header in the Transport
> -
>
> Key: THRIFT-2821
> URL: https://issues.apache.org/jira/browse/THRIFT-2821
> Project: Thrift
>  Issue Type: Improvement
>  Components: JavaScript - Library
>Affects Versions: 0.9.2
> Environment: Browser
>Reporter: David Sautter
>Assignee: Randy Abernethy
>Priority: Trivial
>  Labels: features
> Attachments: 
> 0001-THRIFT-2821-Enable-the-use-of-custom-HTTP-Header-in-.patch, javascript 
> http header support.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Several Thrift server implementations (for example csharp) enable to read 
> custom HTTP Headers, but the JavaScript Client is not yet able to provide 
> them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3156) Node TLS: server executes processing logic two full times

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3156.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

Thanks for the report, spot on. Fixed by patch for 3786. Please reopen if you 
don't see things corrected after applying 3786.

> Node TLS: server executes processing logic two full times
> -
>
> Key: THRIFT-3156
> URL: https://issues.apache.org/jira/browse/THRIFT-3156
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
> Environment: OS X w/ Node.js
>Reporter: John Batte
> Fix For: 0.10.0
>
> Attachments: thrift-jira-evidence.zip
>
>
> h4. Using attached {{thrift-jira-evidence.zip}}
> {code}
> $ unzip thrift-jira-evidence.zip
> $ cd thrift-jira-evidence
> {code}
> *Note*: you'll need a total of three certs: {{ca.crt}}, {{server.crt}}, and 
> {{server.key}}. These have not been provided in the evidence. 
> h4. Server side reproduce steps
> # {{cd server}}
> # Copy {{ca.crt}} to {{config/ssl/ca.crt}}
> # Copy {{server.crt}} to {{config/ssl/server.crt}}
> # Copy {{server.key}} to {{config/ssl/server.key}}
> # {{npm install}}
> # {{NODE_DEBUG="tls" npm start}}
> h5. Server output after server start
> {code}
> > thrift-tls-experiment@0.0.0 start /your/path/to/server
> > node ./src/node/index.js
> Thrift service now listening on port 9797
> {code}
> h4. Client side reproduce steps
> # {{cd client}}
> # Copy {{ca.crt}} to {{config/ssl/ca.crt}}
> # {{npm install}}
> # {{NODE_DEBUG="tls" npm start}}
> h5. Client output after client start
> {code}
> > thrift-tls-experiment@0.0.0 start /your/path/to/client
> > node ./src/node/index.js
> Creating connection host: localhost port: 9797
> Creating client
> Sending: Hello, World!
> TLS 15599: secure established
> Response received!
> Killing connection
> Success! Hello, World! >> !dlroW ,olleH
> {code}
> h5. Server output after client start
> {code}
> TLS 15547: onhandshakestart
> TLS 15547: onhandshakedone
> TLS 15547: secure established
> Mapping to specific processor call
> Trace: Inside process_reverse
> at TermReverserProcessor.process_reverse 
> (/your/path/to/server/src/node/contracts/TermReverser.js:196:11)
> at TermReverserProcessor.process 
> (/your/path/to/server/src/node/contracts/TermReverser.js:183:39)
> at /your/path/to/server/node_modules/thrift/lib/thrift/server.js:55:21
> at TLSSocket. 
> (/your/path/to/server/node_modules/thrift/lib/thrift/transport.js:63:7)
> at TLSSocket.emit (events.js:107:17)
> at readableAddChunk (_stream_readable.js:163:16)
> at TLSSocket.Readable.push (_stream_readable.js:126:10)
> at TCP.onread (net.js:529:20)
> Reversing: Hello, World! call count 1
> Mapping to specific processor call
> Mapping to specific processor call
> Trace: Inside process_reverse
> at TermReverserProcessor.process_reverse 
> (/your/path/to/server/src/node/contracts/TermReverser.js:196:11)
> at TermReverserProcessor.process 
> (/your/path/to/server/src/node/contracts/TermReverser.js:183:39)
> at /your/path/to/server/node_modules/thrift/lib/thrift/server.js:55:21
> at TLSSocket. 
> (/your/path/to/server/node_modules/thrift/lib/thrift/transport.js:63:7)
> at TLSSocket.emit (events.js:107:17)
> at readableAddChunk (_stream_readable.js:163:16)
> at TLSSocket.Readable.push (_stream_readable.js:126:10)
> at TCP.onread (net.js:529:20)
> Reversing: Hello, World! call count 2
> Mapping to specific processor call
> {code}
> *Conclusion*: something is resetting the stream position to zero _after 
> server-side processing is complete_, causing a second complete execution to 
> occur, even though the client only receives one response. This issue does not 
> occur with the equivalent code when TLS has been "turned off". My colleagues 
> and I are having difficulty locating the errant code. Any help is appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3786) Node.js TLS emits 'connect' before connection is ready

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3786.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

great patch, thanks! committed with minor update to condition to support old 
nodes.

> Node.js TLS emits 'connect' before connection is ready
> --
>
> Key: THRIFT-3786
> URL: https://issues.apache.org/jira/browse/THRIFT-3786
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
> Fix For: 0.10.0
>
>
> When using a TLS connection, the Node.js Thrift connection instance will emit 
> a `connect` event early, making it possible to lose commands.
> `connect` is emitted by the Thrift connection instance when the underlying 
> socket is opened, instead of when the TLS handshake has completed. Making 
> matters worse, the offline queue is flushed during this premature `connect`, 
> which means that any commands issued prior to the TLS connection handshake 
> will be lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3786) Node.js TLS emits 'connect' before connection is ready

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-3786:
---

Assignee: Randy Abernethy

> Node.js TLS emits 'connect' before connection is ready
> --
>
> Key: THRIFT-3786
> URL: https://issues.apache.org/jira/browse/THRIFT-3786
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
>
> When using a TLS connection, the Node.js Thrift connection instance will emit 
> a `connect` event early, making it possible to lose commands.
> `connect` is emitted by the Thrift connection instance when the underlying 
> socket is opened, instead of when the TLS handshake has completed. Making 
> matters worse, the offline queue is flushed during this premature `connect`, 
> which means that any commands issued prior to the TLS connection handshake 
> will be lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (THRIFT-1385) make install doesn't install java library in the setted folder

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148777#comment-15148777
 ] 

Randy Abernethy edited comment on THRIFT-1385 at 2/16/16 4:40 PM:
--

While I agree that PREFIX should be respected, the patch applied breaks  normal 
"make install" (when prefix is not supplied). Anyone running a plain make 
install will now find thrift's java lib in: 
/thrift/lib/java/NONE/usr/local/lib/libthrift-1.0.0.jar (which causes build 
errors for everyone not using PREFIX).


was (Author: codesf):
While I agree that --prefix should be respected, the patch applied breaks  
normal "make install" (when prefix is not supplied). Anyone running a plain 
make install will now find thrift's java lib in: 
/thrift/lib/java/NONE/usr/local/lib/libthrift-1.0.0.jar (which causes build 
errors for everyone not using --prefix).

> make install doesn't install java library in the setted folder
> --
>
> Key: THRIFT-1385
> URL: https://issues.apache.org/jira/browse/THRIFT-1385
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
> Environment: -- Ant version
> $ ant -version
> Apache Ant(TM) version 1.8.2 compiled on December 20 2010
> -- Commands
> svn checkout http://svn.apache.org/repos/asf/thrift/trunk thrift
> cd thrift
> ./bootstrap.sh
> ./configure --prefix=${HOME}/fakeroot --without-cpp --without-boost 
> --without-libevent --without-zlib --without-c_glib --without-csharp 
> --without-erlang --without-python --without-perl --without-php 
> --without-php_extension --without-ruby --without-haskell --without-go
> make && make install
>Reporter: Verdoïa Laurent
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
> Attachments: 0001-java-config-prefix-fix.patch, install.patch
>
>
> make install failed on the java library with this error message:
> ./thrift/lib/java/build.xml:135: Failed to copy 
> ./thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar to 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar due to 
> java.io.FileNotFoundException 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar (Permission non accordée)
> For the safety I verified if the file 
> /thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar exists; and the 
> file exists.
> But the source file is not the problem here !
> Why the install basename is /usr/local/lib/ even with 
> --prefix=${HOME}/fakeroot
> The fakeroot folder exists too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-1385) make install doesn't install java library in the setted folder

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-1385.
-
Resolution: Fixed

Committed. 

N.B.: 
1. JAVA_PREFIX takes priority over PREFIX
2. This now makes Java the only language that respects PREFIX (all others use 
lang_PREFIX exclusively)

> make install doesn't install java library in the setted folder
> --
>
> Key: THRIFT-1385
> URL: https://issues.apache.org/jira/browse/THRIFT-1385
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
> Environment: -- Ant version
> $ ant -version
> Apache Ant(TM) version 1.8.2 compiled on December 20 2010
> -- Commands
> svn checkout http://svn.apache.org/repos/asf/thrift/trunk thrift
> cd thrift
> ./bootstrap.sh
> ./configure --prefix=${HOME}/fakeroot --without-cpp --without-boost 
> --without-libevent --without-zlib --without-c_glib --without-csharp 
> --without-erlang --without-python --without-perl --without-php 
> --without-php_extension --without-ruby --without-haskell --without-go
> make && make install
>Reporter: Verdoïa Laurent
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
> Attachments: 0001-java-config-prefix-fix.patch, install.patch
>
>
> make install failed on the java library with this error message:
> ./thrift/lib/java/build.xml:135: Failed to copy 
> ./thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar to 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar due to 
> java.io.FileNotFoundException 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar (Permission non accordée)
> For the safety I verified if the file 
> /thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar exists; and the 
> file exists.
> But the source file is not the problem here !
> Why the install basename is /usr/local/lib/ even with 
> --prefix=${HOME}/fakeroot
> The fakeroot folder exists too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (THRIFT-1385) make install doesn't install java library in the setted folder

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148824#comment-15148824
 ] 

Randy Abernethy edited comment on THRIFT-1385 at 2/16/16 3:53 PM:
--

This patch allows 3 prefix options with JAVA:

No Prefix

root@310dce6012b6:/thrift# ./configure --without-python --without-cpp
...
root@310dce6012b6:/thrift# make install
...
root@310dce6012b6:/thrift# find / -name libthrift-1.0.0.jar
/thrift/lib/java/build/libthrift-1.0.0.jar
/usr/local/lib/libthrift-1.0.0.jar

root@310dce6012b6:/thrift# rm /usr/local/lib/libthrift-1.0.0.jar

JAVA_PREFIX

root@310dce6012b6:/thrift# ./configure --without-python --without-cpp 
JAVA_PREFIX=$HOME
...
root@310dce6012b6:/thrift# make install
...
root@310dce6012b6:/thrift# find / -name libthrift-1.0.0.jar
/thrift/lib/java/build/libthrift-1.0.0.jar
/root/usr/local/lib/libthrift-1.0.0.jar

root@310dce6012b6:/thrift# rm /root/usr/local/lib/libthrift-1.0.0.jar

PREFIX

root@310dce6012b6:/thrift# ./configure --without-python --without-cpp 
PREFIX=/tmp
...
root@310dce6012b6:/thrift# make install
...
root@310dce6012b6:/thrift# find / -name libthrift-1.0.0.jar
/thrift/lib/java/build/libthrift-1.0.0.jar
/tmp/usr/local/lib/libthrift-1.0.0.jar



was (Author: codesf):
This patch allows 3 prefix options with JAVA:

### No Prefix
root@310dce6012b6:/thrift# ./configure --without-python --without-cpp
...
root@310dce6012b6:/thrift# make install
...
root@310dce6012b6:/thrift# find / -name libthrift-1.0.0.jar
/thrift/lib/java/build/libthrift-1.0.0.jar
/usr/local/lib/libthrift-1.0.0.jar

root@310dce6012b6:/thrift# rm /usr/local/lib/libthrift-1.0.0.jar

### JAVA_PREFIX
root@310dce6012b6:/thrift# ./configure --without-python --without-cpp 
JAVA_PREFIX=$HOME
...
root@310dce6012b6:/thrift# make install
...
root@310dce6012b6:/thrift# find / -name libthrift-1.0.0.jar
/thrift/lib/java/build/libthrift-1.0.0.jar
/root/usr/local/lib/libthrift-1.0.0.jar

root@310dce6012b6:/thrift# rm /root/usr/local/lib/libthrift-1.0.0.jar

### PREFIX
root@310dce6012b6:/thrift# ./configure --without-python --without-cpp 
PREFIX=/tmp
...
root@310dce6012b6:/thrift# make install
...
root@310dce6012b6:/thrift# find / -name libthrift-1.0.0.jar
/thrift/lib/java/build/libthrift-1.0.0.jar
/tmp/usr/local/lib/libthrift-1.0.0.jar


> make install doesn't install java library in the setted folder
> --
>
> Key: THRIFT-1385
> URL: https://issues.apache.org/jira/browse/THRIFT-1385
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
> Environment: -- Ant version
> $ ant -version
> Apache Ant(TM) version 1.8.2 compiled on December 20 2010
> -- Commands
> svn checkout http://svn.apache.org/repos/asf/thrift/trunk thrift
> cd thrift
> ./bootstrap.sh
> ./configure --prefix=${HOME}/fakeroot --without-cpp --without-boost 
> --without-libevent --without-zlib --without-c_glib --without-csharp 
> --without-erlang --without-python --without-perl --without-php 
> --without-php_extension --without-ruby --without-haskell --without-go
> make && make install
>Reporter: Verdoïa Laurent
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
> Attachments: 0001-java-config-prefix-fix.patch, install.patch
>
>
> make install failed on the java library with this error message:
> ./thrift/lib/java/build.xml:135: Failed to copy 
> ./thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar to 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar due to 
> java.io.FileNotFoundException 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar (Permission non accordée)
> For the safety I verified if the file 
> /thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar exists; and the 
> file exists.
> But the source file is not the problem here !
> Why the install basename is /usr/local/lib/ even with 
> --prefix=${HOME}/fakeroot
> The fakeroot folder exists too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (THRIFT-1385) make install doesn't install java library in the setted folder

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reopened THRIFT-1385:
-
  Assignee: Randy Abernethy  (was: Roger Meier)

While I agree that --prefix should be respected, the patch applied breaks  
normal "make install" (when prefix is not supplied). Anyone running a plain 
make install will now find thrift's java lib in: 
/thrift/lib/java/NONE/usr/local/lib/libthrift-1.0.0.jar (which causes build 
errors for everyone not using --prefix).

> make install doesn't install java library in the setted folder
> --
>
> Key: THRIFT-1385
> URL: https://issues.apache.org/jira/browse/THRIFT-1385
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
> Environment: -- Ant version
> $ ant -version
> Apache Ant(TM) version 1.8.2 compiled on December 20 2010
> -- Commands
> svn checkout http://svn.apache.org/repos/asf/thrift/trunk thrift
> cd thrift
> ./bootstrap.sh
> ./configure --prefix=${HOME}/fakeroot --without-cpp --without-boost 
> --without-libevent --without-zlib --without-c_glib --without-csharp 
> --without-erlang --without-python --without-perl --without-php 
> --without-php_extension --without-ruby --without-haskell --without-go
> make && make install
>Reporter: Verdoïa Laurent
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
> Attachments: install.patch
>
>
> make install failed on the java library with this error message:
> ./thrift/lib/java/build.xml:135: Failed to copy 
> ./thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar to 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar due to 
> java.io.FileNotFoundException 
> /usr/local/lib/libthrift-0.8.0-snapshot-javadoc.jar (Permission non accordée)
> For the safety I verified if the file 
> /thrift/lib/java/build/libthrift-0.8.0-snapshot-javadoc.jar exists; and the 
> file exists.
> But the source file is not the problem here !
> Why the install basename is /usr/local/lib/ even with 
> --prefix=${HOME}/fakeroot
> The fakeroot folder exists too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3630) Debian/Ubuntu install docs need an update

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3630.
-
Resolution: Fixed

committed

> Debian/Ubuntu install docs need an update
> -
>
> Key: THRIFT-3630
> URL: https://issues.apache.org/jira/browse/THRIFT-3630
> Project: Thrift
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.9.3
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
> Fix For: 0.9.4
>
> Attachments: 
> 0001-THRIFT-3630-Debian-and-Ubuntu-install-docs-update.patch, 
> 0001-THRIFT-3630-Debian-and-Ubuntu-install-docs-update.patch
>
>
> Need to add some missing packages to the list (make/boost thread dev), also 
> need to add boost version update for Ubuntu12/Debian7. 
> Should move Java instructions into the language list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3630) Debian/Ubuntu install docs need an update

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-3630:

Attachment: 0001-THRIFT-3630-Debian-and-Ubuntu-install-docs-update.patch

patch

> Debian/Ubuntu install docs need an update
> -
>
> Key: THRIFT-3630
> URL: https://issues.apache.org/jira/browse/THRIFT-3630
> Project: Thrift
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.9.3
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
> Fix For: 0.9.4
>
> Attachments: 
> 0001-THRIFT-3630-Debian-and-Ubuntu-install-docs-update.patch
>
>
> Need to add some missing packages to the list (make/boost thread dev), also 
> need to add boost version update for Ubuntu12/Debian7. 
> Should move Java instructions into the language list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3630) Debian/Ubuntu install docs need an update

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3630.
-
Resolution: Fixed

committed

> Debian/Ubuntu install docs need an update
> -
>
> Key: THRIFT-3630
> URL: https://issues.apache.org/jira/browse/THRIFT-3630
> Project: Thrift
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.9.3
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
> Fix For: 0.9.4
>
> Attachments: 
> 0001-THRIFT-3630-Debian-and-Ubuntu-install-docs-update.patch
>
>
> Need to add some missing packages to the list (make/boost thread dev), also 
> need to add boost version update for Ubuntu12/Debian7. 
> Should move Java instructions into the language list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3630) Debian/Ubuntu install docs need an update

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-3630:
---

 Summary: Debian/Ubuntu install docs need an update
 Key: THRIFT-3630
 URL: https://issues.apache.org/jira/browse/THRIFT-3630
 Project: Thrift
  Issue Type: Bug
  Components: Documentation
Affects Versions: 0.9.3
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.4


Need to add some missing packages to the list (make/boost thread dev), also 
need to add boost version update for Ubuntu12/Debian7. 

Should move Java instructions into the language list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3392.
-
   Resolution: Fixed
Fix Version/s: 0.9.4

committed, thanks for the issue, patch and especially the test!

I modified the patch to super.close() on close() to preserve the close of the 
underlying transport (which could be a file, socket, named pipe, etc.).

> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> {code:java}
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> {code}
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
> {code:java}
> public TZlibTransport(TTransport transport, int compressionLevel) {
>   transport_ = transport;
>   inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
>   outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
> true);
> }
> {code}
> However, on its close method it only closes the transport and not the 
> underlying streams, forcing users to flush the transport before closing if 
> they really want to write everything:
> {code:java}
> public void close() {
>   if (transport_.isOpen()) {
>   transport_.close();
> }
> {code}
> I think it would be better if we simply relied on the close() method of the 
> TIOStreamTransport, which closes the input and output streams if they have 
> been created. Additionally, it would be better to create the input stream on 
> the first read and the output stream on the first write: otherwise, we will 
> get an error during closing if we're only reading (as TIOStreamTransport will 
> still try to close the output side, resulting in writes from the deflater).
> I have a first version of a fix for these issues: I'll turn it into a pull 
> request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-3392:
---

Assignee: Randy Abernethy

> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>Assignee: Randy Abernethy
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> {code:java}
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> {code}
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
> {code:java}
> public TZlibTransport(TTransport transport, int compressionLevel) {
>   transport_ = transport;
>   inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
>   outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
> true);
> }
> {code}
> However, on its close method it only closes the transport and not the 
> underlying streams, forcing users to flush the transport before closing if 
> they really want to write everything:
> {code:java}
> public void close() {
>   if (transport_.isOpen()) {
>   transport_.close();
> }
> {code}
> I think it would be better if we simply relied on the close() method of the 
> TIOStreamTransport, which closes the input and output streams if they have 
> been created. Additionally, it would be better to create the input stream on 
> the first read and the output stream on the first write: otherwise, we will 
> get an error during closing if we're only reading (as TIOStreamTransport will 
> still try to close the output side, resulting in writes from the deflater).
> I have a first version of a fix for these issues: I'll turn it into a pull 
> request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3380) nodejs: 0.9.2 -> 0.9.3 upgrade breaks Protocol and Transport requires

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14953681#comment-14953681
 ] 

Randy Abernethy commented on THRIFT-3380:
-

I agree that we should not break the world here. The challenge is changing the 
released bits.

[~jfarrell] any thoughts on this?

> nodejs: 0.9.2 -> 0.9.3 upgrade breaks Protocol and Transport requires
> -
>
> Key: THRIFT-3380
> URL: https://issues.apache.org/jira/browse/THRIFT-3380
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
>Reporter: Matt Willer
>Priority: Critical
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Node.js projects that depend on Thrift and need to use a specific transport 
> or protocol must require them in separately, like this:
> {code}
> var thrift = require('thrift'),
> ThriftTransports = require('thrift/lib/thrift/transport');
> {code}
> The new version (0.9.3) changed that directory structure of the thrift module 
> so that the transport file is now located at 
> thrift/lib/nodejs/lib/thrift/transport.js, which breaks any application that 
> was requiring it at the old path.  This type of breaking change is 
> inappropriate for a patch version, and should be fixed immediately.
> The directory structure change also has the undesirable side effect of 
> including every single language implementation of thrift in the Node.js 
> module, bloating the size of the module with unnecessary files.
> Long-term, the right fix for this is to export useful parts of the library 
> (e.g. transport and protocol constructors) from the main file, but since this 
> is a patch version the immediate fix should be to maintain existing behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3373) Various fixes for cross test servers and clients

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-3373:
---

Assignee: Randy Abernethy

> Various fixes for cross test servers and clients
> 
>
> Key: THRIFT-3373
> URL: https://issues.apache.org/jira/browse/THRIFT-3373
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Randy Abernethy
>
> I hope it's the last time such a broad fix is needed on this. 
> * fix testBinary and testMultiException handler of c_glib server
> * nodejs server testBinary handler was missing
> * python and haskell lib names were incorrect in configure.ac (sorry about 
> that)
> * Enable dart in make cross
> * ruby clients did not disconnect from the server
>   Since many test servers use rudimentary TSimpleServer, it resulted in dead 
> locks
> * nodejs clients only half-closed (no more send) the connection.
>the same reason as the above, it resulted in hang.
>   (The patch simply makes it exit with 0 in the end.)
> * python server did not log anything to files
> * nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3373) Various fixes for cross test servers and clients

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3373.
-
   Resolution: Fixed
Fix Version/s: 0.9.4

committed, thanks for the patch!

> Various fixes for cross test servers and clients
> 
>
> Key: THRIFT-3373
> URL: https://issues.apache.org/jira/browse/THRIFT-3373
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
>
> I hope it's the last time such a broad fix is needed on this. 
> * fix testBinary and testMultiException handler of c_glib server
> * nodejs server testBinary handler was missing
> * python and haskell lib names were incorrect in configure.ac (sorry about 
> that)
> * Enable dart in make cross
> * ruby clients did not disconnect from the server
>   Since many test servers use rudimentary TSimpleServer, it resulted in dead 
> locks
> * nodejs clients only half-closed (no more send) the connection.
>the same reason as the above, it resulted in hang.
>   (The patch simply makes it exit with 0 in the end.)
> * python server did not log anything to files
> * nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-2994) Node.js TJSONProtocol cannot be used for object serialization.

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945059#comment-14945059
 ] 

Randy Abernethy commented on THRIFT-2994:
-

Regarding the tests, it would be great to have all tests pass after every patch 
but as long as no additional tests fail after the patch we can commit it on the 
merits of the patch. There are failing node tests in the current master that 
are not associated with your patch.

I'm reviewing 379 
(https://patch-diff.githubusercontent.com/raw/apache/thrift/pull/379.patch). 
The first hunk of the patch I see:{code}
@@ -40,6 +40,8 @@ module.exports = TJSONProtocol;
  */
 function TJSONProtocol(trans) {
   this.trans = trans;
+  this.tstack = [];
+  this.tpos = [];
 };{code}

Conflicts with the master which contains: {code}
function TJSONProtocol(trans) {
  this.tstack = [];
  this.tpos = [];
  this.trans = trans;
}; {code}

Am I not grabbing the right patch?

> Node.js TJSONProtocol cannot be used for object serialization.
> --
>
> Key: THRIFT-2994
> URL: https://issues.apache.org/jira/browse/THRIFT-2994
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: Jan Brauer
>Assignee: Randy Abernethy
>
> Consider the following code using the Thrift example types.
> {code:title=serialize.js|borderStyle=solid}
> var thrift = require('thrift');
> var test_types = require('gen-nodejs/ThriftTest_types.js');
> var bonk = new test_types.Bonk({message: "message", type: 6})
> var t_out = new thrift.TBufferedTransport();
> var p_out = new thrift.TJSONProtocol(t_out);
> bonk.write(p_out);
> var out
> t_out.flush(function (b) { out = b;});
> console.log(out)
> {code}
> My expectation would be for {{out}} to contain the serialized {{Bonk}} struct.
> But due to 
> [TJSONProtocol|https://github.com/apache/thrift/blob/master/lib/nodejs/lib/thrift/protocol.js#L1287]
>  only writing to the underlying transport in {{writeMessageEnd}} the above 
> code does not work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-2994) Node.js TJSONProtocol cannot be used for object serialization.

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-2994:
---

Assignee: Randy Abernethy

> Node.js TJSONProtocol cannot be used for object serialization.
> --
>
> Key: THRIFT-2994
> URL: https://issues.apache.org/jira/browse/THRIFT-2994
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: Jan Brauer
>Assignee: Randy Abernethy
>
> Consider the following code using the Thrift example types.
> {code:title=serialize.js|borderStyle=solid}
> var thrift = require('thrift');
> var test_types = require('gen-nodejs/ThriftTest_types.js');
> var bonk = new test_types.Bonk({message: "message", type: 6})
> var t_out = new thrift.TBufferedTransport();
> var p_out = new thrift.TJSONProtocol(t_out);
> bonk.write(p_out);
> var out
> t_out.flush(function (b) { out = b;});
> console.log(out)
> {code}
> My expectation would be for {{out}} to contain the serialized {{Bonk}} struct.
> But due to 
> [TJSONProtocol|https://github.com/apache/thrift/blob/master/lib/nodejs/lib/thrift/protocol.js#L1287]
>  only writing to the underlying transport in {{writeMessageEnd}} the above 
> code does not work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-1712) Add TBase class for c++

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14723362#comment-14723362
 ] 

Randy Abernethy commented on THRIFT-1712:
-

Hey Martin,

One thing I think might work well with this idea, in your next approach, is IDL 
annotations. For example Apache Thrift IDL allows for annotations like:

{code:title=anno.thrift|borderStyle=solid}
struct  anno  {
  1: i32 (cpp.type = "long") counter
} (final="true")
{code}

The first is C++ specific (cpp.*) the second applies to all languages which can 
make sense of it (final).

The Thrift compiler acquired annotation support for several reasons but some 
that are important as I see it are:

 - Command line switches apply to the entire IDL indiscriminately
 - Command line switches are not a documented part of the specification one 
gets for free with IDL
 - Command line switches are easy to forget

Annotations avoid all three of these issues. With IDL annotations, I can commit 
the above IDL to version control and track the change (and bugs it generates), 
I no longer need a command line switch to make counter a long (you can't forget 
it and it is documented) and you have the ability to treat an i32 in another 
struct differently if that makes sense. Annotations can be used at file scope 
as well. If you are familiar with the IDL instructions: 

 - cpp_include  Adds a #include line for the given literal in C++ output
 - cpp_type Allows the container implementation type to be selected in C++

Both predate annotation support and should be converted to annotations in the 
future (pre v1.0 I would hope). Thus the new annotation style (cpp.include = 
"myheader.h") could handle your header hint and something like this could allow 
base class specification:

struct example {
} (cpp.base = "mybase")

Annotations separate abstract IDL (non annotation IDL) from implementation 
details but still allow high level implementation details to be a documented 
part of the interface specification. They are also controllable service by 
service and  type by type.

I don't personally like a lot of implementation noise in my IDL but I think it 
is an improvement over IDL compiler command line switches which do the same 
thing.

My 2 cents.

Best,
Randy

> Add TBase class for c++
> ---
>
> Key: THRIFT-1712
> URL: https://issues.apache.org/jira/browse/THRIFT-1712
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler
>Affects Versions: 0.8
>Reporter: Martin Vogt
>Assignee: Ben Craig
>Priority: Minor
>  Labels: base, c++, class
> Attachments: 000_line_first_140628v1.patch, 
> 010_base_struct_gen_140629v1.patch, 011_base_struct_rest_140619v2.patch
>
>
> The generated c++ classes for struct's do not have a common base class.
> The patch adds two options to the compiler:
> - line_first : first line before all includes
> - base_struct : custom base class for structs
> For example:
> {code:title=MyService.thrift}
> struct MyStruct {
>1:i32 val;
> }
> service MyService {
>void doSomething();
> }
> {code}
> thrift --gen cpp:line_first='#include ',base_struct=':public 
> TBase' ./MyService.thrift
> {code:title=MyService_types.h}
> #ifndef MyService_TYPES_H
> #define MyService_TYPES_H
> #include 
> #include 
> []
> class MyStruct:public TBase {
> [...]
> {code}
> The default, without any option:
> thrift --gen cpp ./MyService.thrift
> {code:title=MyService_types.h}
> #ifndef MyService_TYPES_H
> #define MyService_TYPES_H
> /* first line (modifier:off) */
> #include 
> []
> class MyStruct /* base_struct (modifier:off) */ {
> [...
> {code}
> The idea is to have a base class for typecasting, which can be done with:
> {code}
> void processSignal(const TBase& tBase) {
>   if (typeid(tBase).name() == typeid(MyStruct).name()) 
> printf("MyStruct found!\n")
>  
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3311) Top level README.md has incorrect formmating

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3311.
-
   Resolution: Fixed
 Assignee: Randy Abernethy
Fix Version/s: 0.9.3

thanks for the patch!

 Top level README.md has incorrect formmating
 

 Key: THRIFT-3311
 URL: https://issues.apache.org/jira/browse/THRIFT-3311
 Project: Thrift
  Issue Type: Bug
Reporter: chris snow
Assignee: Randy Abernethy
Priority: Trivial
 Fix For: 0.9.3

 Attachments: screenshot-1.png


 The readme formatting is incorrect - see the attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3300) Reimplement TZlibTransport in Java using streams

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3300.
-
   Resolution: Fixed
Fix Version/s: 0.9.3

committed, always like to see patches with a net reduction in LOC! thanks for 
the great patch.

 Reimplement TZlibTransport in Java using streams
 

 Key: THRIFT-3300
 URL: https://issues.apache.org/jira/browse/THRIFT-3300
 Project: Thrift
  Issue Type: Improvement
Reporter: Paul Magrath
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3


 The implementation of TZlibTransport in Java could be simplified by making 
 use of the InflaterInputStream, DeflaterOutputStream and TIOStreamTransport 
 classes. This also has the benefit of eliminating the need to allocate byte 
 arrays for buffers. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3300) Reimplement TZlibTransport in Java using streams

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-3300:
---

Assignee: Randy Abernethy

 Reimplement TZlibTransport in Java using streams
 

 Key: THRIFT-3300
 URL: https://issues.apache.org/jira/browse/THRIFT-3300
 Project: Thrift
  Issue Type: Improvement
Reporter: Paul Magrath
Assignee: Randy Abernethy
Priority: Minor

 The implementation of TZlibTransport in Java could be simplified by making 
 use of the InflaterInputStream, DeflaterOutputStream and TIOStreamTransport 
 classes. This also has the benefit of eliminating the need to allocate byte 
 arrays for buffers. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3294) TZlibTransport for Java does not write data correctly

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-3294:
---

Assignee: Randy Abernethy

 TZlibTransport for Java does not write data correctly
 -

 Key: THRIFT-3294
 URL: https://issues.apache.org/jira/browse/THRIFT-3294
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.9.3
Reporter: Paul Magrath
Assignee: Randy Abernethy

 An error similar to the following exception is encountered in the client 
 after anything more than the most trivial usage of the TZlibTransport in Java.
 org.apache.thrift.TApplicationException: out of sequence response
   at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:84)
 Investigation has found that the problem seems to be that the implementation 
 of the flush method is ignoring the write buffer length.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3294) TZlibTransport for Java does not write data correctly

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3294.
-
   Resolution: Fixed
Fix Version/s: 0.9.3

committed, thanks for the patch!

 TZlibTransport for Java does not write data correctly
 -

 Key: THRIFT-3294
 URL: https://issues.apache.org/jira/browse/THRIFT-3294
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.9.3
Reporter: Paul Magrath
Assignee: Randy Abernethy
 Fix For: 0.9.3


 An error similar to the following exception is encountered in the client 
 after anything more than the most trivial usage of the TZlibTransport in Java.
 org.apache.thrift.TApplicationException: out of sequence response
   at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:84)
 Investigation has found that the problem seems to be that the implementation 
 of the flush method is ignoring the write buffer length.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-2199) Remove Dense protocol (was: move to Contrib)

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659674#comment-14659674
 ] 

Randy Abernethy commented on THRIFT-2199:
-

thanks Jens.

 Remove Dense protocol (was: move to Contrib)
 

 Key: THRIFT-2199
 URL: https://issues.apache.org/jira/browse/THRIFT-2199
 Project: Thrift
  Issue Type: Improvement
  Components: Compiler (General)
Affects Versions: 1.0
 Environment: All
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3

 Attachments: 0001-dense-removal.patch


 In response to recent emails I suggest we move the Dense protocol to contrib. 
 It is in an experimental state (per comments) and has not been enhanced for 
 over three years. It impacts complexity of Thrift in a fairly broad fashion, 
 having bearing on compilation and compiler output even when not used. If no 
 one disagrees with this action I would be happy to put a patch together to 
 relocate dense to contrib.
 Would fix THRIFT-2200



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-2199) Remove Dense protocol (was: move to Contrib)

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-2199.
-
Resolution: Fixed

committed

 Remove Dense protocol (was: move to Contrib)
 

 Key: THRIFT-2199
 URL: https://issues.apache.org/jira/browse/THRIFT-2199
 Project: Thrift
  Issue Type: Improvement
  Components: Compiler (General)
Affects Versions: 1.0
 Environment: All
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3

 Attachments: 0001-dense-removal.patch


 In response to recent emails I suggest we move the Dense protocol to contrib. 
 It is in an experimental state (per comments) and has not been enhanced for 
 over three years. It impacts complexity of Thrift in a fairly broad fashion, 
 having bearing on compilation and compiler output even when not used. If no 
 one disagrees with this action I would be happy to put a patch together to 
 relocate dense to contrib.
 Would fix THRIFT-2200



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-2199) Move Dense protocol to Contrib

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-2199:

Attachment: 0001-dense-removal.patch

patch

 Move Dense protocol to Contrib
 --

 Key: THRIFT-2199
 URL: https://issues.apache.org/jira/browse/THRIFT-2199
 Project: Thrift
  Issue Type: Improvement
  Components: Compiler (General)
Affects Versions: 1.0
 Environment: All
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3

 Attachments: 0001-dense-removal.patch


 In response to recent emails I suggest we move the Dense protocol to contrib. 
 It is in an experimental state (per comments) and has not been enhanced for 
 over three years. It impacts complexity of Thrift in a fairly broad fashion, 
 having bearing on compilation and compiler output even when not used. If no 
 one disagrees with this action I would be happy to put a patch together to 
 relocate dense to contrib.
 Would fix THRIFT-2200



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (THRIFT-2199) Move Dense protocol to Contrib

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651970#comment-14651970
 ] 

Randy Abernethy edited comment on THRIFT-2199 at 8/3/15 5:28 PM:
-

This patch removes the experimental dense protocol implementation including 
four files and over 2,000 lines of code. This should not impact any Apache 
Thrift implementation unless said implementation is using the dense protocol. 
Email was sent to user and dev thrift mailing lists on 8/3/2015 to alert any 
possible users of the imminent removal.

The experimental dense code was removed because it increased complexity and 
represented a significant maintenance burden in the compiler and C++ library 
without providing utility to the general community.

Dense was only implemented in C++ and therefore was not workable in cross 
language settings. The TCompactProtocol is a production ready broadly supported 
alternative and the TZLib transport layer (present in Java, Python, C++ and 
other languages) is a possible alternative for cross platform/language high 
compression applications.

The dense code created fingerprints in all generated C++ code files for all 
types whether dense was enabled or not. Users hijacking Dense fingerprints for 
their own uses will need to implement an equivalent custom feature. 

The --gen cpp:dense IDL compiler qualifier and four files have been removed:
- lib/cpp/src/thrift/TReflectionLocal.h
- lib/cpp/src/thrift/protocol/TDenseProtocol.cpp
- lib/cpp/src/thrift/protocol/TDenseProtocol.h
- lib/cpp/test/DenseProtoTest.cpp

along with their associated build/test drivers.


was (Author: codesf):
This patch removes the experimental dense protocol implementation including 
four files and over 2,000 lines of code. This should not impact any Apache 
Thrift implementation unless said implementation is using the dense protocol. 
Email was sent to user and dev thrift mailing lists on 8/3/2015 to alert any 
possible users of the imminent removal.

The experimental dense code was removed because it increased complexity and 
represented a significant maintenance burden in the compiler and C++ library 
without providing utility to the general community.

Dense was only implemented in C++ and therefore was not workable in cross 
language settings. The TZLib transport layer (present in Java, Python, C++ and 
other languages) is a possible alternative for cross platform/language high 
compression applications.

The dense code created fingerprints in all generated C++ code files for all 
types whether dense was enabled or not. Users hijacking Dense fingerprints for 
their own uses will need to implement an equivalent custom feature. 

The --gen cpp:dense IDL compiler qualifier and four files have been removed:
- lib/cpp/src/thrift/TReflectionLocal.h
- lib/cpp/src/thrift/protocol/TDenseProtocol.cpp
- lib/cpp/src/thrift/protocol/TDenseProtocol.h
- lib/cpp/test/DenseProtoTest.cpp

along with their associated build/test drivers.

 Move Dense protocol to Contrib
 --

 Key: THRIFT-2199
 URL: https://issues.apache.org/jira/browse/THRIFT-2199
 Project: Thrift
  Issue Type: Improvement
  Components: Compiler (General)
Affects Versions: 1.0
 Environment: All
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3

 Attachments: 0001-dense-removal.patch


 In response to recent emails I suggest we move the Dense protocol to contrib. 
 It is in an experimental state (per comments) and has not been enhanced for 
 over three years. It impacts complexity of Thrift in a fairly broad fashion, 
 having bearing on compilation and compiler output even when not used. If no 
 one disagrees with this action I would be happy to put a patch together to 
 relocate dense to contrib.
 Would fix THRIFT-2200



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (THRIFT-2199) Move Dense protocol to Contrib

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651970#comment-14651970
 ] 

Randy Abernethy edited comment on THRIFT-2199 at 8/3/15 5:16 PM:
-

This patch removes the experimental dense protocol implementation including 
four files and over 2,000 lines of code. This should not impact any Apache 
Thrift implementation unless said implementation is using the dense protocol. 
Email was sent to user and dev thrift mailing lists on 8/3/2015 to alert any 
possible users of the imminent removal.

The experimental dense code was removed because it increased complexity and 
represented a significant maintenance burden in the compiler and C++ library 
without providing utility to the general community.

Dense was only implemented in C++ and therefore was not workable in cross 
language settings. The TZLib transport layer (present in Java, Python, C++ and 
other languages) is a possible alternative for cross platform/language high 
compression applications.

The dense code created fingerprints in all generated C++ code files for all 
types whether dense was enabled or not. Users hijacking Dense fingerprints for 
their own uses will need to implement an equivalent custom feature. 

The --gen cpp:dense IDL compiler qualifier and four files have been removed:
- lib/cpp/src/thrift/TReflectionLocal.h
- lib/cpp/src/thrift/protocol/TDenseProtocol.cpp
- lib/cpp/src/thrift/protocol/TDenseProtocol.h
- lib/cpp/test/DenseProtoTest.cpp

along with their associated build/test drivers.


was (Author: codesf):
patch

 Move Dense protocol to Contrib
 --

 Key: THRIFT-2199
 URL: https://issues.apache.org/jira/browse/THRIFT-2199
 Project: Thrift
  Issue Type: Improvement
  Components: Compiler (General)
Affects Versions: 1.0
 Environment: All
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3

 Attachments: 0001-dense-removal.patch


 In response to recent emails I suggest we move the Dense protocol to contrib. 
 It is in an experimental state (per comments) and has not been enhanced for 
 over three years. It impacts complexity of Thrift in a fairly broad fashion, 
 having bearing on compilation and compiler output even when not used. If no 
 one disagrees with this action I would be happy to put a patch together to 
 relocate dense to contrib.
 Would fix THRIFT-2200



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-2199) Move Dense protocol to Contrib

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644193#comment-14644193
 ] 

Randy Abernethy commented on THRIFT-2199:
-

+1 for deleting.

 Move Dense protocol to Contrib
 --

 Key: THRIFT-2199
 URL: https://issues.apache.org/jira/browse/THRIFT-2199
 Project: Thrift
  Issue Type: Improvement
  Components: Compiler (General)
Affects Versions: 1.0
 Environment: All
Reporter: Randy Abernethy
Priority: Minor

 In response to recent emails I suggest we move the Dense protocol to contrib. 
 It is in an experimental state (per comments) and has not been enhanced for 
 over three years. It impacts complexity of Thrift in a fairly broad fashion, 
 having bearing on compilation and compiler output even when not used. If no 
 one disagrees with this action I would be happy to put a patch together to 
 relocate dense to contrib.
 Would fix THRIFT-2200



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3042) Dockerfiles fail to build

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14645184#comment-14645184
 ] 

Randy Abernethy commented on THRIFT-3042:
-

+1 for apt-get update -y  ... on all apt-get install lines

 Dockerfiles fail to build
 -

 Key: THRIFT-3042
 URL: https://issues.apache.org/jira/browse/THRIFT-3042
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Affects Versions: 0.9.3
 Environment: ubuntu 14.04 docker host
Reporter: Randy Abernethy
Assignee: Jake Farrell
Priority: Minor
 Fix For: 0.9.3

 Attachments: thrift-3042-ubuntu.patch


 h3.  Docker build on build/docker/ubuntu/Dockerfile fails on Haxe setup. e.g.
 docker@ubuntu:~$ docker build -t thrift thrift/build/docker/ubuntu
 ...
 haxe-3.1.3/std/Xml.hx
 Uncaught exception - load.c(237) : Failed to load library : std.ndll 
 (std.ndll: cannot open shared object file: No such file or directory)
 INFO[0011] The command [/bin/sh -c apt-get install -y libneko0  mkdir 
 -p /tmp/haxe /usr/lib/haxe  curl 
 http://haxe.org/website-content/downloads/3,1,3/downloads/haxe-3.1.3-linux64.tar.gz
  -o /tmp/haxe/haxe-3.1.3-linux64.tar.gz  tar -xvzf 
 /tmp/haxe/haxe-3.1.3-linux64.tar.gz -C /usr/lib/haxe --strip-components=1   
ln -s /usr/lib/haxe/haxe /usr/bin/haxe  ln -s /usr/lib/haxe/haxelib 
 /usr/bin/haxelib  ln -s /usr/lib/libneko.so.0 /usr/lib/libneko.so 
  mkdir -p /usr/lib/haxe/lib   chmod -R 777 /usr/lib/haxe/lib  
 haxelib setup /usr/lib/haxe/lib  haxelib install hxcpp] returned a 
 non-zero code: 1 
 h3. Docker build on build/docker/centosDockerfile fails on Boost build. e.g.
 docker@ubuntu:~$ docker build -t thrift thrift/build/docker/centos
 ...
 /tmp/boost/boost_1_55_0/tools/build/v2/tools/gcc.jam:148: in gcc.init from 
 module gcc
 error: toolset gcc initialization:
 error: no command provided, default command 'g++' not found
 error: initialized from project-config.jam:12
 /tmp/boost/boost_1_55_0/tools/build/v2/build/toolset.jam:41: in toolset.using 
 from module toolset
 /tmp/boost/boost_1_55_0/tools/build/v2/build/project.jam:1007: in using from 
 module project-rules
 project-config.jam:12: in modules.load from module project-config
 /tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:249: in load-config 
 from module build-system
 /tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:412: in 
 load-configuration-files from module build-system
 /tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:524: in load from 
 module build-system
 /tmp/boost/boost_1_55_0/tools/build/v2/kernel/modules.jam:289: in import from 
 module modules
 /tmp/boost/boost_1_55_0/tools/build/v2/kernel/bootstrap.jam:139: in 
 boost-build from module
 /tmp/boost/boost_1_55_0/boost-build.jam:17: in module scope from module
 INFO[0264] The command [/bin/sh -c mkdir -p /tmp/boost  curl -SL 
 http://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.gz;
  | tar -xzC /tmp/boost  cd /tmp/boost/boost_1_55_0  
 ./bootstrap.sh   ./b2 install  cd $HOME] returned a non-zero 
 code: 1 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3262) warning: overflow in implicit constant conversion in DenseProtoTest.cpp

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14639696#comment-14639696
 ] 

Randy Abernethy commented on THRIFT-3262:
-

The entire dense protocol and all support for it in the compiler should be 
removed. It is an old incomplete experiment that has not been worked on for 
years. Have pinged the original author on #thrift to inquire about intentions 
but no response.

 warning: overflow in implicit constant conversion in DenseProtoTest.cpp
 ---

 Key: THRIFT-3262
 URL: https://issues.apache.org/jira/browse/THRIFT-3262
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
Reporter: Jens Geyer

 {code}
 DenseProtoTest.cpp: In member function 'void 
 test_dense_proto_1::test_method()':
 DenseProtoTest.cpp:68:14: warning: overflow in implicit constant conversion 
 [-Woverflow]
ooe.a_bite = 0xd6;
   ^
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3250) Apache Thrift should use registered media types with HTTP

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-3250:

Component/s: Ruby - Library
 Python - Library
 PHP - Library
 Perl - Library
 JavaME - Library
 Haxe - Library
 Haskell - Library
 Go - Library
 Erlang - Library
 Delphi - Library
 D - Library
 Cocoa - Library
 AS3 - Library

 Apache Thrift should use registered media types with HTTP
 -

 Key: THRIFT-3250
 URL: https://issues.apache.org/jira/browse/THRIFT-3250
 Project: Thrift
  Issue Type: Improvement
  Components: AS3 - Library, C# - Library, C++ - Library, Cocoa - 
 Library, D - Library, Delphi - Library, Erlang - Library, Go - Library, 
 Haskell - Library, Haxe - Library, Java - Library, JavaME - Library, 
 JavaScript - Library, Node.js - Library, Perl - Library, PHP - Library, 
 Python - Library, Ruby - Library
Affects Versions: 0.9.3
 Environment: all
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor

 Now that we have registered media types:
 - application/vnd.apache.thrift.binary
 - application/vnd.apache.thrift.compact
 - application/vnd.apache.thrift.json
 We should use them exclusively, replacing the old x-thrift. I suggest 
 TProtocol gain a getMediaType() method which returns the correct media type 
 when invoked on a concrete protocol (e.g. TBinaryProtocol.getMediaType() 
 would return application/vnd.apache.thrift.binary.
 HTTP oriented code can then invoke the getMediaType() method of the protocol 
 to discover the correct media type to set in HTTP headers. 
 Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3250) Apache Thrift should use registered media types with HTTP

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14636660#comment-14636660
 ] 

Randy Abernethy commented on THRIFT-3250:
-

Absolutely. (I got tired of clicking the lib check boxes when I opened the 
ticket  :-)

 Apache Thrift should use registered media types with HTTP
 -

 Key: THRIFT-3250
 URL: https://issues.apache.org/jira/browse/THRIFT-3250
 Project: Thrift
  Issue Type: Improvement
  Components: C# - Library, C++ - Library, Java - Library, JavaScript 
 - Library, Node.js - Library
Affects Versions: 0.9.3
 Environment: all
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor

 Now that we have registered media types:
 - application/vnd.apache.thrift.binary
 - application/vnd.apache.thrift.compact
 - application/vnd.apache.thrift.json
 We should use them exclusively, replacing the old x-thrift. I suggest 
 TProtocol gain a getMediaType() method which returns the correct media type 
 when invoked on a concrete protocol (e.g. TBinaryProtocol.getMediaType() 
 would return application/vnd.apache.thrift.binary.
 HTTP oriented code can then invoke the getMediaType() method of the protocol 
 to discover the correct media type to set in HTTP headers. 
 Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3250) Apache Thrift should use registered media types with HTTP

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-3250:
---

 Summary: Apache Thrift should use registered media types with HTTP
 Key: THRIFT-3250
 URL: https://issues.apache.org/jira/browse/THRIFT-3250
 Project: Thrift
  Issue Type: Improvement
  Components: C# - Library, C++ - Library, Java - Library, JavaScript - 
Library, Node.js - Library
Affects Versions: 0.9.3
 Environment: all
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3


Now that we have registered media types:
- application/vnd.apache.thrift.binary
- application/vnd.apache.thrift.compact
- application/vnd.apache.thrift.json

We should use them exclusively, replacing the old x-thrift. I suggest TProtocol 
gain a getMediaType() method which returns the correct media type when invoked 
on a concrete media type (e.g. TBinaryProtocol.getMediaType() would return 
application/vnd.apache.thrift.binary.

HTTP oriented code can then invoke the getMediaType() method of the protocol to 
discover the correct media type to set in HTTP headers. 

Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3250) Apache Thrift should use registered media types with HTTP

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-3250:

Description: 
Now that we have registered media types:
- application/vnd.apache.thrift.binary
- application/vnd.apache.thrift.compact
- application/vnd.apache.thrift.json

We should use them exclusively, replacing the old x-thrift. I suggest TProtocol 
gain a getMediaType() method which returns the correct media type when invoked 
on a concrete protocol (e.g. TBinaryProtocol.getMediaType() would return 
application/vnd.apache.thrift.binary.

HTTP oriented code can then invoke the getMediaType() method of the protocol to 
discover the correct media type to set in HTTP headers. 

Thoughts?

  was:
Now that we have registered media types:
- application/vnd.apache.thrift.binary
- application/vnd.apache.thrift.compact
- application/vnd.apache.thrift.json

We should use them exclusively, replacing the old x-thrift. I suggest TProtocol 
gain a getMediaType() method which returns the correct media type when invoked 
on a concrete media type (e.g. TBinaryProtocol.getMediaType() would return 
application/vnd.apache.thrift.binary.

HTTP oriented code can then invoke the getMediaType() method of the protocol to 
discover the correct media type to set in HTTP headers. 

Thoughts?


 Apache Thrift should use registered media types with HTTP
 -

 Key: THRIFT-3250
 URL: https://issues.apache.org/jira/browse/THRIFT-3250
 Project: Thrift
  Issue Type: Improvement
  Components: C# - Library, C++ - Library, Java - Library, JavaScript 
 - Library, Node.js - Library
Affects Versions: 0.9.3
 Environment: all
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor
 Fix For: 0.9.3


 Now that we have registered media types:
 - application/vnd.apache.thrift.binary
 - application/vnd.apache.thrift.compact
 - application/vnd.apache.thrift.json
 We should use them exclusively, replacing the old x-thrift. I suggest 
 TProtocol gain a getMediaType() method which returns the correct media type 
 when invoked on a concrete protocol (e.g. TBinaryProtocol.getMediaType() 
 would return application/vnd.apache.thrift.binary.
 HTTP oriented code can then invoke the getMediaType() method of the protocol 
 to discover the correct media type to set in HTTP headers. 
 Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3250) Apache Thrift should use registered media types with HTTP

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634457#comment-14634457
 ] 

Randy Abernethy commented on THRIFT-3250:
-

I'll put some patches together.

 Apache Thrift should use registered media types with HTTP
 -

 Key: THRIFT-3250
 URL: https://issues.apache.org/jira/browse/THRIFT-3250
 Project: Thrift
  Issue Type: Improvement
  Components: C# - Library, C++ - Library, Java - Library, JavaScript 
 - Library, Node.js - Library
Affects Versions: 0.9.3
 Environment: all
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor

 Now that we have registered media types:
 - application/vnd.apache.thrift.binary
 - application/vnd.apache.thrift.compact
 - application/vnd.apache.thrift.json
 We should use them exclusively, replacing the old x-thrift. I suggest 
 TProtocol gain a getMediaType() method which returns the correct media type 
 when invoked on a concrete protocol (e.g. TBinaryProtocol.getMediaType() 
 would return application/vnd.apache.thrift.binary.
 HTTP oriented code can then invoke the getMediaType() method of the protocol 
 to discover the correct media type to set in HTTP headers. 
 Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3217) Provide a little endian variant of the binary protocol in C++

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612906#comment-14612906
 ] 

Randy Abernethy commented on THRIFT-3217:
-

I could not attribute any noticeable variation in performance between BE and LE 
protocols. 

I get about the same results as you did (ratiowise) with the provided benchmark 
prog:
thrift@ubuntu:~/t2/lib/cpp/test$ ./Benchmark 
Write big endian: 6253.51 kHz
 Read big endian: 4101.72 kHz
Write little endian: 7454.67 kHz
 Read little endian: 3944.28 kHz

However the slow first loop is likely due to cold cache. When I run the LE 
first and the BE second the output looks about the same (first loop is slow). 
I sanity tested with BE and BE and got the same result (first loop slow); then 
with LE.and LE and got the same result (first loop slow) 

When I preheat the cache (adding a preheating loop just like the first loop 
followed by a TMemoryBuffer reset) I see parity across the runs in both LE 
and BE. 

thrift@ubuntu:~/t2/lib/cpp/test$ ./Benchmark 
Write big endian: 7205.23 kHz
 Read big endian: 3986.69 kHz
Write little endian: 7210.8 kHz
 Read little endian: 3943.92 kHz
thrift@ubuntu:~/t2/lib/cpp/test$ ./Benchmark 
Write big endian: 7247.9 kHz
 Read big endian: 3990.68 kHz
Write little endian: 7414.92 kHz
 Read little endian: 4002.96 kHz
thrift@ubuntu:~/t2/lib/cpp/test$ ./Benchmark 
Write big endian: 7290.75 kHz
 Read big endian: 3969.55 kHz
Write little endian: 7429.7 kHz
 Read little endian: 4007.77 kHz
thrift@ubuntu:~/t2/lib/cpp/test$ ./Benchmark 
Write big endian: 7223.86 kHz
 Read big endian: 3928.78 kHz
Write little endian: 6812.92 kHz
 Read little endian: 4008.93 kHz
thrift@ubuntu:~/t2/lib/cpp/test$ ./Benchmark 
Write big endian: 7375.34 kHz
 Read big endian: 3965.91 kHz
Write little endian: 7397.37 kHz
 Read little endian: 4003.54 kHz

My guess is that the Intel BSWAP is too fast to notice.

 Provide a little endian variant of the binary protocol in C++
 -

 Key: THRIFT-3217
 URL: https://issues.apache.org/jira/browse/THRIFT-3217
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Library
Affects Versions: 0.9.3
Reporter: Ben Craig
Assignee: Ben Craig

 Most computers these days are little endian.  With Thrift's current binary 
 protocol, we end up adjusting endianness on both sides of the connection most 
 of the time.  We should provide a variant that is optimized for the common 
 case of little endian machines.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3200) JS and nodejs do not encode JSON protocol binary fields as base64

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599570#comment-14599570
 ] 

Randy Abernethy commented on THRIFT-3200:
-

I agree. Node and JS both still have interop gaps to close. We should make them 
cross lang compatible asap so that they are inline for v1.

 JS and nodejs do not encode JSON protocol binary fields as base64
 -

 Key: THRIFT-3200
 URL: https://issues.apache.org/jira/browse/THRIFT-3200
 Project: Thrift
  Issue Type: Bug
  Components: JavaScript - Library, Node.js - Library
Affects Versions: 0.9.2
Reporter: Adam Beberg
 Fix For: 0.9.3


 Binary fields in the JSON protocol are base64 encoded in 
 cpp/go/java/rb/py/go/... All code with JSON implementations except javascript 
 and nodejs - which escape them as if they as strings (unfinished 
 implementation). This makes js/nodejs incompatable with any other languages 
 since JSON is their only supported protocol. To fix this js/nodejs need to be 
 corrected, but this will break backward compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-2926) JavaScript: binary protocol implementation

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598907#comment-14598907
 ] 

Randy Abernethy commented on THRIFT-2926:
-

No updates I know of. If I'm missing a patch newer than the last one I 
commented on let me know.

-Randy

 JavaScript: binary protocol implementation
 --

 Key: THRIFT-2926
 URL: https://issues.apache.org/jira/browse/THRIFT-2926
 Project: Thrift
  Issue Type: Sub-task
  Components: JavaScript - Library
Affects Versions: 0.9.2
Reporter: Radoslaw Gruchalski
Assignee: Randy Abernethy
  Labels: features, javascript

 I have implemented BinaryProtocol for the JS library. Implementation provided 
 with unit tests. Looking for feedback.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-1383) Spaces in thrift input file lead to incorrectly generated code

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584717#comment-14584717
 ] 

Randy Abernethy commented on THRIFT-1383:
-

Any thoughts on solving this? 

Seems like just having the compiler reject input files with spaces might be 
easiest and most direct. The compiler could remove or convert spaces 
automatically but that seems underhanded. I would rather the compiler be 
upfront about its requirement, allowing the user to choose the appropriate 
solution.

My 2 cents

 Spaces in thrift input file lead to incorrectly generated code
 --

 Key: THRIFT-1383
 URL: https://issues.apache.org/jira/browse/THRIFT-1383
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Compiler
Reporter: Jens Geyer

 Spaces in file names produce identifiers (e.g. namespaces) with spaces, which 
 is illegal. I checked that only for the C++ generator, but there are probably 
 other generators affected as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3090) cmake build is broken

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14492985#comment-14492985
 ] 

Randy Abernethy commented on THRIFT-3090:
-

I can confirm that base packages for Centos 7 install cmake 2.8.11 while Centos 
6.5 installs 2.8.12.2. A curious state of affairs and as you suggest, probably 
temporary. I just built 2.8.12 from source on a centos 7 box and it seems to 
work fine at first blush. 
+1 for 2.8.12 if we need it.

 cmake build is broken
 -

 Key: THRIFT-3090
 URL: https://issues.apache.org/jira/browse/THRIFT-3090
 Project: Thrift
  Issue Type: Bug
 Environment: Mac OS X 10.10.3
 C++ compiler: Apple system compiler (clang), Apple LLVM version 6.0 
 (clang-600.0.57) (based on LLVM 3.5svn)
 boost 1.57
 cmake 3.2.1
Reporter: Marco Molteni

 A current version of apache/thrift on github as of 2015-04-10 doesn't build 
 with cmake due to multiple errors:
 - some C++ targets fail to link with missing symbols, because they do not 
 link against the `thrift` library
 - the c_glib test targets fail to build because the reference to `shared_ptr` 
 is considered ambiguous by the compiler (it resolves to both boost and stdlib 
 shared_ptr)
 See pull request https://github.com/apache/thrift/pull/434



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3084) C++ add concurrent client limit to threaded servers

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14491624#comment-14491624
 ] 

Randy Abernethy commented on THRIFT-3084:
-

Hey James,

Thanks for the thorough response, I +1 your implementation, a big improvement 
over what we have now, so take this as what it is, just a collegial chat. 

My real focus here is that we do not want many servers that do the same or very 
similar things. It adds little value, confuses users and creates an additional 
maintenance burden on the maintainers (close to my heart). Some of the Apache 
Thrift languages have a crazy number of (more or less redundant) servers. 
People write blog post trying to compare them. Your patch was a lightning rod 
for removing code (TThreadedServer) which is the best thing you can do to a 
code base. Thanks for that!

If you subscribe to the above minimum server axiom (which perhaps not all do), 
then a server should be in the code base because it brings something 
particularly unique to the table. The nonblocking server is event driven, the 
thread pool server is thread per client, an IOCompletion Port server is based 
on completion ports, an async server returns packets out of order, etc. So do 
we really want another synchronous, blocking, thread per client server? 
Shouldn’t we just have one good one? If we want just one good one, then is 
there a need for a shared framework base with implementation in it with a view 
on the processing model? The last thing I want to see is additional micro 
variations on the thread per client server theme. I also don’t want people to 
think they have to derive from TServerFramework (sounds pretty official). A 
server should implement TServer and that is really the only requirement.

So what about simple server. I see SimpleServer as a special case. Its one goal 
is to be simple. At the end of the day, if it is only marginally different from 
TThreadPoolServer, maybe we should delete it too. Seems like it would be silly 
to implement SimpleServer in terms of TThreadPool. Yet we sort of are with the 
proposed framework classes. It is not adding unique value anymore, it isn’t any 
simpler than TThreadPool. This leaves us with a Framework class with one 
derivative TThreadPool and takes me back to wanting to just implement it in 
TThreadPool.

I won’t bug you anymore on this, as I mentioned I am +1 on the patch. It is 
great work and though I am lobbying to package it a little differently, diverse 
views on things are a natural part of a vibrant community and it is your patch.

Best,
Randy

 C++ add concurrent client limit to threaded servers
 ---

 Key: THRIFT-3084
 URL: https://issues.apache.org/jira/browse/THRIFT-3084
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Library
Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
Reporter: James E. King, III
 Attachments: THRIFT-3084-on-3083.v2.patch


 The TThreadedServer and TThreadPoolServer do not impose limits on the number 
 of simultaneous connections, which is not useful in production as bad clients 
 can drive a server to consume too many file descriptors or have too many 
 threads.
 With TThreadPoolServer one can set the limit on the number of threads, 
 however the server will use one additional file descriptor because the 
 serve() routine does not block until after accepting the threadManager size + 
 1 sockets.
 With TThreadedServer there was no built-in way to throttle.
 Give the serve() loop is the only code capable of adding a client, the 
 solution is to add a Monitor to the TServerFramework and check the number of 
 concurrent clients immediately before calling TServerTransport::accept() to 
 get another client, and to track the number of clients that are still alive 
 (their smart pointer hasn't been destroyed).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3084) C++ add concurrent client limit to threaded servers

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490651#comment-14490651
 ] 

Randy Abernethy commented on THRIFT-3084:
-

Hey Ben: 

I agree with keeping the TThreadedServer name for 0.9.x (typedef or whatever). 
I would like to see it dropped in 1.0 though. Questions like: Should I use 
TThreaded or TThreadPool when I want a non eventlib server? and What is the 
difference between …? will go away. Given that the TThreaded interface will be 
supported in TThreadPoolServer I don't think its removal will create a 
significant burden. 

-Randy

 C++ add concurrent client limit to threaded servers
 ---

 Key: THRIFT-3084
 URL: https://issues.apache.org/jira/browse/THRIFT-3084
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Library
Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
Reporter: James E. King, III

 The TThreadedServer and TThreadPoolServer do not impose limits on the number 
 of simultaneous connections, which is not useful in production as bad clients 
 can drive a server to consume too many file descriptors or have too many 
 threads.
 1. Add a barrier to TServerTransport that will be checked before accept().
 2. In the onClientConnected override (see THRIFT-3083) if the server reaches 
 the limit of the number of accepted clients, enable the barrier.
 3. In the onClientDisconnected override if the count of connected clients 
 falls below the maximum concurrent limit, clear the barrier.  This will allow 
 the limit to be changed dynamically at runtime (lowered) with drain off 
 clients until more can be accepted.
 Alternate proposal: Implement a Semaphore and have the servers block the 
 serve() thread if the client that arrived puts the server at the concurrent 
 client limit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3084) C++ add concurrent client limit to threaded servers

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490722#comment-14490722
 ] 

Randy Abernethy commented on THRIFT-3084:
-

Hey James:

I have a different view on the implementation inheritance front. 

TSimpleServer has a responsibility, be simple, be a good way to understand 
thrift server basics and provide a clean, simple, single threaded 
implementation. TThreadPoolServer has a very different purpose, provide a 
thread per client based server implementation which can be used for handling 
scaled production loads. Semantically there is no implied implementation bond 
here, only the fact that they are both Apache Thrift servers.

TSimpleServer should have the TServer interface, but should it have the same 
implementation as TThreadPoolServer? It mostly does now but will it always? Is 
it easier or harder for me to understand the simple server with code in various 
classes handling the implementation? What if someone decides to add an 
IOCompletion port server for Windows? Should it use the framework 
implementation designed for TThreadPoolServer? Can the NonblockingServer? What 
if I need to update the TServerFramework implementation for TThreadPoolServer? 
I would need to be an expert in all of the derived servers to know for sure 
that my implementation changes will work with each of them. At this point 
TSimpleServer is not very simple, it is no longer performing its one 
responsibility. 

Tightly coupled classes (and systems in general) make maintenance hard. There 
is no tighter way to couple classes than implementation inheritance. There are 
some fairly well thought out guidelines that relate to this issue, for example:
Alexandrescu, Andrei; Herb Sutter (2004-10-25). C++ Coding Standards: 101 
Rules, Guidelines, and Best Practices 
- 34. Prefer composition to inheritance 
- 36. Prefer providing abstract interfaces 
- 37. Public inheritance is substitutability. Inherit, not to reuse, but to be 
reused

I have seen many crimes against encapsulation, separation of concerns and KIS 
committed in the name of DRY.

I am all for the other code improvements, particularly the TThreadPoolServer 
code you have written in the TServerFramework class. My “keep it simple” 
approach would be to integrate the TThreadPoolServer fixes standalone, 
deprecate TThreadedServer (implementing it with TThreadPoolServer as Ben 
suggests) and keep TSimpleServer simple and self-contained.

Just my 2 cents and certainly subjective. You are making things better patch by 
patch so I am a fan either way.

Best,
Randy


 C++ add concurrent client limit to threaded servers
 ---

 Key: THRIFT-3084
 URL: https://issues.apache.org/jira/browse/THRIFT-3084
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Library
Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
Reporter: James E. King, III

 The TThreadedServer and TThreadPoolServer do not impose limits on the number 
 of simultaneous connections, which is not useful in production as bad clients 
 can drive a server to consume too many file descriptors or have too many 
 threads.
 1. Add a barrier to TServerTransport that will be checked before accept().
 2. In the onClientConnected override (see THRIFT-3083) if the server reaches 
 the limit of the number of accepted clients, enable the barrier.
 3. In the onClientDisconnected override if the count of connected clients 
 falls below the maximum concurrent limit, clear the barrier.  This will allow 
 the limit to be changed dynamically at runtime (lowered) with drain off 
 clients until more can be accepted.
 Alternate proposal: Implement a Semaphore and have the servers block the 
 serve() thread if the client that arrived puts the server at the concurrent 
 client limit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3084) C++ add concurrent client limit to threaded servers

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14481530#comment-14481530
 ] 

Randy Abernethy commented on THRIFT-3084:
-

Prior to addressing these issues I suggest considering the removal of 
TThreadedServer. If a server is not truly differentiating then we are just 
confusing users by having it and adding work for the contributors/maintainers. 
What value add does TThreadedServer provide over TThreadPoolServer? With a few 
lines of code we could easily provide features that makde TThreadPoolServer 
behave like TThreadedServer when desired (you can do it presently by adding 
threads to the pool with server events as Ben suggests). 

Recommendations:
- We remove TThreadedServer from the system and focus on getting a single 
threaded server right (TThreadPoolServer seems like the correct starting 
point). 

By avoiding undifferentiated servers we also eliminate any need for 
complicating the server code with shared base implementations. 
TNonBlockingServer is differentiating and should share the TServer interface 
and little else, TSimpleServer should be simple and free of code hierarchies by 
design and TThreadPoolServer should stand as the threaded server and 
encapsulate good threading practices in one simple package, with pooling as an 
optimization.

Thoughts?

 C++ add concurrent client limit to threaded servers
 ---

 Key: THRIFT-3084
 URL: https://issues.apache.org/jira/browse/THRIFT-3084
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Library
Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
Reporter: James E. King, III

 The TThreadedServer and TThreadPoolServer do not impose limits on the number 
 of simultaneous connections, which is not useful in production as bad clients 
 can drive a server to consume too many file descriptors or have too many 
 threads.
 1. Add a barrier to TServerTransport that will be checked before accept().
 2. In the onClientConnected override (see THRIFT-3083) if the server reaches 
 the limit of the number of accepted clients, enable the barrier.
 3. In the onClientDisconnected override if the count of connected clients 
 falls below the maximum concurrent limit, clear the barrier.  This will allow 
 the limit to be changed dynamically at runtime (lowered) with drain off 
 clients until more can be accepted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3078) TNonblockingServerSocket's logger is not named after TNonblockingServerSocket

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-3078.
-
Resolution: Duplicate

 TNonblockingServerSocket's logger is not named after TNonblockingServerSocket
 -

 Key: THRIFT-3078
 URL: https://issues.apache.org/jira/browse/THRIFT-3078
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.9.1, 0.9.2
Reporter: Xiaoshuang LU





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3072) Build in separate directory

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14393144#comment-14393144
 ] 

Randy Abernethy commented on THRIFT-3072:
-

I agree. While it has not been taken to a vote yet, it appears there is strong 
momentum for conversion to cmake. This would be a nice feature to have in the 
v1.0 build solution either way.

 Build in separate directory
 ---

 Key: THRIFT-3072
 URL: https://issues.apache.org/jira/browse/THRIFT-3072
 Project: Thrift
  Issue Type: Improvement
  Components: Build Process
Affects Versions: 0.9.2
Reporter: James E. King, III

 The thrift build environment leverages .gitignore extensively to allow for 
 [builds in the same 
 directory|http://wiki.apache.org/thrift/ThriftInstallation] as the source.  
 It would be preferable to allow for an external build directory such that the 
 source directory could be read-only.  This would allow for an extensive 
 simplification of .gitignore and easier cleanup of builds, and maintain a 
 pristine source directory.
 {code}
 ~/thrift$ cd ..
 ~$ cd thrift-build
 ~/thrift-build$ ../thrift/bootstrap.sh 
 ../thrift/bootstrap.sh: 22: ../thrift/bootstrap.sh: ./cleanup.sh: not found
 aclocal: error: 'configure.ac' is required
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)