[jira] [Updated] (THRIFT-1261) STDIO support for node-thrift

[Jordan Shaw (JIRA)]

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

Jordan Shaw updated THRIFT-1261:


Description: 
This bit of code adds support to send thrift messages over STDIO to and from a 
node process. This comes in handy when running a PHP server. PHP tends to use 
an exorbitant amount of resources when running as a daemon so it's a better 
solution to spawn a process, pipe the messages over STDIO, listen for the 
response on STDOUT and then close the process. This also solves the problem of 
running a server that isn't inherently multi-threaded(again php as an example).


  was:This bit of code adds support to send thrift messages over STDIO to and 
from a node process. This comes in handy when running a PHP server. PHP tends 
to use an exorbitant amount of resources when running as a daemon so it's a 
better solution to spawn a process, pipe the messages over STDIO, listen for 
the response on STDOUT and then close the process. This also solves the problem 
of running a server that isn't inherently multi-threaded(again php as an 
example).


I can't find the upload patch button so here is the github pull request 
https://github.com/wadey/node-thrift/pull/11.

> STDIO support for node-thrift
> -
>
> Key: THRIFT-1261
> URL: https://issues.apache.org/jira/browse/THRIFT-1261
> Project: Thrift
>  Issue Type: New Feature
>  Components: Node.js - Library
>Reporter: Jordan Shaw
>Priority: Minor
>
> This bit of code adds support to send thrift messages over STDIO to and from 
> a node process. This comes in handy when running a PHP server. PHP tends to 
> use an exorbitant amount of resources when running as a daemon so it's a 
> better solution to spawn a process, pipe the messages over STDIO, listen for 
> the response on STDOUT and then close the process. This also solves the 
> problem of running a server that isn't inherently multi-threaded(again php as 
> an example).

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

[jira] [Created] (THRIFT-1261) STDIO support for node-thrift

[Jordan Shaw (JIRA)]

STDIO support for node-thrift
-

 Key: THRIFT-1261
 URL: https://issues.apache.org/jira/browse/THRIFT-1261
 Project: Thrift
  Issue Type: New Feature
  Components: Node.js - Library
Reporter: Jordan Shaw
Priority: Minor


This bit of code adds support to send thrift messages over STDIO to and from a 
node process. This comes in handy when running a PHP server. PHP tends to use 
an exorbitant amount of resources when running as a daemon so it's a better 
solution to spawn a process, pipe the messages over STDIO, listen for the 
response on STDOUT and then close the process. This also solves the problem of 
running a server that isn't inherently multi-threaded(again php as an example).

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

[jira] [Closed] (THRIFT-1252) Segfault in Ruby deserializer

[Jake Farrell (JIRA)]

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

Jake Farrell closed THRIFT-1252.



> Segfault in Ruby deserializer
> -
>
> Key: THRIFT-1252
> URL: https://issues.apache.org/jira/browse/THRIFT-1252
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7
> Environment: Thrift 0.7.0dev (revision 1152979)
> Ruby 1.9.2
> OS X 10.6, Linux x86_64
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Fix For: 0.7
>
> Attachments: THRIFT-1252.patch
>
>
> There is a segfault bug in the native Ruby deserializer that was introduced 
> with THRIFT-1189. The @index variable of MemoryBufferTransport is not always 
> correctly updated from native code when GARBAGE_BUFFER_SIZE is exceeded.
> Will attach the patch shortly.

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

[jira] [Updated] (THRIFT-1252) Segfault in Ruby deserializer

[Jake Farrell (JIRA)]

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

Jake Farrell updated THRIFT-1252:
-

Fix Version/s: 0.7

> Segfault in Ruby deserializer
> -
>
> Key: THRIFT-1252
> URL: https://issues.apache.org/jira/browse/THRIFT-1252
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7
> Environment: Thrift 0.7.0dev (revision 1152979)
> Ruby 1.9.2
> OS X 10.6, Linux x86_64
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Fix For: 0.7
>
> Attachments: THRIFT-1252.patch
>
>
> There is a segfault bug in the native Ruby deserializer that was introduced 
> with THRIFT-1189. The @index variable of MemoryBufferTransport is not always 
> correctly updated from native code when GARBAGE_BUFFER_SIZE is exceeded.
> Will attach the patch shortly.

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

