Build failed in Jenkins: Thrift #160

[Apache Jenkins Server]

See 

Changes:

[bryanduxbury] THRIFT-1180. as3: AS3 compiler generates uncompilable code for 
binary types.

Switch to ByteArray.

Patch: Ethan Urie

[bryanduxbury] fix indentation

[bryanduxbury] THRIFT-1140. glib_c: Framed Transport Client using C (Glib) 
Library hangs when connecting to Ruby Server

Include the size of the whole buffer.

Patch: Lukas Fittl

[bryanduxbury] THRIFT-1200. js: JS compiler generates code that clobbers 
existing namespaces

Patch: Ilya Maykov

[bryanduxbury] THRIFT-1193. rb: Potential infinite loop in nonblocking_server

Patch: Ilya Maykov

[bryanduxbury] THRIFT-1199. java: Union structs should have generated methods 
to test whether a specific field is currently set 

Patch: Piotr Kozikowski

--
[...truncated 1781 lines...]
make[5]: Leaving directory 
`
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
make[2]: Leaving directory 
`
Making check in csharp
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory 
`
Making check in java
make[2]: Entering directory 
`
/usr/bin/ant 
Buildfile: 

setup.init:

mvn.ant.tasks.check:

mvn.ant.tasks.download:
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/maven/maven-ant-tasks/2.1.3/maven-ant-tasks-2.1.3.jar
  [get] To: 

  [get] Not modified - so not downloaded

mvn.init:
[artifact:dependencies] [WARNING] Overriding profile: 
'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: pom

init:

compile:

dist:

