[GitHub] thrift issue #1382: THRIFT-4285 Move TX/RX methods from gen. code to library
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1382 ping @jeking3 ---
TException and cross-tests
Hi, We're working on Common Lisp support for Thrift. I've run into a little issue while implementing cross-tests - namely this bit: /** * Print 'testException(%s)' with arg as '%s' * @param string arg - a string indication what type of exception to throw * if arg == "Xception" throw Xception with errorCode = 1001 and message = arg * elsen if arg == "TException" throw TException * else do not throw anything */ void testException(1: string arg) throws(1: Xception err1), Is there some specification on how TException is supposed to work? I understand it is a parent of any exception type defined by the user in the IDL file, but I thought that would be purely an implementation detail of specific languages so that they can make clauses that catch all user-defined errors they receive via Thrift. But apparently, it should be possible to send it explicitly via the protocol, without it being defined in the IDL? Or maybe it's meant to test the TApplicationException, as defined here: https://erikvanoosten.github.io/thrift-missing-specification/#_response_struct ? Supposed to be sent not like a user-defined exception (message type Reply), but with a message of type Exception?
[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198288#comment-16198288 ] ASF GitHub Bot commented on THRIFT-4285: Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1382 ping @jeking3 > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch, > 0001-go-pull-generated-send-recv-into-lib-v7.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4119) bootstrap.sh is missing from the source tarball
[ https://issues.apache.org/jira/browse/THRIFT-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198462#comment-16198462 ] Robert Lu commented on THRIFT-4119: --- [~ctubbsii] Well, I agree with you. [~jfarrell] Talk about the release directory structure, I think we can improve it: # the tar.gz download should be repo snapshot. # http://www.apache.org/dist/thrift/debian/ and http://www.apache.org/dist/thrift/rpm/ should contain the thrift and thrift-compiler package, and update in time. the rpm and deb repo is still version 0.9.3. > bootstrap.sh is missing from the source tarball > --- > > Key: THRIFT-4119 > URL: https://issues.apache.org/jira/browse/THRIFT-4119 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.10.0 >Reporter: Christopher Tubbs >Assignee: Jake Farrell >Priority: Critical > > The bootstrap.sh file is missing from the source tarball. This makes building > from source difficult. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1382: THRIFT-4285 Move TX/RX methods from gen. code to library
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1382
Is there a way you can provide a generated NewFooClientFactory as an
adapter to run the new code? i.e. (sorry this isn't go, but you get the idea):
mypkg.NewFooClientFactory(transport, protocolFactory) { return
mypkg.NewFooClient(thrift.NewTStandardClient(protocolFactory.GetProtocol(transport)));
}
This would make it backwards compatible for everyone and you wouldn't need
to change any of the test files, I believe? This would be better overall for
the project to maintain backwards compatibility. Let me know what you think.
I was away for a couple days on college tours with my son, sorry for the
delay.
---
[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[
https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198614#comment-16198614
]
ASF GitHub Bot commented on THRIFT-4285:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1382
Is there a way you can provide a generated NewFooClientFactory as an
adapter to run the new code? i.e. (sorry this isn't go, but you get the idea):
mypkg.NewFooClientFactory(transport, protocolFactory) { return
mypkg.NewFooClient(thrift.NewTStandardClient(protocolFactory.GetProtocol(transport)));
}
This would make it backwards compatible for everyone and you wouldn't need
to change any of the test files, I believe? This would be better overall for
the project to maintain backwards compatibility. Let me know what you think.
I was away for a couple days on college tours with my son, sorry for the
delay.
> Pull generated send/recv into library to allow behaviour to be customised
> -
>
> Key: THRIFT-4285
> URL: https://issues.apache.org/jira/browse/THRIFT-4285
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Compiler, Go - Library
>Reporter: Chris Bannister
>Assignee: Chris Bannister
> Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch,
> 0001-go-pull-generated-send-recv-into-lib-v7.patch
>
>
> Currently it is difficult to change how thrift writes messages onto the
> transport because they are in the generated code. Instead the generated
> send/recv methods should be in the library. This will greatly simplify the
> client code and remove many duplicate methods whilst allowing users more
> flexibility to implement connection pools and other features such as THeader.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1382: THRIFT-4285 Move TX/RX methods from gen. code to library
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1382 > Is there a way you can provide a generated NewFooClientFactory as an adapter to run the new code? It would require putting back some of the generated code, but I'll try to find a way. I agree avoiding the BC break is worth it if possible. > I was away for a couple days on college tours with my son, sorry for the delay. No worries, I just wanted to ping you in case this slipped through the cracks. ---
[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198624#comment-16198624 ] ASF GitHub Bot commented on THRIFT-4285: Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1382 > Is there a way you can provide a generated NewFooClientFactory as an adapter to run the new code? It would require putting back some of the generated code, but I'll try to find a way. I agree avoiding the BC break is worth it if possible. > I was away for a couple days on college tours with my son, sorry for the delay. No worries, I just wanted to ping you in case this slipped through the cracks. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch, > 0001-go-pull-generated-send-recv-into-lib-v7.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1382: THRIFT-4285 Move TX/RX methods from gen. code to library
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1382 Given the backlog on the project, I don't blame you! :) ---
[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198648#comment-16198648 ] ASF GitHub Bot commented on THRIFT-4285: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1382 Given the backlog on the project, I don't blame you! :) > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch, > 0001-go-pull-generated-send-recv-into-lib-v7.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: TException and cross-tests
Hi Tom, All Apache Thrift generated exceptions are derived from TException, not just user defined exceptions. There are transport exceptions like TTransportException which raise connectivity problems, TProtocolExceptions for serialization errors, TApplicationExceptions for Server errors (e.g. calling a function that does not exist) and user def exceptions for application errors. TException is derived from the base exception type in the language in question (if there is one). Processors catch only the handler exceptions declared in the exception clause of the method in the service's IDL, any other exception escaping the handler will unwind the processor and possibly crash the server. Exceptions in the IDL exception list are passed back to the client by the processor. The only other kind of exception passed back to the client is TApplicationException which is used when a request is mechanically broken (wrong protocol or transport setup, missing reqed args, etc.). The only user defined way to return an exception to a caller from a handler is to actually raise the exception (throw, whatever). Again the exception must also be IDL defined and in the IDL exception list of the method in question. -Randy On Tue, Oct 10, 2017 at 12:42 AM, Tom wrote: > Hi, > > We're working on Common Lisp support for Thrift. I've run into a > little issue while implementing cross-tests - namely this bit: > > /** >* Print 'testException(%s)' with arg as '%s' >* @param string arg - a string indication what type of exception to > throw >* if arg == "Xception" throw Xception with errorCode = 1001 and message > = arg >* elsen if arg == "TException" throw TException >* else do not throw anything >*/ > void testException(1: string arg) throws(1: Xception err1), > > > Is there some specification on how TException is supposed to work? I > understand it is a parent of any exception type defined by the user in > the IDL file, but I thought that would be purely an implementation > detail of specific languages so that they can make clauses that catch > all user-defined errors they receive via Thrift. But apparently, it > should be possible to send it explicitly via the protocol, without it > being defined in the IDL? > > Or maybe it's meant to test the TApplicationException, as defined > here: https://erikvanoosten.github.io/thrift-missing- > specification/#_response_struct > ? Supposed to be sent not like a user-defined exception (message type > Reply), but with a message of type Exception? >
[GitHub] thrift pull request #1379: THRIFT-4350: enable dotnet-2.0.0-sdk in ubuntu xe...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1379 ---
[jira] [Resolved] (THRIFT-4350) Update netcore build for dotnet 2.0 sdk and make cross validation
[ https://issues.apache.org/jira/browse/THRIFT-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4350. Resolution: Fixed Fix Version/s: 0.11.0 > Update netcore build for dotnet 2.0 sdk and make cross validation > - > > Key: THRIFT-4350 > URL: https://issues.apache.org/jira/browse/THRIFT-4350 > Project: Thrift > Issue Type: Improvement > Components: .NETCore - Library >Affects Versions: 0.10.0 > Environment: docker ubuntu-xenial >Reporter: James E. King, III >Assignee: James E. King, III > Fix For: 0.11.0 > > > # Add dotnet core 2.0.0 official to the docker build image (xenial) > # Convert projects using "dotnet migrate" > # Ensure one can build on Windows inside Visual Studio 2017 using the project > that is checked in > # Ensure one can build on Linux using the project that is checked in and use > make check > # Set the target framework to netcoreapp2.0 - required for threading to work? > # Enable netcore in make cross > # Fix issues found: > ## netcore library never increases the sequence id number -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4350) Update netcore build for dotnet 2.0 sdk and make cross validation
[ https://issues.apache.org/jira/browse/THRIFT-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198843#comment-16198843 ] ASF GitHub Bot commented on THRIFT-4350: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1379 > Update netcore build for dotnet 2.0 sdk and make cross validation > - > > Key: THRIFT-4350 > URL: https://issues.apache.org/jira/browse/THRIFT-4350 > Project: Thrift > Issue Type: Improvement > Components: .NETCore - Library >Affects Versions: 0.10.0 > Environment: docker ubuntu-xenial >Reporter: James E. King, III >Assignee: James E. King, III > Fix For: 0.11.0 > > > # Add dotnet core 2.0.0 official to the docker build image (xenial) > # Convert projects using "dotnet migrate" > # Ensure one can build on Windows inside Visual Studio 2017 using the project > that is checked in > # Ensure one can build on Linux using the project that is checked in and use > make check > # Set the target framework to netcoreapp2.0 - required for threading to work? > # Enable netcore in make cross > # Fix issues found: > ## netcore library never increases the sequence id number -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1388: THRIFT-4355 Fix javascript indentation of default...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1388 ---
[jira] [Assigned] (THRIFT-4355) Javascript indentation incorrect when defaulting field attribute to a struct
[ https://issues.apache.org/jira/browse/THRIFT-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4355: -- Assignee: James E. King, III > Javascript indentation incorrect when defaulting field attribute to a struct > > > Key: THRIFT-4355 > URL: https://issues.apache.org/jira/browse/THRIFT-4355 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Compiler, Node.js - Compiler >Affects Versions: 0.10.0 >Reporter: Brian Forbis >Assignee: James E. King, III >Priority: Trivial > Fix For: 0.11.0 > > > This is the same bug described in THRIFT-4334 for the perl compiler, which > has also manifested in the javascript compilers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (THRIFT-4355) Javascript indentation incorrect when defaulting field attribute to a struct
[ https://issues.apache.org/jira/browse/THRIFT-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4355. Resolution: Fixed Fix Version/s: 0.11.0 Committed - thanks. > Javascript indentation incorrect when defaulting field attribute to a struct > > > Key: THRIFT-4355 > URL: https://issues.apache.org/jira/browse/THRIFT-4355 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Compiler, Node.js - Compiler >Affects Versions: 0.10.0 >Reporter: Brian Forbis >Assignee: James E. King, III >Priority: Trivial > Fix For: 0.11.0 > > > This is the same bug described in THRIFT-4334 for the perl compiler, which > has also manifested in the javascript compilers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4355) Javascript indentation incorrect when defaulting field attribute to a struct
[ https://issues.apache.org/jira/browse/THRIFT-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198863#comment-16198863 ] ASF GitHub Bot commented on THRIFT-4355: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1388 > Javascript indentation incorrect when defaulting field attribute to a struct > > > Key: THRIFT-4355 > URL: https://issues.apache.org/jira/browse/THRIFT-4355 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Compiler, Node.js - Compiler >Affects Versions: 0.10.0 >Reporter: Brian Forbis >Assignee: James E. King, III >Priority: Trivial > Fix For: 0.11.0 > > > This is the same bug described in THRIFT-4334 for the perl compiler, which > has also manifested in the javascript compilers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1361 Seems like it still has some issues in the cross test with c_glib. ---
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198867#comment-16198867 ] ASF GitHub Bot commented on THRIFT-4329: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1361 Seems like it still has some issues in the cross test with c_glib. > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4362) Missing size-check can lead to huge memory allocation
Christian Ciach created THRIFT-4362:
---
Summary: Missing size-check can lead to huge memory allocation
Key: THRIFT-4362
URL: https://issues.apache.org/jira/browse/THRIFT-4362
Project: Thrift
Issue Type: Bug
Components: Java - Library
Affects Versions: 0.10.0, 0.9.3
Reporter: Christian Ciach
In some cases the method
{{monospaced}}org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int
size){{monospaced}} gets called with a "size" parameter that has not been
validated by the existing method {{monospaced}}checkStringReadLength(int
size){{monospaced}}.
This is true if the method is called by
{{monospaced}}readMessageBegin(){{monospaced}} of the same class. The method
{{monospaced}}readString(){{monospaced}} checks the size correctly before
calling {{monospaced}}readStringBody(int size){{monospaced}}.
Since the readStringBody-method is public, there may be other callers who don't
check the size before calling this method.
We encountered this issue in production several times. Because of this we are
currently using our own patched version of libthrift-0.9.3. The patch is
attached, but it is surely not the best solution, because with this patch the
size may be checked twice, depending on the caller.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (THRIFT-4362) Missing size-check can lead to huge memory allocation
[
https://issues.apache.org/jira/browse/THRIFT-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Ciach updated THRIFT-4362:
Description:
In some cases the method
{{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
called with a "size" parameter that has not been validated by the existing
method {{checkStringReadLength(int size)}}.
This is true if the method is called by {{readMessageBegin()}} of the same
class. The method {{readString()}} checks the size correctly before calling
{{readStringBody(int size)}}.
Since the readStringBody-method is public, there may be other callers who don't
check the size before calling this method.
We encountered this issue in production several times. Because of this we are
currently using our own patched version of libthrift-0.9.3. The patch is
attached, but it is surely not the best solution, because with this patch the
size may be checked twice, depending on the caller.
was:
In some cases the method
{{monospaced}}org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int
size){{monospaced}} gets called with a "size" parameter that has not been
validated by the existing method {{monospaced}}checkStringReadLength(int
size){{monospaced}}.
This is true if the method is called by
{{monospaced}}readMessageBegin(){{monospaced}} of the same class. The method
{{monospaced}}readString(){{monospaced}} checks the size correctly before
calling {{monospaced}}readStringBody(int size){{monospaced}}.
Since the readStringBody-method is public, there may be other callers who don't
check the size before calling this method.
We encountered this issue in production several times. Because of this we are
currently using our own patched version of libthrift-0.9.3. The patch is
attached, but it is surely not the best solution, because with this patch the
size may be checked twice, depending on the caller.
> Missing size-check can lead to huge memory allocation
> -
>
> Key: THRIFT-4362
> URL: https://issues.apache.org/jira/browse/THRIFT-4362
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Christian Ciach
>
> In some cases the method
> {{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
> called with a "size" parameter that has not been validated by the existing
> method {{checkStringReadLength(int size)}}.
> This is true if the method is called by {{readMessageBegin()}} of the same
> class. The method {{readString()}} checks the size correctly before calling
> {{readStringBody(int size)}}.
> Since the readStringBody-method is public, there may be other callers who
> don't check the size before calling this method.
> We encountered this issue in production several times. Because of this we are
> currently using our own patched version of libthrift-0.9.3. The patch is
> attached, but it is surely not the best solution, because with this patch the
> size may be checked twice, depending on the caller.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (THRIFT-4362) Missing size-check can lead to huge memory allocation
[
https://issues.apache.org/jira/browse/THRIFT-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Ciach updated THRIFT-4362:
Description:
In some cases the method
{{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
called with a "size" parameter that has not been validated by the existing
method {{checkStringReadLength(int size)}}.
This is true if the method is called by {{readMessageBegin()}} of the same
class. The method {{readString()}} checks the size correctly before calling
{{readStringBody(int size)}}.
Since the readMessageBegin-method is public, there may be other callers who
don't check the size before calling this method.
We encountered this issue in production several times. Because of this we are
currently using our own patched version of libthrift-0.9.3. The patch is
attached, but it is surely not the best solution, because with this patch the
size may be checked twice, depending on the caller.
was:
In some cases the method
{{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
called with a "size" parameter that has not been validated by the existing
method {{checkStringReadLength(int size)}}.
This is true if the method is called by {{readMessageBegin()}} of the same
class. The method {{readString()}} checks the size correctly before calling
{{readStringBody(int size)}}.
Since the readStringBody-method is public, there may be other callers who don't
check the size before calling this method.
We encountered this issue in production several times. Because of this we are
currently using our own patched version of libthrift-0.9.3. The patch is
attached, but it is surely not the best solution, because with this patch the
size may be checked twice, depending on the caller.
> Missing size-check can lead to huge memory allocation
> -
>
> Key: THRIFT-4362
> URL: https://issues.apache.org/jira/browse/THRIFT-4362
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Christian Ciach
>
> In some cases the method
> {{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
> called with a "size" parameter that has not been validated by the existing
> method {{checkStringReadLength(int size)}}.
> This is true if the method is called by {{readMessageBegin()}} of the same
> class. The method {{readString()}} checks the size correctly before calling
> {{readStringBody(int size)}}.
> Since the readMessageBegin-method is public, there may be other callers who
> don't check the size before calling this method.
> We encountered this issue in production several times. Because of this we are
> currently using our own patched version of libthrift-0.9.3. The patch is
> attached, but it is surely not the best solution, because with this patch the
> size may be checked twice, depending on the caller.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (THRIFT-4362) Missing size-check can lead to huge memory allocation
[
https://issues.apache.org/jira/browse/THRIFT-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Ciach updated THRIFT-4362:
Attachment: check-size.patch
> Missing size-check can lead to huge memory allocation
> -
>
> Key: THRIFT-4362
> URL: https://issues.apache.org/jira/browse/THRIFT-4362
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Christian Ciach
> Attachments: check-size.patch
>
>
> In some cases the method
> {{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
> called with a "size" parameter that has not been validated by the existing
> method {{checkStringReadLength(int size)}}.
> This is true if the method is called by {{readMessageBegin()}} of the same
> class. The method {{readString()}} checks the size correctly before calling
> {{readStringBody(int size)}}.
> Since the readMessageBegin-method is public, there may be other callers who
> don't check the size before calling this method.
> We encountered this issue in production several times. Because of this we are
> currently using our own patched version of libthrift-0.9.3. The patch is
> attached, but it is surely not the best solution, because with this patch the
> size may be checked twice, depending on the caller.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (THRIFT-4362) Missing size-check can lead to huge memory allocation
[
https://issues.apache.org/jira/browse/THRIFT-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Ciach updated THRIFT-4362:
Description:
In some cases the method
{{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
called with a "size" parameter that has not been validated by the existing
method {{checkStringReadLength(int size)}}.
This is true if the method is called by {{readMessageBegin()}} of the same
class. The method {{readString()}} checks the size correctly before calling
{{readStringBody(int size)}}.
Since the methods {{readStringBody(int size)}} and {{readMessageBegin()}} are
public, there may be other callers who don't check the size correctly.
We encountered this issue in production several times. Because of this we are
currently using our own patched version of libthrift-0.9.3. The patch is
attached, but it is surely not the best solution, because with this patch the
size may be checked twice, depending on the caller.
was:
In some cases the method
{{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
called with a "size" parameter that has not been validated by the existing
method {{checkStringReadLength(int size)}}.
This is true if the method is called by {{readMessageBegin()}} of the same
class. The method {{readString()}} checks the size correctly before calling
{{readStringBody(int size)}}.
Since the readMessageBegin-method is public, there may be other callers who
don't check the size before calling this method.
We encountered this issue in production several times. Because of this we are
currently using our own patched version of libthrift-0.9.3. The patch is
attached, but it is surely not the best solution, because with this patch the
size may be checked twice, depending on the caller.
> Missing size-check can lead to huge memory allocation
> -
>
> Key: THRIFT-4362
> URL: https://issues.apache.org/jira/browse/THRIFT-4362
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Christian Ciach
> Attachments: check-size.patch
>
>
> In some cases the method
> {{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets
> called with a "size" parameter that has not been validated by the existing
> method {{checkStringReadLength(int size)}}.
> This is true if the method is called by {{readMessageBegin()}} of the same
> class. The method {{readString()}} checks the size correctly before calling
> {{readStringBody(int size)}}.
> Since the methods {{readStringBody(int size)}} and {{readMessageBegin()}} are
> public, there may be other callers who don't check the size correctly.
> We encountered this issue in production several times. Because of this we are
> currently using our own patched version of libthrift-0.9.3. The patch is
> attached, but it is surely not the best solution, because with this patch the
> size may be checked twice, depending on the caller.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-889) Add SPNEGO support to Thrift HTTP transport
[ https://issues.apache.org/jira/browse/THRIFT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199127#comment-16199127 ] Jens Geyer commented on THRIFT-889: --- > My understanding is that Facebook's Thrift library is a fork of Apache Thrift? No. FB opensourced Thrift twice. The first one became what is now known as Apache Thrift, the second is a later re-release of their (FBs) codebase. There still is some exchange between the projects. > Would it be possible to merge back Kerberos Not sure if a simple merge will do, but yes. > Add SPNEGO support to Thrift HTTP transport > --- > > Key: THRIFT-889 > URL: https://issues.apache.org/jira/browse/THRIFT-889 > Project: Thrift > Issue Type: New Feature > Components: Java - Library >Reporter: Carl Steinbach > Attachments: SPNEGO_cropped.png > > > [SPNEGO|http://en.wikipedia.org/wiki/SPNEGO] is the standard mechanism for > Kerberos authentication over HTTP. > Thrift should give users the option of using a Thrift HTTP client or server > that is capable of authentication using SPNEGO/Kerberos. This will be useful > for Hadoop which has chosen Kerberos as its standard authentication protocol, > as well as people who need to use Kerberos authentication with Thrift based > services running in servlet containers like Tomcat. > References: > * [LGPL licensed SPNEGO library for Java|http://spnego.sourceforge.net/] > * [Glassfish Spnego project|https://spnego.dev.java.net/] > * [SPNEGO authentication scheme for > HTTPClient|https://issues.apache.org/jira/browse/HTTPCLIENT-523] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: TException and cross-tests
Thank you for the thorough explanation. It clarified some bits of the
exception system for me.
I'm still not sure about that test I quoted, though - the
testException one. My best guess is that when the client calls
testException("TException"), the server should pass back an instance
of Xception (which is the only thing it can technically "throw" for
that function, unless we dig deeper into implementation details and
try to force a TApplicationException, which is probably a horrible
idea), and the client is supposed to catch it by establishing a
handler for TException. So basically, this is to test the hierarchy on
the client side. Is that right?
On Tue, Oct 10, 2017 at 5:27 PM, Randy Abernethy wrote:
> Hi Tom,
>
> All Apache Thrift generated exceptions are derived from TException, not
> just user defined exceptions. There are transport exceptions like
> TTransportException which raise connectivity problems, TProtocolExceptions
> for serialization errors, TApplicationExceptions for Server errors (e.g.
> calling a function that does not exist) and user def exceptions for
> application errors.
>
> TException is derived from the base exception type in the language in
> question (if there is one).
>
> Processors catch only the handler exceptions declared in the exception
> clause of the method in the service's IDL, any other exception escaping the
> handler will unwind the processor and possibly crash the server. Exceptions
> in the IDL exception list are passed back to the client by the processor.
> The only other kind of exception passed back to the client is
> TApplicationException which is used when a request is mechanically broken
> (wrong protocol or transport setup, missing reqed args, etc.).
>
> The only user defined way to return an exception to a caller from a handler
> is to actually raise the exception (throw, whatever). Again the exception
> must also be IDL defined and in the IDL exception list of the method in
> question.
>
> -Randy
>
>
> On Tue, Oct 10, 2017 at 12:42 AM, Tom wrote:
>
>> Hi,
>>
>> We're working on Common Lisp support for Thrift. I've run into a
>> little issue while implementing cross-tests - namely this bit:
>>
>> /**
>>* Print 'testException(%s)' with arg as '%s'
>>* @param string arg - a string indication what type of exception to
>> throw
>>* if arg == "Xception" throw Xception with errorCode = 1001 and message
>> = arg
>>* elsen if arg == "TException" throw TException
>>* else do not throw anything
>>*/
>> void testException(1: string arg) throws(1: Xception err1),
>>
>>
>> Is there some specification on how TException is supposed to work? I
>> understand it is a parent of any exception type defined by the user in
>> the IDL file, but I thought that would be purely an implementation
>> detail of specific languages so that they can make clauses that catch
>> all user-defined errors they receive via Thrift. But apparently, it
>> should be possible to send it explicitly via the protocol, without it
>> being defined in the IDL?
>>
>> Or maybe it's meant to test the TApplicationException, as defined
>> here: https://erikvanoosten.github.io/thrift-missing-
>> specification/#_response_struct
>> ? Supposed to be sent not like a user-defined exception (message type
>> Reply), but with a message of type Exception?
>>