Re: [VOTE] Release Apache Thrift 0.7.0

[Ilya Maykov]

Ruby compiler and libraries look good and pass all tests.

+1

-- Ilya


On Thu, Aug 11, 2011 at 11:48 AM, Bryan Duxbury  wrote:

> I was able to resolve my GPG issues and verified that the compiler and Java
> tests run as expected.
>
> +1
>
> On Wed, Aug 10, 2011 at 3:08 PM, Jake Farrell  wrote:
>
> > All,
> >
> > I propose that we accept
> > http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz
> > as the official Thrift 0.7.0 release.
> >
> > I generated this tarball by checking out
> > https://svn.apache.org/repos/asf/thrift/branches/0.7.x and running
> > "./bootstrap.sh && ./configure && make dist".
> >
> > The GPG signature can be found at:
> >
> http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz.asc
> > .
> > It has an MD5 sum of 8d7a0070a223e59cf6a2d72aa013b3c4.
> >
> > The java library can be found at:
> > https://repository.apache.org/content/repositories/orgapachethrift-025/
> > libthrift-0.7.0.jar has an MD5 sum of 9d82be1cd2f75a6218ff4a4fb1d91015.
> >
> > The CHANGES list for this release if available at:
> > http://svn.apache.org/repos/asf/thrift/branches/0.7.x/CHANGES
> >
> > Please download, verify sig/sum, and install/test the libraries of your
> > choice.
> >
> > This vote closes in 72 hours.
> >
> > -Jake
> >
>

[jira] [Commented] (THRIFT-1205) port server unduly fragile with arbitrary input

[Hudson (JIRA)]

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

Hudson commented on THRIFT-1205:


Integrated in Thrift #218 (See [https://builds.apache.org/job/Thrift/218/])
THRIFT-1205. java: port server unduly fragile with arbitrary input

Increase the default max frame size to 16MB.

Patch: Ryan King

bryanduxbury : http://svn.apache.org/viewvc/?view=rev&rev=1156731
Files : 
* /thrift/trunk/lib/java/src/org/apache/thrift/transport/TFramedTransport.java
* 
/thrift/trunk/lib/java/src/org/apache/thrift/transport/TFastFramedTransport.java


> port server unduly fragile with arbitrary input
> ---
>
> Key: THRIFT-1205
> URL: https://issues.apache.org/jira/browse/THRIFT-1205
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.6.1
> Environment: javac 1.5.0_19, OS X 10.4.11
>Reporter: Toby Thain
>Assignee: Ryan King
>Priority: Critical
>  Labels: security
> Fix For: 0.8
>
> Attachments: 
> 0001-THRIFT-1205-reduce-the-default-frame-size-to-16MB.patch
>
>
> Telnetting to the port and type a couple of arbitrary characters crashes the 
> server almost immediately as follows. I haven't glanced at the relevant code. 
> Is this reproducible on other platforms?
> {noformat}
> $ ./run-server.sh 
> Starting the simple server...
> Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readStringBody(TBinaryProtocol.java:353)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:215)
> at SimonSays$Processor.process(Unknown Source)
> at org.apache.thrift.server.TSimpleServer.serve(TSimpleServer.java:70)
> at JavaServer.simple(Unknown Source)
> at JavaServer$1.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:613)
> {noformat}

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

[jira] [Commented] (THRIFT-1239) TupleProtocol- An extremely compact, temporary protocol

[Hudson (JIRA)]

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

Hudson commented on THRIFT-1239:


Integrated in Thrift #218 (See [https://builds.apache.org/job/Thrift/218/])
THRIFT-169. java: Pluggable Serializers
THRIFT-1239. java: TupleProtocol- An extremely compact, temporary protocol

This monster commit is the combination of the two above tickets, providing a 
new serialization framework and the first new consumer in one go.

Patch: Armaan Sarkar

bryanduxbury : http://svn.apache.org/viewvc/?view=rev&rev=1156728
Files : 
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/StandardScheme.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/IScheme.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/TupleScheme.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme
* /thrift/trunk/lib/java/test/org/apache/thrift/protocol/TestTTupleProtocol.java
* /thrift/trunk/compiler/cpp/src/generate/t_java_generator.cc
* /thrift/trunk/lib/java/src/org/apache/thrift/protocol/TTupleProtocol.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/SchemeFactory.java
* /thrift/trunk/lib/java/test/org/apache/thrift/Fixtures.java
* /thrift/trunk/lib/java/src/org/apache/thrift/protocol/TCompactProtocol.java
* /thrift/trunk/lib/java/src/org/apache/thrift/protocol/TProtocol.java


> TupleProtocol- An extremely compact, temporary protocol
> ---
>
> Key: THRIFT-1239
> URL: https://issues.apache.org/jira/browse/THRIFT-1239
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Armaan Sarkar
>Assignee: Armaan Sarkar
>Priority: Minor
> Fix For: 0.8
>
> Attachments: pluggable_serializer_master.patch, thrift-1239-v2.patch, 
> thrift-1239-v3.patch, thrift-1239-v4.patch, tuple_generator.patch, 
> tuple_protocol.patch
>
>
> Currently, protocols are built to be pretty robust to 'schema' changes. This 
> is done by sending metadata about when a struct or a field will start/end, 
> the number of fields to expect and the types of each field, etc. However, 
> there are cases when the recipient knows all of this, even before it receives 
> this metadata. In these cases, sending the metadata unnecessarily eats up 
> bandwidth. The TupleProtocol rectifies this by sending and receiving only the 
> value of each field in a specified order. The only metadata passed is about 
> variable information such as the size of a container or which optional fields 
> are set.

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

[jira] [Commented] (THRIFT-169) Buffered transports leave data in write buffer on failed flush

[Hudson (JIRA)]

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

Hudson commented on THRIFT-169:
---

Integrated in Thrift #218 (See [https://builds.apache.org/job/Thrift/218/])
THRIFT-169. java: Pluggable Serializers
THRIFT-1239. java: TupleProtocol- An extremely compact, temporary protocol

This monster commit is the combination of the two above tickets, providing a 
new serialization framework and the first new consumer in one go.

Patch: Armaan Sarkar

bryanduxbury : http://svn.apache.org/viewvc/?view=rev&rev=1156728
Files : 
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/StandardScheme.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/IScheme.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/TupleScheme.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme
* /thrift/trunk/lib/java/test/org/apache/thrift/protocol/TestTTupleProtocol.java
* /thrift/trunk/compiler/cpp/src/generate/t_java_generator.cc
* /thrift/trunk/lib/java/src/org/apache/thrift/protocol/TTupleProtocol.java
* /thrift/trunk/lib/java/src/org/apache/thrift/scheme/SchemeFactory.java
* /thrift/trunk/lib/java/test/org/apache/thrift/Fixtures.java
* /thrift/trunk/lib/java/src/org/apache/thrift/protocol/TCompactProtocol.java
* /thrift/trunk/lib/java/src/org/apache/thrift/protocol/TProtocol.java


> Buffered transports leave data in write buffer on failed flush
> --
>
> Key: THRIFT-169
> URL: https://issues.apache.org/jira/browse/THRIFT-169
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Reporter: Erik Frey
>Assignee: Mark Slee
>Priority: Minor
> Attachments: buffered_flush_fix_php.patch
>
>
> When TBuffered/TFramedTransport's underlying transport fails during a 
> flush(), the transport enters an irrecoverable state with unflushed data in 
> its write buffer.

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

Build failed in Jenkins: Thrift-cpp #120

[Apache Jenkins Server]

See 

Changes:

[jfarrell] Removing duplicate java client properties seen during release process

[bryanduxbury] THRIFT-1205. java: port server unduly fragile with arbitrary 
input

Increase the default max frame size to 16MB.

Patch: Ryan King

[bryanduxbury] THRIFT-169. java: Pluggable Serializers
THRIFT-1239. java: TupleProtocol- An extremely compact, temporary protocol

This monster commit is the combination of the two above tickets, providing a 
new serialization framework and the first new consumer in one go.

Patch: Armaan Sarkar

--
[...truncated 116 lines...]
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether make sets $(MAKE)... (cached) yes
checking for bison... bison -y
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking whether ln -s works... yes
checking for gawk... (cached) mawk
checking for ranlib... (cached) ranlib
checking for boostlib >= 1.33.1... yes
checking for libevent >= 1.0... yes
checking for zlib >= 1.2.3... yes
checking for trial... /usr/bin/trial
checking for 6g... /usr/local/bin/6g
checking for 6l... /usr/local/bin/6l
checking for gomake... /usr/local/bin/gomake
checking for goinstall... /usr/local/bin/goinstall
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for working volatile... yes
checking for stdbool.h that conforms to C99... no
checking for _Bool... no
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking return type of signal handlers... void
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for inttypes.h... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking openssl/rand.h usability... yes
checking openssl/rand.h presence... yes
checking for openssl/rand.h... yes
checking openssl/x509v3.h usability... yes
checking openssl/x509v3.h presence... yes
checking for openssl/x509v3.h... yes
checking for pthread_create in -lpthread... yes
checking for clock_gettime in -lrt... yes
checking for setsockopt in -lsocket... no
checking for SSL_ctrl in -lssl... yes
checking for int16_t... yes
checking for int32_t... yes
checking for int64_t... yes
checking for int8_t... yes
checking for mode_t... yes
checking for off_t... yes
checking for size_t... yes
checking for ssize_t... yes
checking for uint16_t... yes
checking for uint32_t... yes
checking for uint64_t... yes
checking for uint8_t... yes
checking for ptrdiff_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking whether AI_ADDRCONFIG is declared... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for pid_t... yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for working memcmp... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for sys/socket.h... (cached) yes
checking types of arguments for select... int,f

[jira] [Closed] (THRIFT-1205) port server unduly fragile with arbitrary input

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury closed THRIFT-1205.
-

   Resolution: Fixed
Fix Version/s: 0.8

I just committed this. Thanks for the patch.

> port server unduly fragile with arbitrary input
> ---
>
> Key: THRIFT-1205
> URL: https://issues.apache.org/jira/browse/THRIFT-1205
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.6.1
> Environment: javac 1.5.0_19, OS X 10.4.11
>Reporter: Toby Thain
>Assignee: Ryan King
>Priority: Critical
>  Labels: security
> Fix For: 0.8
>
> Attachments: 
> 0001-THRIFT-1205-reduce-the-default-frame-size-to-16MB.patch
>
>
> Telnetting to the port and type a couple of arbitrary characters crashes the 
> server almost immediately as follows. I haven't glanced at the relevant code. 
> Is this reproducible on other platforms?
> {noformat}
> $ ./run-server.sh 
> Starting the simple server...
> Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readStringBody(TBinaryProtocol.java:353)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:215)
> at SimonSays$Processor.process(Unknown Source)
> at org.apache.thrift.server.TSimpleServer.serve(TSimpleServer.java:70)
> at JavaServer.simple(Unknown Source)
> at JavaServer$1.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:613)
> {noformat}

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

[jira] [Resolved] (THRIFT-769) Pluggable Serializers

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury resolved THRIFT-769.
--

   Resolution: Fixed
Fix Version/s: 0.8
 Assignee: Armaan Sarkar  (was: Bryan Duxbury)

Committed as part of THRIFT-1239

> Pluggable Serializers
> -
>
> Key: THRIFT-769
> URL: https://issues.apache.org/jira/browse/THRIFT-769
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler, Java - Library
>Reporter: Bryan Duxbury
>Assignee: Armaan Sarkar
>  Labels: gsoc2011, mentor
> Fix For: 0.8
>
> Attachments: pluggable_serializer.patch, thrift_scheme.patch, 
> thrift_scheme_update1.patch
>
>
> Thrift is already designed to have modular Protocols, which define the 
> various elements of binary encoding. However, the way that our code is 
> generated, we're also implicitly defining every protocol to have a 
> *structure* like that of the Binary protocol. 
> This has served us well so far with it's simplicity, and other protocols 
> (like Compact and JSON) have been able to squeeze into this model 
> successfully, though at a noticeable cost. For instance, Compact protocol has 
> to keep its own internal state in a stack to know what the last field id we 
> wrote was so that it can write compact deltas. The JSON protocol is even more 
> complex, keeping a truly monstrous amount of state around in order to be able 
> to do the right thing at the right time. All this state tracking comes with 
> cost, both in complexity and in actual runtime.
> I think that there's a solution to this problem - making the serialization 
> code itself pluggable. That is, rather than there being a single "write" and 
> "read" method for every protocol, we could let Protocols require a certain 
> kind of Serializer to interact with them. Binary protocol could use the 
> "default tagged" serializer, which would look like what we have today. JSON 
> would probably use a custom one that basically let it write out strings and 
> nothing else. Compact would also likely use a custom serializer that kept all 
> the needed state on the system stack, rather than in a user-code stack. Dare 
> I say it, but it's possible that if we did it right, we could even serialize 
> Thrift structs with Avro's serialization format!
> The upshot of this change would be to make many protocols faster and simpler, 
> while also allowing us to implement a broader set of protocols that don't fit 
> with the traditional Thrift-style protocols.

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

[jira] [Closed] (THRIFT-1239) TupleProtocol- An extremely compact, temporary protocol

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury closed THRIFT-1239.
-

   Resolution: Fixed
Fix Version/s: 0.8
 Assignee: Armaan Sarkar

I just committed this with the minor change that the schemes map is now static. 
This is fantastic stuff - thanks Armaan!

> TupleProtocol- An extremely compact, temporary protocol
> ---
>
> Key: THRIFT-1239
> URL: https://issues.apache.org/jira/browse/THRIFT-1239
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Armaan Sarkar
>Assignee: Armaan Sarkar
>Priority: Minor
> Fix For: 0.8
>
> Attachments: pluggable_serializer_master.patch, thrift-1239-v2.patch, 
> thrift-1239-v3.patch, thrift-1239-v4.patch, tuple_generator.patch, 
> tuple_protocol.patch
>
>
> Currently, protocols are built to be pretty robust to 'schema' changes. This 
> is done by sending metadata about when a struct or a field will start/end, 
> the number of fields to expect and the types of each field, etc. However, 
> there are cases when the recipient knows all of this, even before it receives 
> this metadata. In these cases, sending the metadata unnecessarily eats up 
> bandwidth. The TupleProtocol rectifies this by sending and receiving only the 
> value of each field in a specified order. The only metadata passed is about 
> variable information such as the size of a container or which optional fields 
> are set.

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

Re: [VOTE] Release Apache Thrift 0.7.0

[Bryan Duxbury]

I was able to resolve my GPG issues and verified that the compiler and Java
tests run as expected.

+1

On Wed, Aug 10, 2011 at 3:08 PM, Jake Farrell  wrote:

> All,
>
> I propose that we accept
> http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz
> as the official Thrift 0.7.0 release.
>
> I generated this tarball by checking out
> https://svn.apache.org/repos/asf/thrift/branches/0.7.x and running
> "./bootstrap.sh && ./configure && make dist".
>
> The GPG signature can be found at:
> http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz.asc
> .
> It has an MD5 sum of 8d7a0070a223e59cf6a2d72aa013b3c4.
>
> The java library can be found at:
> https://repository.apache.org/content/repositories/orgapachethrift-025/
> libthrift-0.7.0.jar has an MD5 sum of 9d82be1cd2f75a6218ff4a4fb1d91015.
>
> The CHANGES list for this release if available at:
> http://svn.apache.org/repos/asf/thrift/branches/0.7.x/CHANGES
>
> Please download, verify sig/sum, and install/test the libraries of your
> choice.
>
> This vote closes in 72 hours.
>
> -Jake
>

[jira] [Updated] (THRIFT-1239) TupleProtocol- An extremely compact, temporary protocol

[Armaan Sarkar (JIRA)]

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

Armaan Sarkar updated THRIFT-1239:
--

Attachment: thrift-1239-v4.patch

I left out some java files in the last patch. This includes all files.

> TupleProtocol- An extremely compact, temporary protocol
> ---
>
> Key: THRIFT-1239
> URL: https://issues.apache.org/jira/browse/THRIFT-1239
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Armaan Sarkar
>Priority: Minor
> Attachments: pluggable_serializer_master.patch, thrift-1239-v2.patch, 
> thrift-1239-v3.patch, thrift-1239-v4.patch, tuple_generator.patch, 
> tuple_protocol.patch
>
>
> Currently, protocols are built to be pretty robust to 'schema' changes. This 
> is done by sending metadata about when a struct or a field will start/end, 
> the number of fields to expect and the types of each field, etc. However, 
> there are cases when the recipient knows all of this, even before it receives 
> this metadata. In these cases, sending the metadata unnecessarily eats up 
> bandwidth. The TupleProtocol rectifies this by sending and receiving only the 
> value of each field in a specified order. The only metadata passed is about 
> variable information such as the size of a container or which optional fields 
> are set.

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

[jira] [Created] (THRIFT-1260) The thrift THttpclient in c# client is not closing the connections when calling SendRequest

[guy manella (JIRA)]

The thrift THttpclient in c# client is not closing the connections when calling 
SendRequest
---

 Key: THRIFT-1260
 URL: https://issues.apache.org/jira/browse/THRIFT-1260
 Project: Thrift
  Issue Type: Bug
  Components: C# - Library
Affects Versions: 0.7
Reporter: guy manella
Priority: Minor
 Fix For: 0.7


When calling the server more than 16000 times, an exception is being thrown - 
"An operation on a socket could not be performed because the system lacked 
sufficient buffer space or because a queue was full" its because the stream is 
not being closed.

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

Re: AW: [VOTE] Release Apache Thrift 0.7.0

[Jake Farrell]

I thought we had taken care of that in 6.1, i'll go ahead and give myself a 
ticket to automate this process. I've updated the versions and placed the 
rc0+versions back up on my site. Thanks everyone for helping test and get this 
out.

-Jake


On Aug 10, 2011, at 6:48 PM, Roger Meier wrote:

> Thanks Jake for preparing the release!
> 
> I have just one open issue... the version info
> Many files contain version information and they have to be updated manually 
> See http://wiki.apache.org/thrift/HowToVersion
> 
> We can probably  add a build.xml to update that version info and cross
> language unit tests.
> 
> -Roger
> 
>> -Ursprüngliche Nachricht-
>> Von: Jake Farrell [mailto:jfarr...@apache.org]
>> Gesendet: Donnerstag, 11. August 2011 00:09
>> An: dev@thrift.apache.org
>> Betreff: [VOTE] Release Apache Thrift 0.7.0
>> 
>> All,
>> 
>> I propose that we accept
>> http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz
>> as the official Thrift 0.7.0 release.
>> 
>> I generated this tarball by checking out
>> https://svn.apache.org/repos/asf/thrift/branches/0.7.x and running
>> "./bootstrap.sh && ./configure && make dist".
>> 
>> The GPG signature can be found at:
>> 
> http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz.asc.
>> It has an MD5 sum of 8d7a0070a223e59cf6a2d72aa013b3c4.
>> 
>> The java library can be found at:
>> https://repository.apache.org/content/repositories/orgapachethrift-025/
>> libthrift-0.7.0.jar has an MD5 sum of 9d82be1cd2f75a6218ff4a4fb1d91015.
>> 
>> The CHANGES list for this release if available at:
>> http://svn.apache.org/repos/asf/thrift/branches/0.7.x/CHANGES
>> 
>> Please download, verify sig/sum, and install/test the libraries of your
> choice.
>> 
>> This vote closes in 72 hours.
>> 
>> -Jake
>> 
> 
> 

[jira] [Created] (THRIFT-1259) Automate versioning

[Jake Farrell (JIRA)]

Automate versioning 


 Key: THRIFT-1259
 URL: https://issues.apache.org/jira/browse/THRIFT-1259
 Project: Thrift
  Issue Type: Task
  Components: Build Process
Affects Versions: 0.7
Reporter: Jake Farrell
Assignee: Jake Farrell


Only a manual process exists for updating the versions for a release. Need to 
automate this to make generating releases easier. 

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

[jira] [Assigned] (THRIFT-274) Towards a working release/versioning process

[Jake Farrell (JIRA)]

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

Jake Farrell reassigned THRIFT-274:
---

Assignee: Jake Farrell

Agree with Roger on this, Major.Minor.Patch with optional -snapshot or -dev to 
describe non-released versions.

> Towards a working release/versioning process
> 
>
> Key: THRIFT-274
> URL: https://issues.apache.org/jira/browse/THRIFT-274
> Project: Thrift
>  Issue Type: Bug
>Reporter: Luke Lu
>Assignee: Jake Farrell
>
> The current thrift version is virtually useless because it's not getting 
> updated when backward compatibility is broken (it's always 20080411-exported 
> on all the snapshots,) I can't just tell people to use the trunk and not 
> breaking things due things like namespace changes etc. Many projects maintain 
> a reasonable versioning scheme even when system is in alpha state.
> Thrift overall is stable enough to warrant a working versioning scheme. Can 
> we at least start to discuss a version scheme, e.g., major.minor.patch or 
> major.minor.micro.patch, where patch number changes are bug fixes and minor 
> or micro are backward compatible changes and major changes indicate breaking 
> backward compatibility or just marketing hype.
> I propose that we call the current thrift version 1.0.0.0 after all the 
> namespace changes and stick to a reasonable scheme instead of using suffixes 
> (like beta/rc etc.) as it's much friendlier to other components that 
> uses thrift.

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

Re: AW: [VOTE] Release Apache Thrift 0.7.0

[Jake Farrell]

I thought we had taken care of that in 6.1, i'll go ahead and give myself a 
ticket to automate this process. I've updated the versions and placed the 
rc0+versions back up on my site. Thanks everyone for helping test and get this 
out.

-Jake


On Aug 10, 2011, at 6:48 PM, Roger Meier wrote:

> Thanks Jake for preparing the release!
> 
> I have just one open issue... the version info
> Many files contain version information and they have to be updated manually 
> See http://wiki.apache.org/thrift/HowToVersion
> 
> We can probably  add a build.xml to update that version info and cross
> language unit tests.
> 
> -Roger
> 
>> -Ursprüngliche Nachricht-
>> Von: Jake Farrell [mailto:jfarr...@apache.org]
>> Gesendet: Donnerstag, 11. August 2011 00:09
>> An: dev@thrift.apache.org
>> Betreff: [VOTE] Release Apache Thrift 0.7.0
>> 
>> All,
>> 
>> I propose that we accept
>> http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz
>> as the official Thrift 0.7.0 release.
>> 
>> I generated this tarball by checking out
>> https://svn.apache.org/repos/asf/thrift/branches/0.7.x and running
>> "./bootstrap.sh && ./configure && make dist".
>> 
>> The GPG signature can be found at:
>> 
> http://people.apache.org/~jfarrell/thrift/0.7.0/thrift-0.7.0-rc0.tar.gz.asc.
>> It has an MD5 sum of 8d7a0070a223e59cf6a2d72aa013b3c4.
>> 
>> The java library can be found at:
>> https://repository.apache.org/content/repositories/orgapachethrift-025/
>> libthrift-0.7.0.jar has an MD5 sum of 9d82be1cd2f75a6218ff4a4fb1d91015.
>> 
>> The CHANGES list for this release if available at:
>> http://svn.apache.org/repos/asf/thrift/branches/0.7.x/CHANGES
>> 
>> Please download, verify sig/sum, and install/test the libraries of your
> choice.
>> 
>> This vote closes in 72 hours.
>> 
>> -Jake
>> 
> 
>