BUILD SUCCESSFUL
Total time: 1 second
make  check-local
make[3]: Entering directory 
`
/usr/bin/ant 
Buildfile: 

setup.init:

mvn.ant.tasks.check:

mvn.ant.tasks.download:
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/maven/maven-ant-tasks/2.1.3/maven-ant-tasks-2.1.3.jar
  [get] To: 

  [get] Not modified - so not downloaded

mvn.init:
[artifact:dependencies] [WARNING] Overriding profile: 
'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: pom

init:

compile:

dist:

BUILD SUCCESSFUL
Total time: 1 second
/usr/bin/ant  test
Buildfile: 

generate:
 [exec] 
[WARNING::41]
 64-bit constant "100" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::169]
 64-bit constant "1099511627775" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "4294967295" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "1099511627775" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "281474976710655" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "72057594037927935" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "9223372036854775807" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "4294967295" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "1099511627775" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "281474976710655" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constan

[jira] [Commented] (THRIFT-1177) Update thrift to reflect changes in Go's networking libraries

[Aalok Shah (JIRA)]

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

Aalok Shah commented on THRIFT-1177:


It appears in the current stable release (r57.1) of Go, http.Get() returns 3 
values.
In the latest development version, http.Get() returns 2 values.
As there is no way to perform conditional compilations (a la #ifdef in C), a 
version can either work with the stable release or tip, but not both.

I assume the Thrift project prefers working with the latest stable release 
rather than the fluctuations that can occur on tip.

Thanks for looking at the patch.

> Update thrift to reflect changes in Go's networking libraries
> -
>
> Key: THRIFT-1177
> URL: https://issues.apache.org/jira/browse/THRIFT-1177
> Project: Thrift
>  Issue Type: Dependency upgrade
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.7
>Reporter: Aalok Shah
>Priority: Minor
> Fix For: 0.7
>
> Attachments: gopatch2-r2.diff, gopatch2.diff
>
>
> Go updated its networking libraries requiring a change to both the thrift 
> code generator and the libraries.
> Additionally, the Go generator did not support arguments/variables that were 
> Go keywords, this needs to be updated to work with Cassandra's thrift since 
> "range" is a Go keyword.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1039) Refactor methods accessing binary data

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-1039:
--

Fix Version/s: (was: 0.7)
   0.8

> Refactor methods accessing binary data
> --
>
> Key: THRIFT-1039
> URL: https://issues.apache.org/jira/browse/THRIFT-1039
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Compiler
> Environment: All
>Reporter: Mathias Herberts
>Priority: Minor
> Fix For: 0.8
>
> Attachments: THRIFT-1039.patch
>
>
> Since THRIFT-830, binary fields are implemented using ByteBuffer.
> struct A {
>   1: binary bin_field,
> }
> will generate a method 'byte[] getBin_field()' which will optionally resize 
> the underlying ByteBuffer so it has a capacity of 'remaining()' and return 
> the backing array of this new ByteBuffer.
> This has several implications.
> First the ByteBuffer in 'bin_field' might be modified, thus misleading users 
> into thinking that the call to 'getBin_field()' had no effect on the 
> underlying structure.
> Thus the following will fail:
> byte[] b = new byte[2];
> b[0] = 0x01;
> A a = new A();
> a.setBin_field(ByteBuffer.wrap(b, 0, 1));
> byte[] bb = a.getBin_field();
> b[0] = 0x02;
> Assert.assertEquals(0x02, bb[0]);
> Second it creates a singularity in the getters as all other getters involving 
> containers of binary data will return collections of ByteBuffer.
> I suggest we refactor to something more in the line of what HADOOP-6298 has 
> done, i.e. provide a copyBytes() method which copies the bytes in a 
> ByteBuffer and returns a correctly sized array.
> Such a method could be generated for each structure, with the following 
> signature:
> public byte[] copyBytes(ByteBuffer b);
> This method would basically do what the current 'getBin_field' type methods 
> do (allocate a byte array and fill it with the ByteBuffer's data), except it 
> would not modify the structure's internal ByteBuffers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1007) Deserializer override for ByteBuffer input

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-1007:
--

Fix Version/s: (was: 0.7)
   0.8

> Deserializer override for ByteBuffer input
> --
>
> Key: THRIFT-1007
> URL: https://issues.apache.org/jira/browse/THRIFT-1007
> Project: Thrift
>  Issue Type: New Feature
>Affects Versions: 0.5
>Reporter: Bryan Duxbury
> Fix For: 0.8
>
>
> Would be very convenient to be able to deserialize directly out of a 
> ByteBuffer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-966) Bind to zero port

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-966:
-

Fix Version/s: (was: 0.7)

> Bind to zero port
> -
>
> Key: THRIFT-966
> URL: https://issues.apache.org/jira/browse/THRIFT-966
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: Ivan Murashko
> Attachments: bindinfo_retrieval.diff
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> apache::thrift::transport::TServerSocket class has a possibility to set 0 as 
> port number. In this case bind will assign a free port number. Unfortunately 
> there is no possibility to retrieve the assigned port number from the 
> TServerSocket class. Thus clients will not be able to connect the server.
> The suggested patch introduces 
> apache::thrift::transport::TServerSocket::getBindPort() method that return 
> the assigned port number or -1 in the case of any failure or when the port 
> has not been assigned yet.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-883) Extend ByteBuffer support to non-array-backed ByteBuffers

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-883:
-

Fix Version/s: (was: 0.7)
   0.8

> Extend ByteBuffer support to non-array-backed ByteBuffers
> -
>
> Key: THRIFT-883
> URL: https://issues.apache.org/jira/browse/THRIFT-883
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.4
>Reporter: Bryan Duxbury
>Assignee: Bryan Duxbury
> Fix For: 0.8
>
> Attachments: TBinaryProtocol-writeBinary.patch
>
>
> Binary fields are backed by ByteBuffers that wrap byte arrays, and all the 
> protocol code assumes that every ByteBuffer is of this type. However, now 
> that the structs setters allow ByteBuffer arguments, it would be nice to 
> support other kinds of ByteBuffers, like those that are allocated direct.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-965) Use a queue instead of a set to record interest changes in NonblockingServer

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-965:
-

Fix Version/s: (was: 0.7)

> Use a queue instead of a set to record interest changes in NonblockingServer
> 
>
> Key: THRIFT-965
> URL: https://issues.apache.org/jira/browse/THRIFT-965
> Project: Thrift
>  Issue Type: Improvement
>Affects Versions: 0.2, 0.3, 0.4, 0.5
>Reporter: Bryan Duxbury
>Assignee: Bryan Duxbury
>
> Right now we use a HashSet to record interest changes. This requires us to 
> synchronize on access to it which seems like an unnecessary contention 
> bottleneck. Instead, if we used a queue, we could do standard 
> producer/consumer and use more granular locks (if any).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-963) Reuse buffers in TNonblockingServer

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-963:
-

Fix Version/s: (was: 0.7)

> Reuse buffers in TNonblockingServer
> ---
>
> Key: THRIFT-963
> URL: https://issues.apache.org/jira/browse/THRIFT-963
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Reporter: Bryan Duxbury
>Assignee: Bryan Duxbury
>
> Right now, we reallocate buffers all the time (twice per request!). We should 
> be able to reuse these buffers quite easily. The only downside to reusing 
> buffers is that each connection will hold as much memory as the biggest 
> request they ever saw, which can be wasteful. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1180) AS3 compiler generates uncompilable code for binary types.

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury closed THRIFT-1180.
-

Resolution: Fixed
  Assignee: Ethan Urie

I just committed this to TRUNK.

> AS3 compiler generates uncompilable code for binary types.
> --
>
> Key: THRIFT-1180
> URL: https://issues.apache.org/jira/browse/THRIFT-1180
> Project: Thrift
>  Issue Type: Bug
>  Components: AS3 - Compiler
>Affects Versions: 0.5, 0.6, 0.6.1, 0.7
> Environment: Mac OS X 10.6.7 
>Reporter: Ethan Urie
>Assignee: Ethan Urie
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-1180_use_ByteArray_for_binary_types.patch
>
>
> When a thrift definition file includes a field of type {{binary}} the 
> generated code uses {{byte[]}} which is not valid AS3 (there's no byte 
> primitive). AS3 does provide the ByteArray class which would fix this issue.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1029) Function parameter documentation is not rendered to HTML

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-1029:
--

Fix Version/s: (was: 0.7)

> Function parameter documentation is not rendered to HTML
> 
>
> Key: THRIFT-1029
> URL: https://issues.apache.org/jira/browse/THRIFT-1029
> Project: Thrift
>  Issue Type: Bug
>  Components: Compiler (General)
>Affects Versions: 0.4
> Environment: linux 64 bit, thrift 0.4.0
>Reporter: Dvir Volk
>Priority: Minor
>
> the test file TestDoc.thrift mentions that method parameters should be 
> documented like so:
>   /** This is an example of a function with params documented */
>   Numberz  testEnum(
> /** This param is a thing */
> 1: Numberz thing
>   ),
> rendering this file (or other files with parameters documented like this) to 
> HTML does not render the parameter documentation, just the function's.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1012) Transport for DataInput DataOutput interface

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-1012:
--

Fix Version/s: (was: 0.7)

> Transport for DataInput DataOutput interface
> 
>
> Key: THRIFT-1012
> URL: https://issues.apache.org/jira/browse/THRIFT-1012
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>Priority: Minor
> Attachments: 1012_v1.txt
>
>
> Java library needs a transport for DataInput and DataOutput interfaces. 
> specifically RandomAccessFile implements these.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1019) java backend should use fully qualified names for domain types

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-1019:
--

Fix Version/s: (was: 0.7)

> java backend should use fully qualified names for domain types
> --
>
> Key: THRIFT-1019
> URL: https://issues.apache.org/jira/browse/THRIFT-1019
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Reporter: Peter Schuller
>Priority: Minor
>
> This is a follow-up to THRIFT-1013. The left-overs from that is to also do 
> fully qualified names for the domain classes (for example even with the 
> changes in THRIFT-1013, our 'State' still conflicted because an inner class 
> used for asynch method calls extended the TAsynchMethodCall, bringing State 
> into scope).
> Simply changing type_name() to always generate fully qualified names (not 
> just when program differs) was very simple, but unfortunately was not enough. 
> This exposes the issues that inner classes are not accessible by 
> "package.classname" but rather as "package.outerclass.classname".
> I found no trivial way to fix this because it requires maintaining some new 
> state that is specific to the Java backend, and it affects code (particularly 
> the client bit) that I'm not in a good position to test (currently using it 
> only for server-side). I'm having to drop this for time reasons and instead 
> rename the structure in our thrift spec for now, but I wanted to file the 
> issue anyway even though i don't expect to submit a patch.
> Briefly, what I would have started doing (though I'm not comfortable saying 
> it's the cleanest way to do it), was to add a map member to the generator 
> where one would put the information that maps a t_struct to its enclosing 
> t_struct. This could be filled in while looping in 
> generate_service_helpers(), and looked at in whenever type_name() is used to 
> refer to a type. I'm not sure whether this is enough or not since I haven't 
> tried it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1167) Java nonblocking server with more than one thread for select and handling IO

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury commented on THRIFT-1167:
---

OK, that makes sense. I generally don't expect that most people will end up 
with really skewed selectors, at least for reasonably large numbers of clients.

I had an alternative that is definitely not better, so let's not even talk 
about it :)

> Java nonblocking server with more than one thread for select and handling IO
> 
>
> Key: THRIFT-1167
> URL: https://issues.apache.org/jira/browse/THRIFT-1167
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
>Reporter: Steve Jiang
>Assignee: Bryan Duxbury
> Attachments: threadedselectorthrift3.diff
>
>
> I've used the HsHa server model to write a server that uses a thread for 
> accept and a separate, configurable number of Selector threads to handle IO.  
> I'd like to contribute this back to Thrift.
> For apps that are RPC-heavy and require little computation from the executor 
> pool running on multi-core architectures, this server allows gets throughput 
> as IO is not limited by one CPU.
> Please take a look at the attached patch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1140) Framed Transport Client using C (Glib) Library hangs when connecting to Ruby Server

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury closed THRIFT-1140.
-

Resolution: Fixed
  Assignee: Lukas Fittl

I just committed this to TRUNK.

> Framed Transport Client using C (Glib) Library hangs when connecting to Ruby 
> Server
> ---
>
> Key: THRIFT-1140
> URL: https://issues.apache.org/jira/browse/THRIFT-1140
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
> Environment: Debian 6.0, 64-bit
>Reporter: Lukas Fittl
>Assignee: Lukas Fittl
> Fix For: 0.7
>
> Attachments: thrift-1140.patch
>
>
> When using the C (Glib) library to connect using the framed transport and 
> binary protocol to connect to a Ruby-based server, the connection just hangs 
> during the write phase.
> This is due to a too big size being set in the Thrift header, so the server 
> waits for 4 bytes more than are actually being sent.
> The same issue happens the other way around, when the server sends a 
> response, but the client thinks it needs 4 more bytes of data.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-902) socket and connect timeout in TSocket should be distinguished

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-902:
-

Fix Version/s: (was: 0.7)

> socket and connect timeout in TSocket should be distinguished
> -
>
> Key: THRIFT-902
> URL: https://issues.apache.org/jira/browse/THRIFT-902
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.4
>Reporter: Piotr Bartosiewicz
>Priority: Minor
>
> Currently the same timeout value is passed to the socket.connect and 
> socket.setSoTimeout. I think that this timeouts should be distinguished 
> because they have different meanings.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1167) Java nonblocking server with more than one thread for select and handling IO

[Steve Jiang (JIRA)]

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

Steve Jiang commented on THRIFT-1167:
-

The sockets are currently owned by a single thread (assigned round-robin at 
accept time) for the lifetime of the connection.  The server allows overriding 
"createSelectorThreadLoadBalancer" to provide a smarter assignment strategy.  
However, this is only balancing at accept time so a particular thread may still 
be assigned a disproportionate number of long-lived, high-throughput 
connections but no worse than the current single select thread model.

I haven't run into this problem, but this could be changed so that there's an 
opportunity to re-assign a connection whenever a request is completed. However, 
that strategy might introduce more context switches in the non-problematic 
cases.  Did you have other ideas in mind?

> Java nonblocking server with more than one thread for select and handling IO
> 
>
> Key: THRIFT-1167
> URL: https://issues.apache.org/jira/browse/THRIFT-1167
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
>Reporter: Steve Jiang
>Assignee: Bryan Duxbury
> Attachments: threadedselectorthrift3.diff
>
>
> I've used the HsHa server model to write a server that uses a thread for 
> accept and a separate, configurable number of Selector threads to handle IO.  
> I'd like to contribute this back to Thrift.
> For apps that are RPC-heavy and require little computation from the executor 
> pool running on multi-core architectures, this server allows gets throughput 
> as IO is not limited by one CPU.
> Please take a look at the attached patch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-847) Test Framework harmonization across all languages

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-847:
-

Fix Version/s: (was: 0.7)
   0.8

> Test Framework harmonization across all languages
> -
>
> Key: THRIFT-847
> URL: https://issues.apache.org/jira/browse/THRIFT-847
> Project: Thrift
>  Issue Type: Improvement
>  Components: C# - Library, C++ - Library, Cocoa - Library, Erlang - 
> Library, Haskell - Library, Java - Library, JavaScript - Library, OCaml - 
> Library, Perl - Library, PHP - Library, Python - Library, Ruby - Library, 
> Test Suite
>Affects Versions: 0.1, 0.2, 0.3
>Reporter: Roger Meier
>Assignee: Christian Lavoie
>  Labels: gsoc2011, mentor
> Fix For: 0.8
>
> Attachments: v1-WORK_IN_PROGRESS-unified_tests.tar.gz
>
>
> Today each Language supported by Thrift, have its own unit test, all are 
> using the same Thrift IDL's located at the test directory. But the behavior 
> of these tests seems to be different from language to language... this makes 
> it difficult to do tests and bug fixing across different Languages. e.g.
> * C++ Test and JavaScript Test Server written in Java have different 
> responses for the same services
> * C# and Java Test Server have different responses for testException as C++
> I propose the following steps:
> * identify the language with the reference implementation (well defined 
> return values for all test cases) 
> * update the ThriftTest.thrift with details about the required return values 
> that have to be implemented
> * update test implementations and move language tests into their appropriate 
> library directory (THRIFT-35)
> * a public test server that supports multiple protocols and transports could 
> be another enhancement for testing purposes
> I'm ready to help preparing patches, just tell me what you need!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-936) Thrift libraries for Object Pascal language

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-936:
-

 Priority: Trivial  (was: Major)
Fix Version/s: (was: 0.7)

> Thrift libraries for Object Pascal language
> ---
>
> Key: THRIFT-936
> URL: https://issues.apache.org/jira/browse/THRIFT-936
> Project: Thrift
>  Issue Type: New Feature
> Environment: Borland Delphi 7, Windows 
>Reporter: Jens Geyer
>Priority: Trivial
>
> Make Thrift libraries available for Borland Pascal 7 on Windows.
> Support for newer Delphi versions and Free Pascal will be added later.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-915) autotools doesn't barf (but fails) when some components are missing

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-915:
-

 Priority: Minor  (was: Major)
Fix Version/s: (was: 0.7)

> autotools doesn't barf (but fails) when some components are missing
> ---
>
> Key: THRIFT-915
> URL: https://issues.apache.org/jira/browse/THRIFT-915
> Project: Thrift
>  Issue Type: Bug
>Affects Versions: 0.5
> Environment: Debian unstable, as of 2010/09/22
>Reporter: Christian Lavoie
>Priority: Minor
> Attachments: configure-no-flex, configure-no-flex-bison, 
> configure-no-flex-bison-pkg-config, dpkg.log, make-no-flex, make-no-flex-bison
>
>
> When some fundamental components are missing (flex, yacc, pkg-config, 
> partial-boosts install...), thrift's configure.ac dies in non-obvious ways. 
> In some cases it aborts with a MONO-related error (it complains about parsing 
> errors near the 'MONO' token) or sometimes just halts halfway through the 
> configure tests (it'll stop before running config.status and after checking 
> for the slew of c functions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-937) Very basic version of the pascal libraries

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-937:
-

 Priority: Trivial  (was: Major)
Fix Version/s: (was: 0.7)

> Very basic version of the pascal libraries
> --
>
> Key: THRIFT-937
> URL: https://issues.apache.org/jira/browse/THRIFT-937
> Project: Thrift
>  Issue Type: Sub-task
> Environment: Borland Delphi 7, Windows
>Reporter: Jens Geyer
>Priority: Trivial
> Attachments: THRIFT-936_basic_set_of_Object_Pascal_libraries.zip
>
>
> First goal is to get a basic version of the libraries ready. To pass this 
> first step, the code shall compile without warnings and pass a very basic 
> smoke test with Borland Delphi 7 on Windows. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-938) Pascal version of the tutorial sample code

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-938:
-

 Priority: Minor  (was: Major)
Fix Version/s: (was: 0.7)

> Pascal version of the tutorial sample code
> --
>
> Key: THRIFT-938
> URL: https://issues.apache.org/jira/browse/THRIFT-938
> Project: Thrift
>  Issue Type: Sub-task
> Environment: Borland Pascal 7, Windows
>Reporter: Jens Geyer
>Priority: Minor
>
> Add Object Pascal version of the tutorial samples. Except for the code 
> generation part, make sure all required libraries are ready to compile (and 
> later test) the tutorial sample code successfully.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1200) JS compiler generates code that clobbers existing namespaces

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury closed THRIFT-1200.
-

   Resolution: Fixed
Fix Version/s: 0.7

I just committed this to trunk.

> JS compiler generates code that clobbers existing namespaces
> 
>
> Key: THRIFT-1200
> URL: https://issues.apache.org/jira/browse/THRIFT-1200
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler
>Affects Versions: 0.6.1
> Environment: all
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Fix For: 0.7
>
> Attachments: THRIFT-1200-js-namespace-fix.txt
>
>
> The JavaScript compiler currently generates code that will clobber an 
> already-existing namespace. It should check if the namespace exists before 
> initializing it to {}. Example code pre-patch, assuming the .thrift file has 
> the declaration {{namespace js CompanyName.ModuleName}}:
> {code:JavaScript}
> var CompanyName = {};
> CompanyName.ModuleName = {}
> {code}
> Becomes this after patch:
> {code:JavaScript}
> if (typeof CompanyName === 'undefined') CompanyName = {};
> if (typeof CompanyName.ModuleName === 'undefined') CompanyName.ModuleName = 
> {};
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1167) Java nonblocking server with more than one thread for select and handling IO

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury commented on THRIFT-1167:
---

OK, that helps a lot.

Here's one question I've been trying to solve. In this architecture, does a 
given socket get bound to a particular select thread for the lifetime of the 
connection, or do the sockets move around between selectors opportunistically?

> Java nonblocking server with more than one thread for select and handling IO
> 
>
> Key: THRIFT-1167
> URL: https://issues.apache.org/jira/browse/THRIFT-1167
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
>Reporter: Steve Jiang
>Assignee: Bryan Duxbury
> Attachments: threadedselectorthrift3.diff
>
>
> I've used the HsHa server model to write a server that uses a thread for 
> accept and a separate, configurable number of Selector threads to handle IO.  
> I'd like to contribute this back to Thrift.
> For apps that are RPC-heavy and require little computation from the executor 
> pool running on multi-core architectures, this server allows gets throughput 
> as IO is not limited by one CPU.
> Please take a look at the attached patch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1200) JS compiler generates code that clobbers existing namespaces

[Ilya Maykov (JIRA)]

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

Ilya Maykov commented on THRIFT-1200:
-

As far as I know, the "var" keyword is not necessary here. In JavaScript, 
omitting "var" always makes a variable global. Using "var" gives a variable 
local scope (so, within a function would give it function scope). However, 
because the namespace declaration happens at global scope, the "var" keyword 
has no effect.

> JS compiler generates code that clobbers existing namespaces
> 
>
> Key: THRIFT-1200
> URL: https://issues.apache.org/jira/browse/THRIFT-1200
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler
>Affects Versions: 0.6.1
> Environment: all
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Attachments: THRIFT-1200-js-namespace-fix.txt
>
>
> The JavaScript compiler currently generates code that will clobber an 
> already-existing namespace. It should check if the namespace exists before 
> initializing it to {}. Example code pre-patch, assuming the .thrift file has 
> the declaration {{namespace js CompanyName.ModuleName}}:
> {code:JavaScript}
> var CompanyName = {};
> CompanyName.ModuleName = {}
> {code}
> Becomes this after patch:
> {code:JavaScript}
> if (typeof CompanyName === 'undefined') CompanyName = {};
> if (typeof CompanyName.ModuleName === 'undefined') CompanyName.ModuleName = 
> {};
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1195) Allow users to act on client connects/disconnects

[David Reiss (JIRA)]

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

David Reiss commented on THRIFT-1195:
-

In C++, the TServerEventHandler and TProcessorEventHandler are the hook points 
for this.  It's a little more overhead to have separate objects, but it saves 
you from having to inject arbitrary special names into the handlers or worrying 
about default implementations.

> Allow users to act on client connects/disconnects
> -
>
> Key: THRIFT-1195
> URL: https://issues.apache.org/jira/browse/THRIFT-1195
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
> Environment: Ubuntu 11.04, Sun JVM
>Reporter: Diwaker Gupta
> Attachments: THRIFT-1195-v0.patch
>
>
> As it stands, the Java library doesn't provide any hooks to detect exactly 
> when a client got connected/disconnected. For many services, this information 
> is both useful and required for things like cleaning up state.
> There are of course many possible ways to address this. Here are some 
> thoughts from my initial mail on the topic:
> {noformat}
> Suppose I have a stateful service and I'd like to clean up some state
> when a client disconnects. IIUC, there's no straight forward way to do
> this with Thrift. I'd love to hear what others have done in similar
> situations.
> I'm trying to figure out if there's a way to support this without
> modifying Thrift core (this is all with the Thrift Java library):
> * my first instinct was to extend TFramedTransport with a custom
> factory that allows adding "listeners" that can be fired on a close.
> Unfortunately it seems like TFramedTransport.close is either never
> called, or not called when a client disconnects. The actual socket
> close is wrapped up inside a TNonblockingSocket within the FrameBuffer
> managed by TNonblockingServer. So this approach doesn't work.
> * Since the client socket is generated by
> TNonblockingServerSocket.accept, I next considered overriding
> accemptImpl() in a custom ServerSocket. This poses other problems --
> because much of the state in TNonblockingServerSocket is private, I
> need to use super.acceptImpl() to obtain the TNonblockingSocket (or
> reimplement everything). This in turn is not helpful because I then
> need to wrap the returned TNonblockingSocket in another "forwarding
> object" such that the listeners can be fired when the socket is
> closed.
> {noformat}
> Unfortunately I did not find any way to do this without modifying Thrift 
> itself, hence this issue. After evaluating several different alternatives, I 
> decided to go with the least intrusive approach, which is implemented in the 
> attached patch. Basically users can add open/close handlers as part of the 
> Args supplied to TNonblockingServer. The server code then invokes the 
> callbacks when appropriate. I realize this approach is not perfect so I'm 
> eager to get some feedback and hear some alternatives.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1195) Allow users to act on client connects/disconnects

[Diwaker Gupta (JIRA)]

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

Diwaker Gupta commented on THRIFT-1195:
---

Sure. As long as there's a reasonable hook, I'm not particularly attached to a 
specific implementation.

> Allow users to act on client connects/disconnects
> -
>
> Key: THRIFT-1195
> URL: https://issues.apache.org/jira/browse/THRIFT-1195
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
> Environment: Ubuntu 11.04, Sun JVM
>Reporter: Diwaker Gupta
> Attachments: THRIFT-1195-v0.patch
>
>
> As it stands, the Java library doesn't provide any hooks to detect exactly 
> when a client got connected/disconnected. For many services, this information 
> is both useful and required for things like cleaning up state.
> There are of course many possible ways to address this. Here are some 
> thoughts from my initial mail on the topic:
> {noformat}
> Suppose I have a stateful service and I'd like to clean up some state
> when a client disconnects. IIUC, there's no straight forward way to do
> this with Thrift. I'd love to hear what others have done in similar
> situations.
> I'm trying to figure out if there's a way to support this without
> modifying Thrift core (this is all with the Thrift Java library):
> * my first instinct was to extend TFramedTransport with a custom
> factory that allows adding "listeners" that can be fired on a close.
> Unfortunately it seems like TFramedTransport.close is either never
> called, or not called when a client disconnects. The actual socket
> close is wrapped up inside a TNonblockingSocket within the FrameBuffer
> managed by TNonblockingServer. So this approach doesn't work.
> * Since the client socket is generated by
> TNonblockingServerSocket.accept, I next considered overriding
> accemptImpl() in a custom ServerSocket. This poses other problems --
> because much of the state in TNonblockingServerSocket is private, I
> need to use super.acceptImpl() to obtain the TNonblockingSocket (or
> reimplement everything). This in turn is not helpful because I then
> need to wrap the returned TNonblockingSocket in another "forwarding
> object" such that the listeners can be fired when the socket is
> closed.
> {noformat}
> Unfortunately I did not find any way to do this without modifying Thrift 
> itself, hence this issue. After evaluating several different alternatives, I 
> decided to go with the least intrusive approach, which is implemented in the 
> attached patch. Basically users can add open/close handlers as part of the 
> Args supplied to TNonblockingServer. The server code then invokes the 
> callbacks when appropriate. I realize this approach is not perfect so I'm 
> eager to get some feedback and hear some alternatives.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1195) Allow users to act on client connects/disconnects

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury commented on THRIFT-1195:
---

What if we changed the compiler to generate special "connect" and "hang up" 
methods on the interface for the handlers? I think that would be a lot more 
straightforward and usable, plus it would also set the stage for supporting the 
feature in other server types.

> Allow users to act on client connects/disconnects
> -
>
> Key: THRIFT-1195
> URL: https://issues.apache.org/jira/browse/THRIFT-1195
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
> Environment: Ubuntu 11.04, Sun JVM
>Reporter: Diwaker Gupta
> Attachments: THRIFT-1195-v0.patch
>
>
> As it stands, the Java library doesn't provide any hooks to detect exactly 
> when a client got connected/disconnected. For many services, this information 
> is both useful and required for things like cleaning up state.
> There are of course many possible ways to address this. Here are some 
> thoughts from my initial mail on the topic:
> {noformat}
> Suppose I have a stateful service and I'd like to clean up some state
> when a client disconnects. IIUC, there's no straight forward way to do
> this with Thrift. I'd love to hear what others have done in similar
> situations.
> I'm trying to figure out if there's a way to support this without
> modifying Thrift core (this is all with the Thrift Java library):
> * my first instinct was to extend TFramedTransport with a custom
> factory that allows adding "listeners" that can be fired on a close.
> Unfortunately it seems like TFramedTransport.close is either never
> called, or not called when a client disconnects. The actual socket
> close is wrapped up inside a TNonblockingSocket within the FrameBuffer
> managed by TNonblockingServer. So this approach doesn't work.
> * Since the client socket is generated by
> TNonblockingServerSocket.accept, I next considered overriding
> accemptImpl() in a custom ServerSocket. This poses other problems --
> because much of the state in TNonblockingServerSocket is private, I
> need to use super.acceptImpl() to obtain the TNonblockingSocket (or
> reimplement everything). This in turn is not helpful because I then
> need to wrap the returned TNonblockingSocket in another "forwarding
> object" such that the listeners can be fired when the socket is
> closed.
> {noformat}
> Unfortunately I did not find any way to do this without modifying Thrift 
> itself, hence this issue. After evaluating several different alternatives, I 
> decided to go with the least intrusive approach, which is implemented in the 
> attached patch. Basically users can add open/close handlers as part of the 
> Args supplied to TNonblockingServer. The server code then invokes the 
> callbacks when appropriate. I realize this approach is not perfect so I'm 
> eager to get some feedback and hear some alternatives.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1191) Erlang binding throws during skipping fields of composite type (maps, lists, structs, sets)

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury commented on THRIFT-1191:
---

The pull request you reference seems to have changes to the AS3 generator as 
well as changes to protocol.erl. That seems unintentional, right?

> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> ---
>
> Key: THRIFT-1191
> URL: https://issues.apache.org/jira/browse/THRIFT-1191
> Project: Thrift
>  Issue Type: Bug
>  Components: Erlang - Library
>Reporter: Anatoly Kanivetsky
>
> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> Here's the pull request with this fix:
> https://github.com/apache/thrift/pull/3 here is the patch
> Here's the fix only:
> https://github.com/chaos-ad/thrift/commit/d70576209ae01f7ae56a1afccc1210d120b0ecde

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1193) Potential infinite loop in nonblocking_server

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury closed THRIFT-1193.
-

   Resolution: Fixed
Fix Version/s: 0.7

I just committed this. Thanks for the patch, Ilya!

> Potential infinite loop in nonblocking_server
> -
>
> Key: THRIFT-1193
> URL: https://issues.apache.org/jira/browse/THRIFT-1193
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
>Priority: Minor
> Fix For: 0.7
>
> Attachments: patch-THRIFT-1193.txt
>
>
> The fix for THRIFT-1187 could cause the server to enter an infinite loop if 
> select() started throwing Errno::EBADF when called on a non-closed 
> @server_transport.
> The obvious fix is to turn the 'next' into a 'break'.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1200) JS compiler generates code that clobbers existing namespaces

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury commented on THRIFT-1200:
---

So you don't need the "var" statement, even for the first segment?

> JS compiler generates code that clobbers existing namespaces
> 
>
> Key: THRIFT-1200
> URL: https://issues.apache.org/jira/browse/THRIFT-1200
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler
>Affects Versions: 0.6.1
> Environment: all
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Attachments: THRIFT-1200-js-namespace-fix.txt
>
>
> The JavaScript compiler currently generates code that will clobber an 
> already-existing namespace. It should check if the namespace exists before 
> initializing it to {}. Example code pre-patch, assuming the .thrift file has 
> the declaration {{namespace js CompanyName.ModuleName}}:
> {code:JavaScript}
> var CompanyName = {};
> CompanyName.ModuleName = {}
> {code}
> Becomes this after patch:
> {code:JavaScript}
> if (typeof CompanyName === 'undefined') CompanyName = {};
> if (typeof CompanyName.ModuleName === 'undefined') CompanyName.ModuleName = 
> {};
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (THRIFT-1047) rb_thrift_memory_buffer_write treats arg as string without check, segfaults if you pass non-string

[Ilya Maykov (JIRA)]

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

Ilya Maykov edited comment on THRIFT-1047 at 6/8/11 10:03 PM:
--

Jake - can you also add the type check to the pure-Ruby implementation of 
MemoryBufferTransport (in 
lib/rb/lib/thrift/transport/memory_buffer_transport.rb)? Otherwise, the native 
and non-native implementations will behave differently. This is relevant for 
non-MRI Ruby interpreters (JRuby, maybe some others) where the native 
extensions don't load correctly and the thrift gem falls back to the native 
implementations.

  was (Author: ilyam):
Jake - can you also add the type check to the pure-Ruby implementation of 
MemoryBufferTransport (in lib/rb/thrift/transport/memory_buffer_transport.rb)? 
Otherwise, the native and non-native implementations will behave differently. 
This is relevant for non-MRI Ruby interpreters (JRuby, maybe some others) where 
the native extensions don't load correctly and the thrift gem falls back to the 
native implementations.
  
> rb_thrift_memory_buffer_write treats arg as string without check, segfaults 
> if you pass non-string
> --
>
> Key: THRIFT-1047
> URL: https://issues.apache.org/jira/browse/THRIFT-1047
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.5
>Reporter: Jake Donham
>
> I think there should be a call to Check_Type(str, T_STRING) in there
> VALUE rb_thrift_memory_buffer_write(VALUE self, VALUE str) {
>   VALUE buf = GET_BUF(self);
>   rb_str_buf_cat(buf, RSTRING_PTR(str), RSTRING_LEN(str));
>   return Qnil;
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1047) rb_thrift_memory_buffer_write treats arg as string without check, segfaults if you pass non-string

[Ilya Maykov (JIRA)]

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

Ilya Maykov commented on THRIFT-1047:
-

Jake - can you also add the type check to the pure-Ruby implementation of 
MemoryBufferTransport (in lib/rb/thrift/transport/memory_buffer_transport.rb)? 
Otherwise, the native and non-native implementations will behave differently. 
This is relevant for non-MRI Ruby interpreters (JRuby, maybe some others) where 
the native extensions don't load correctly and the thrift gem falls back to the 
native implementations.

> rb_thrift_memory_buffer_write treats arg as string without check, segfaults 
> if you pass non-string
> --
>
> Key: THRIFT-1047
> URL: https://issues.apache.org/jira/browse/THRIFT-1047
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.5
>Reporter: Jake Donham
>
> I think there should be a call to Check_Type(str, T_STRING) in there
> VALUE rb_thrift_memory_buffer_write(VALUE self, VALUE str) {
>   VALUE buf = GET_BUF(self);
>   rb_str_buf_cat(buf, RSTRING_PTR(str), RSTRING_LEN(str));
>   return Qnil;
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1201) getaddrinfo resource leak

[Craig Robson (JIRA)]

getaddrinfo resource leak
-

 Key: THRIFT-1201
 URL: https://issues.apache.org/jira/browse/THRIFT-1201
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
Affects Versions: 0.6.1
Reporter: Craig Robson
Priority: Minor


TServerSocket::listen() calls getaddrinfo().  There are several ways exceptions 
can happen before freeaddrinfo() is called thus leaking the getaddrinfo result.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1200) JS compiler generates code that clobbers existing namespaces

[Ilya Maykov (JIRA)]

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

Ilya Maykov updated THRIFT-1200:


Attachment: THRIFT-1200-js-namespace-fix.txt

Attaching patch against trunk as of 2011-06-08 (rev 1133549).

> JS compiler generates code that clobbers existing namespaces
> 
>
> Key: THRIFT-1200
> URL: https://issues.apache.org/jira/browse/THRIFT-1200
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler
>Affects Versions: 0.6.1
> Environment: all
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Attachments: THRIFT-1200-js-namespace-fix.txt
>
>
> The JavaScript compiler currently generates code that will clobber an 
> already-existing namespace. It should check if the namespace exists before 
> initializing it to {}. Example code pre-patch, assuming the .thrift file has 
> the declaration {{namespace js CompanyName.ModuleName}}:
> {code:JavaScript}
> var CompanyName = {};
> CompanyName.ModuleName = {}
> {code}
> Becomes this after patch:
> {code:JavaScript}
> if (typeof CompanyName === 'undefined') CompanyName = {};
> if (typeof CompanyName.ModuleName === 'undefined') CompanyName.ModuleName = 
> {};
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1200) JS compiler generates code that clobbers existing namespaces

[Ilya Maykov (JIRA)]

JS compiler generates code that clobbers existing namespaces


 Key: THRIFT-1200
 URL: https://issues.apache.org/jira/browse/THRIFT-1200
 Project: Thrift
  Issue Type: Bug
  Components: JavaScript - Compiler
Affects Versions: 0.6.1
 Environment: all
Reporter: Ilya Maykov
Assignee: Ilya Maykov


The JavaScript compiler currently generates code that will clobber an 
already-existing namespace. It should check if the namespace exists before 
initializing it to {}. Example code pre-patch, assuming the .thrift file has 
the declaration {{namespace js CompanyName.ModuleName}}:

{code:JavaScript}
var CompanyName = {};
CompanyName.ModuleName = {}
{code}

Becomes this after patch:

{code:JavaScript}
if (typeof CompanyName === 'undefined') CompanyName = {};
if (typeof CompanyName.ModuleName === 'undefined') CompanyName.ModuleName = {};
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1199) Union structs should have generated methods to test whether a specific field is currently set

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury closed THRIFT-1199.
-

   Resolution: Fixed
Fix Version/s: 0.7

I just committed this. Thanks for the patch!

> Union structs should have generated methods to test whether a specific field 
> is currently set 
> --
>
> Key: THRIFT-1199
> URL: https://issues.apache.org/jira/browse/THRIFT-1199
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Compiler
>Reporter: Piotr Kozikowski
>Assignee: Piotr Kozikowski
>Priority: Trivial
> Fix For: 0.7
>
> Attachments: thrift-1199.patch
>
>
> For example, in the following union 
> {code}
> union MyUnion {
>   1: string my_field1;
>   2: string my_field2;
> }
> {code}
> it would be nice to be able to do something like {{boolean test = 
> myUnion.is_my_field1;}} as an alternative to {{boolean test = 
> (myUnion.getSetField() == _Fields.MY_FIELD1);}}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Optional Struct Members in Go-Thrift Compiler

[Bryan Duxbury]

In the Java library, we added extra "is set" flags for fields that could not
be nulled out but could be not set.

On Wed, Jun 8, 2011 at 10:38 AM, Trevor Smith  wrote:

> Hello,
>
> The current Go compiler implementation in Thrift does not deal
> correctly with optional struct values. This, for example, makes
> compiling the Cassandra Thrift interface unusable, because it sends
> along optional string values as zero length strings, when it should in
> fact be skipping the field altogether.
>
> I am working on a patch to fix this. For many Go datatypes this is
> straight forward (ie types that can be represented as nil in Go).
> However, it is not clear to me how to generate Go code that does the
> optional check for string and integer types -- specifically to allow a
> string zero length string or an integer of value 0 in an optional
> field, versus the non inclusion of those values. This is because Go
> sets integer and string types to 0 and "", respectively, as their
> default values.
>
> Literally, I do not know how to:
>
> // Create the code to make a decision as to include or not include a
> struct field in
> // t_go_compiler.cc: generate_go_struct_writer
> if (item->get_req() == t_field::T_OPTIONAL && /* type is int and zero,
> what to do? */( {
> }
>
> Any suggestions would be appreciated.
>
> Thank you.
>
> Trevor Smith
>

Optional Struct Members in Go-Thrift Compiler

[Trevor Smith]

Hello,

The current Go compiler implementation in Thrift does not deal
correctly with optional struct values. This, for example, makes
compiling the Cassandra Thrift interface unusable, because it sends
along optional string values as zero length strings, when it should in
fact be skipping the field altogether.

I am working on a patch to fix this. For many Go datatypes this is
straight forward (ie types that can be represented as nil in Go).
However, it is not clear to me how to generate Go code that does the
optional check for string and integer types -- specifically to allow a
string zero length string or an integer of value 0 in an optional
field, versus the non inclusion of those values. This is because Go
sets integer and string types to 0 and "", respectively, as their
default values.

Literally, I do not know how to:

// Create the code to make a decision as to include or not include a
struct field in
// t_go_compiler.cc: generate_go_struct_writer
if (item->get_req() == t_field::T_OPTIONAL && /* type is int and zero,
what to do? */( {
}

Any suggestions would be appreciated.

Thank you.

Trevor Smith

[jira] [Commented] (THRIFT-633) Generated code has @Override annotations which won't compile using Apple's JDK 1.5

[Jake Farrell (JIRA)]

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

Jake Farrell commented on THRIFT-633:
-

Toby, have you tried reproducing this against the trunk? THRIFT-1170 should 
have take care of this with the new java5 option. 

> Generated code has @Override annotations which won't compile using Apple's 
> JDK 1.5
> --
>
> Key: THRIFT-633
> URL: https://issues.apache.org/jira/browse/THRIFT-633
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
> Environment: Mac OS X Tiger/Leopard JDK 1.5
>Reporter: Mathias Herberts
>
> Apple's JDK 1.5 does not recognize @Override annotation. Tests fail with 
> error:
> [javac] 
> /private/var/tmp/thrift-trunk/lib/java/gen-java/thrift/test/ComparableUnion.java:251:
>  method does not override a method from its superclass
> [javac]   @Override
> [javac]^

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1177) Update thrift to reflect changes in Go's networking libraries

[Trevor Summers Smith (JIRA)]

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

Trevor Summers Smith updated THRIFT-1177:
-

Attachment: gopatch2-r2.diff

The first patch submitted has one bug that prevents the Cassandra thrift file 
from compiling (http.Get now returns three values and was returning two). I 
have attached the full patch with this bug fixed.

I used: 6g version release.r57.1 8294 and compiled the Cassandra-0.8.0 Thrift 
file successfully, and tested some of its basic functionality.

I did not do an in-depth review of all changes in this patch, because I am not 
yet familiar enough with the codebase.

> Update thrift to reflect changes in Go's networking libraries
> -
>
> Key: THRIFT-1177
> URL: https://issues.apache.org/jira/browse/THRIFT-1177
> Project: Thrift
>  Issue Type: Dependency upgrade
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.7
>Reporter: Aalok Shah
>Priority: Minor
> Fix For: 0.7
>
> Attachments: gopatch2-r2.diff, gopatch2.diff
>
>
> Go updated its networking libraries requiring a change to both the thrift 
> code generator and the libraries.
> Additionally, the Go generator did not support arguments/variables that were 
> Go keywords, this needs to be updated to work with Cassandra's thrift since 
> "range" is a Go keyword.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira