Re: [VOTE] Apache Thrift 0.16.0-rc2 release candidate

[Aki Sukegawa]

+1

On Thu, 10 Feb 2022, 14:05 Duru Can Celasun,  wrote:

> +1
>
>
>
> On Thu, 10 Feb 2022, at 18:48, Yuxuan Wang wrote:
> > +1
> >
> > Thanks for all the work, Jens!
> >
> > On Wed, Feb 9, 2022 at 12:19 PM Jens Geyer  wrote:
> >
> >>
> >> All,
> >>
> >> I propose that we accept the following release candidate as the official
> >> Apache Thrift 0.16.0 release:
> >>
> >>
> >>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.tar.gz
> >>
> >> The release candidate was created from the release/0.16.0 branch and can
> >> be cloned using:
> >>
> >> git clone -b release/0.16.0 https://github.com/apache/thrift.git
> >>
> >> The release candidates GPG signature can be found at:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.tar.gz.asc
> >>
> >> The release candidates checksums are:
> >> md5: 44cf1b54b4ec1890576c85804acfa637
> >> sha1: a4770d0d16851b59b657348d6d167437938dd750
> >> sha256: f460b5c1ca30d8918ff95ea3eb6291b3951cf518553566088f3f2be8981f6209
> >>
> >>
> >> A prebuilt statically-linked Windows compiler is available at:
> >>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.exe
> >>
> >> Prebuilt statically-linked Windows compiler GPG signature:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.exe.asc
> >>
> >> Prebuilt statically-linked Windows compiler checksums are:
> >> md5: 9ff1a90f8dd5b1fa73d55990b775a516
> >> sha1: 16a85665a095b5924f2d00efe1e7ae4595c1a317
> >> sha256: e106135ee72c5328ccf13faa1180570c672d4bb7af44d3f9e34642874474b58a
> >>
> >>
> >> The CHANGES list for this release is available at:
> >> https://github.com/apache/thrift/blob/0.16.0/CHANGES.md
> >>
> >>
> >> Please download, verify sig/sum, install and test the libraries and
> >> languages of your choice.
> >>
> >> This vote will close in 123 hours on 2022-02-15 00:00 UTC
> >> https://www.timeanddate.com/countdown/generic?iso=20220215T=1440
> >>
> >> [ ] +1 Release this as Apache Thrift 0.16.0
> >> [ ] +0
> >> [ ] -1 Do not release this as Apache Thrift 0.16.0 because...
> >>
> >> PS: Thanks to all that made it possible.
> >>
> >>
> >>
>

[jira] [Commented] (THRIFT-4858) Java TThreadPoolServer: confusing error message on closed socket

[Aki Sukegawa (Jira)]

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

Aki Sukegawa commented on THRIFT-4858:
--

[~q.xu] please take a look at the actual changes in the associated PRs for 
these tickets. They changed how TTransportException are handled in 
TThreadPoolServer.

> Java TThreadPoolServer: confusing error message on closed socket
> 
>
> Key: THRIFT-4858
> URL: https://issues.apache.org/jira/browse/THRIFT-4858
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.12.0
> Environment: Here is some information on my environment and code that 
> calls Thrift.
> Environment: Red Hat Linux 7.6, Java 1.8, Thrift 0.12.0. Both my client and 
> server are in Java. However, I have also seen this when a Python client calls 
> the Java server.
> Here is what I do to set up the server, my service Iface name is 
> "AlgorithmRepository" ...
> {{TServerTransport transport = new TServerSocket(10202);}}
> {{ TProcessor processor = new AlgorithmRepository.Processor<>(this);}}
> {{ Args args = new 
> TThreadPoolServer.Args(transport).processor(processor).inputTransportFactory(new
>  TFramedTransport.Factory()).outputTransportFactory(new 
> TFramedTransport.Factory()).protocolFactory(new TBinaryProtocol.Factory());}}
> {{ final TServer server = new TThreadPoolServer(args);}}
> {{ new Thread(server::serve).start();}}
> That last line corresponds to the Thread you see at the bottom of the 
> exception.
> It is worth noting we did also set the Input and Output Protocol Factories 
> too and it had no affect on the result.
> We saw on stackoverflow that if you don't have the same Transport type, it 
> will fail to function. Here is client code that sets this up:
> {{TTransport transport = new TFramedTransport(new TSocket(host, port, 
> socketTimeoutMillis));}}
> I'd be happy to share more client code if you felt it was something the 
> client is doing wrong.
>  
>Reporter: Michael Czajkowski
>Assignee: Aki Sukegawa
>Priority: Major
> Fix For: 0.13.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've spotted an error in using java libthrift that I'd like to call to your 
> attention. It is in version 0.12.0, but I see it in other versions. I will 
> comment about the other versions at the end, please read - it may be very 
> *important* to you.
> I create a TThreadPoolServer, and when my client calls a method, the server 
> spawns off a worker thread and when it gets to this line (in 
> TThreadPoolServer):
> {{if(stopped_ || !processor.process(inputProtocol, outputProtocol)) {}}
> {{break;}}
>  }
> It will call a TBaseProcessor's process method, which can only return either 
> True or throw an Exception. In my case, it gets to the very bottom and calls 
> the ProcessFunction fn properly:
> {{fn.process(msg.seqid, in, out, iface);}}
> Followed by returning true. However, since the TThreadPoolServer will not 
> "break" out of the while(true) loop it is in, it will attempt to call the 
> TBaseProcessor's process method again and this time around I get an exception 
> when this line is called on TBaseProcessor's process method:
> {{TMessage msg = in.readMessageBegin();}}
> Exception is:
> 17844 [pool-6-thread-5] ERROR org.apache.thrift.server.TThreadPoolServer - 
> Thrift error occurred during processing of message.
> {{org.apache.thrift.transport.TTransportException}}
>  at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:132)
>  at 
> org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:100)
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
>  at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:33)
>  at 
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:318)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>

[jira] [Updated] (THRIFT-4858) Java TThreadPoolServer: confusing error message on closed socket

[Aki Sukegawa (Jira)]

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

Aki Sukegawa updated THRIFT-4858:
-
Summary: Java TThreadPoolServer: confusing error message on closed socket  
(was: Java TThreadPoolServer calls TBaseProcesser twice, erroneously)

> Java TThreadPoolServer: confusing error message on closed socket
> 
>
> Key: THRIFT-4858
> URL: https://issues.apache.org/jira/browse/THRIFT-4858
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.12.0
> Environment: Here is some information on my environment and code that 
> calls Thrift.
> Environment: Red Hat Linux 7.6, Java 1.8, Thrift 0.12.0. Both my client and 
> server are in Java. However, I have also seen this when a Python client calls 
> the Java server.
> Here is what I do to set up the server, my service Iface name is 
> "AlgorithmRepository" ...
> {{TServerTransport transport = new TServerSocket(10202);}}
> {{ TProcessor processor = new AlgorithmRepository.Processor<>(this);}}
> {{ Args args = new 
> TThreadPoolServer.Args(transport).processor(processor).inputTransportFactory(new
>  TFramedTransport.Factory()).outputTransportFactory(new 
> TFramedTransport.Factory()).protocolFactory(new TBinaryProtocol.Factory());}}
> {{ final TServer server = new TThreadPoolServer(args);}}
> {{ new Thread(server::serve).start();}}
> That last line corresponds to the Thread you see at the bottom of the 
> exception.
> It is worth noting we did also set the Input and Output Protocol Factories 
> too and it had no affect on the result.
> We saw on stackoverflow that if you don't have the same Transport type, it 
> will fail to function. Here is client code that sets this up:
> {{TTransport transport = new TFramedTransport(new TSocket(host, port, 
> socketTimeoutMillis));}}
> I'd be happy to share more client code if you felt it was something the 
> client is doing wrong.
>  
>Reporter: Michael Czajkowski
>Assignee: Aki Sukegawa
>Priority: Major
> Fix For: 0.13.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've spotted an error in using java libthrift that I'd like to call to your 
> attention. It is in version 0.12.0, but I see it in other versions. I will 
> comment about the other versions at the end, please read - it may be very 
> *important* to you.
> I create a TThreadPoolServer, and when my client calls a method, the server 
> spawns off a worker thread and when it gets to this line (in 
> TThreadPoolServer):
> {{if(stopped_ || !processor.process(inputProtocol, outputProtocol)) {}}
> {{break;}}
>  }
> It will call a TBaseProcessor's process method, which can only return either 
> True or throw an Exception. In my case, it gets to the very bottom and calls 
> the ProcessFunction fn properly:
> {{fn.process(msg.seqid, in, out, iface);}}
> Followed by returning true. However, since the TThreadPoolServer will not 
> "break" out of the while(true) loop it is in, it will attempt to call the 
> TBaseProcessor's process method again and this time around I get an exception 
> when this line is called on TBaseProcessor's process method:
> {{TMessage msg = in.readMessageBegin();}}
> Exception is:
> 17844 [pool-6-thread-5] ERROR org.apache.thrift.server.TThreadPoolServer - 
> Thrift error occurred during processing of message.
> {{org.apache.thrift.transport.TTransportException}}
>  at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:132)
>  at 
> org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:100)
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
>  at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:33)
>  at 
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:318)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> I surmise be

[jira] [Resolved] (THRIFT-4858) Java TThreadPoolServer calls TBaseProcesser twice, erroneously

[Aki Sukegawa (Jira)]

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

Aki Sukegawa resolved THRIFT-4858.
--
  Assignee: Aki Sukegawa
Resolution: Fixed

Please reopen if this persists with current master or anywhere after 
[https://github.com/apache/thrift/commit/c35ed736d26a1dfd8965ae197a67904ed9b4fba3#diff-c6a81da7e9ec5ce3c040a3386a790b69R321]

> Java TThreadPoolServer calls TBaseProcesser twice, erroneously
> --
>
> Key: THRIFT-4858
> URL: https://issues.apache.org/jira/browse/THRIFT-4858
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.12.0
> Environment: Here is some information on my environment and code that 
> calls Thrift.
> Environment: Red Hat Linux 7.6, Java 1.8, Thrift 0.12.0. Both my client and 
> server are in Java. However, I have also seen this when a Python client calls 
> the Java server.
> Here is what I do to set up the server, my service Iface name is 
> "AlgorithmRepository" ...
> {{TServerTransport transport = new TServerSocket(10202);}}
> {{ TProcessor processor = new AlgorithmRepository.Processor<>(this);}}
> {{ Args args = new 
> TThreadPoolServer.Args(transport).processor(processor).inputTransportFactory(new
>  TFramedTransport.Factory()).outputTransportFactory(new 
> TFramedTransport.Factory()).protocolFactory(new TBinaryProtocol.Factory());}}
> {{ final TServer server = new TThreadPoolServer(args);}}
> {{ new Thread(server::serve).start();}}
> That last line corresponds to the Thread you see at the bottom of the 
> exception.
> It is worth noting we did also set the Input and Output Protocol Factories 
> too and it had no affect on the result.
> We saw on stackoverflow that if you don't have the same Transport type, it 
> will fail to function. Here is client code that sets this up:
> {{TTransport transport = new TFramedTransport(new TSocket(host, port, 
> socketTimeoutMillis));}}
> I'd be happy to share more client code if you felt it was something the 
> client is doing wrong.
>  
>Reporter: Michael Czajkowski
>Assignee: Aki Sukegawa
>Priority: Major
> Fix For: 0.13.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've spotted an error in using java libthrift that I'd like to call to your 
> attention. It is in version 0.12.0, but I see it in other versions. I will 
> comment about the other versions at the end, please read - it may be very 
> *important* to you.
> I create a TThreadPoolServer, and when my client calls a method, the server 
> spawns off a worker thread and when it gets to this line (in 
> TThreadPoolServer):
> {{if(stopped_ || !processor.process(inputProtocol, outputProtocol)) {}}
> {{break;}}
>  }
> It will call a TBaseProcessor's process method, which can only return either 
> True or throw an Exception. In my case, it gets to the very bottom and calls 
> the ProcessFunction fn properly:
> {{fn.process(msg.seqid, in, out, iface);}}
> Followed by returning true. However, since the TThreadPoolServer will not 
> "break" out of the while(true) loop it is in, it will attempt to call the 
> TBaseProcessor's process method again and this time around I get an exception 
> when this line is called on TBaseProcessor's process method:
> {{TMessage msg = in.readMessageBegin();}}
> Exception is:
> 17844 [pool-6-thread-5] ERROR org.apache.thrift.server.TThreadPoolServer - 
> Thrift error occurred during processing of message.
> {{org.apache.thrift.transport.TTransportException}}
>  at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:132)
>  at 
> org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:100)
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
>  at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:33)
>  at 
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:318)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadP

[jira] [Updated] (THRIFT-4858) Java TThreadPoolServer calls TBaseProcesser twice, erroneously

[Aki Sukegawa (Jira)]

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

Aki Sukegawa updated THRIFT-4858:
-
Fix Version/s: 0.13.0

> Java TThreadPoolServer calls TBaseProcesser twice, erroneously
> --
>
> Key: THRIFT-4858
> URL: https://issues.apache.org/jira/browse/THRIFT-4858
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.12.0
> Environment: Here is some information on my environment and code that 
> calls Thrift.
> Environment: Red Hat Linux 7.6, Java 1.8, Thrift 0.12.0. Both my client and 
> server are in Java. However, I have also seen this when a Python client calls 
> the Java server.
> Here is what I do to set up the server, my service Iface name is 
> "AlgorithmRepository" ...
> {{TServerTransport transport = new TServerSocket(10202);}}
> {{ TProcessor processor = new AlgorithmRepository.Processor<>(this);}}
> {{ Args args = new 
> TThreadPoolServer.Args(transport).processor(processor).inputTransportFactory(new
>  TFramedTransport.Factory()).outputTransportFactory(new 
> TFramedTransport.Factory()).protocolFactory(new TBinaryProtocol.Factory());}}
> {{ final TServer server = new TThreadPoolServer(args);}}
> {{ new Thread(server::serve).start();}}
> That last line corresponds to the Thread you see at the bottom of the 
> exception.
> It is worth noting we did also set the Input and Output Protocol Factories 
> too and it had no affect on the result.
> We saw on stackoverflow that if you don't have the same Transport type, it 
> will fail to function. Here is client code that sets this up:
> {{TTransport transport = new TFramedTransport(new TSocket(host, port, 
> socketTimeoutMillis));}}
> I'd be happy to share more client code if you felt it was something the 
> client is doing wrong.
>  
>Reporter: Michael Czajkowski
>Priority: Major
> Fix For: 0.13.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've spotted an error in using java libthrift that I'd like to call to your 
> attention. It is in version 0.12.0, but I see it in other versions. I will 
> comment about the other versions at the end, please read - it may be very 
> *important* to you.
> I create a TThreadPoolServer, and when my client calls a method, the server 
> spawns off a worker thread and when it gets to this line (in 
> TThreadPoolServer):
> {{if(stopped_ || !processor.process(inputProtocol, outputProtocol)) {}}
> {{break;}}
>  }
> It will call a TBaseProcessor's process method, which can only return either 
> True or throw an Exception. In my case, it gets to the very bottom and calls 
> the ProcessFunction fn properly:
> {{fn.process(msg.seqid, in, out, iface);}}
> Followed by returning true. However, since the TThreadPoolServer will not 
> "break" out of the while(true) loop it is in, it will attempt to call the 
> TBaseProcessor's process method again and this time around I get an exception 
> when this line is called on TBaseProcessor's process method:
> {{TMessage msg = in.readMessageBegin();}}
> Exception is:
> 17844 [pool-6-thread-5] ERROR org.apache.thrift.server.TThreadPoolServer - 
> Thrift error occurred during processing of message.
> {{org.apache.thrift.transport.TTransportException}}
>  at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:132)
>  at 
> org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:100)
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
>  at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:33)
>  at 
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:318)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> I surmise because my TProtocol in has already sent the bytes (I am using a 
> TBinaryProtocol) to the process function, there is nothing left to read and 
> thus we never make it t

[jira] [Commented] (THRIFT-4858) Java TThreadPoolServer calls TBaseProcesser twice, erroneously

[Aki Sukegawa (Jira)]

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

Aki Sukegawa commented on THRIFT-4858:
--

The excessive error message was likely to be introduced by THRIFT-3769 (0.12.0) 
and subsequently been fixed by THRIFT-4805 (upcoming release).

> Java TThreadPoolServer calls TBaseProcesser twice, erroneously
> --
>
> Key: THRIFT-4858
> URL: https://issues.apache.org/jira/browse/THRIFT-4858
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.12.0
> Environment: Here is some information on my environment and code that 
> calls Thrift.
> Environment: Red Hat Linux 7.6, Java 1.8, Thrift 0.12.0. Both my client and 
> server are in Java. However, I have also seen this when a Python client calls 
> the Java server.
> Here is what I do to set up the server, my service Iface name is 
> "AlgorithmRepository" ...
> {{TServerTransport transport = new TServerSocket(10202);}}
> {{ TProcessor processor = new AlgorithmRepository.Processor<>(this);}}
> {{ Args args = new 
> TThreadPoolServer.Args(transport).processor(processor).inputTransportFactory(new
>  TFramedTransport.Factory()).outputTransportFactory(new 
> TFramedTransport.Factory()).protocolFactory(new TBinaryProtocol.Factory());}}
> {{ final TServer server = new TThreadPoolServer(args);}}
> {{ new Thread(server::serve).start();}}
> That last line corresponds to the Thread you see at the bottom of the 
> exception.
> It is worth noting we did also set the Input and Output Protocol Factories 
> too and it had no affect on the result.
> We saw on stackoverflow that if you don't have the same Transport type, it 
> will fail to function. Here is client code that sets this up:
> {{TTransport transport = new TFramedTransport(new TSocket(host, port, 
> socketTimeoutMillis));}}
> I'd be happy to share more client code if you felt it was something the 
> client is doing wrong.
>  
>Reporter: Michael Czajkowski
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've spotted an error in using java libthrift that I'd like to call to your 
> attention. It is in version 0.12.0, but I see it in other versions. I will 
> comment about the other versions at the end, please read - it may be very 
> *important* to you.
> I create a TThreadPoolServer, and when my client calls a method, the server 
> spawns off a worker thread and when it gets to this line (in 
> TThreadPoolServer):
> {{if(stopped_ || !processor.process(inputProtocol, outputProtocol)) {}}
> {{break;}}
>  }
> It will call a TBaseProcessor's process method, which can only return either 
> True or throw an Exception. In my case, it gets to the very bottom and calls 
> the ProcessFunction fn properly:
> {{fn.process(msg.seqid, in, out, iface);}}
> Followed by returning true. However, since the TThreadPoolServer will not 
> "break" out of the while(true) loop it is in, it will attempt to call the 
> TBaseProcessor's process method again and this time around I get an exception 
> when this line is called on TBaseProcessor's process method:
> {{TMessage msg = in.readMessageBegin();}}
> Exception is:
> 17844 [pool-6-thread-5] ERROR org.apache.thrift.server.TThreadPoolServer - 
> Thrift error occurred during processing of message.
> {{org.apache.thrift.transport.TTransportException}}
>  at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:132)
>  at 
> org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:100)
>  at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
>  at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
>  at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:33)
>  at 
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:318)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> I surmise because my TProtocol in has already sent the bytes (I am 

[jira] [Commented] (THRIFT-4677) UnicodeDecodeError in Python3

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4677:
--

AFAIK Apache Thrift's string wire format is tied to UTF8.

> UnicodeDecodeError in Python3
> -
>
> Key: THRIFT-4677
> URL: https://issues.apache.org/jira/browse/THRIFT-4677
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
> Environment: Operating System: Windows 10 Pro (Simplified Chinese)
> Python Interpreter: Python 3.6.6
> {{osquery}} Version: 3.3.0
> {{osquery-python}} Version: 3.0.5
>  
>Reporter: Jarry Shaw
>Priority: Critical
> Attachments: compat.py
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> This is an issue occurred when using 
> [osquery-python|https://github.com/osquery/osquery-python] (Python binding of 
> [osquery|https://osquery.io/] by Facebook).
> When querying, {{UnicodeDecodeError}} raised with error message: "{{'utf-8' 
> codec can't decode byte 0xc3 in position 0: invalid continuation byte}}" from 
> {{thrift.compat.binary_to_str}}, which is because the encoding of {{bin_val}} 
> parameter should be "{{gbk}}".
> Possible approaches are:
>  * add a parameter for user to determine encodings
>  * get the system encoding through {{locale.getpreferredencoding()}}
>  * call {{bin_val.decode}} with {{errors='replace'}} or {{errors='ignore'}} 
> parameter
>  * introduce {{chardet}} to try and resolve encoding problems
> The attachment is my hack solution to this issue (through not perfect).



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

[jira] [Resolved] (THRIFT-4056) Skip() should throw TProtocolException.INVALID_DATA on unknown data types

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-4056.
--
Resolution: Not A Problem

It doesn't throw INVALID_DATA but it correctly aborts the processing on invalid 
data.

If we still want to throw INVALID_DATA please raise another issue to switch the 
whole library's error handling to Thrift-defined exceptions.

> Skip() should throw TProtocolException.INVALID_DATA on unknown data types
> -
>
> Key: THRIFT-4056
> URL: https://issues.apache.org/jira/browse/THRIFT-4056
> Project: Thrift
>  Issue Type: Sub-task
>  Components: Erlang - Library
>Reporter: Jens Geyer
>Priority: Major
>




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

[jira] [Commented] (THRIFT-4056) Skip() should throw TProtocolException.INVALID_DATA on unknown data types

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4056:
--

The title says "should throw TProtocolException.INVALID_DATA" but it'll throw a 
standard {{function_clause}} exception.

That said, since whole library's error handling is basically the same, it 
wouldn't make sense to introduce Thrift specific exception only here. Even if 
we want to switch to Thrift specific exceptions, probably it shouldn't be done 
under this issue.

> Skip() should throw TProtocolException.INVALID_DATA on unknown data types
> -
>
> Key: THRIFT-4056
> URL: https://issues.apache.org/jira/browse/THRIFT-4056
> Project: Thrift
>  Issue Type: Sub-task
>  Components: Erlang - Library
>Reporter: Jens Geyer
>Priority: Major
>




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

[jira] [Commented] (THRIFT-4056) Skip() should throw TProtocolException.INVALID_DATA on unknown data types

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4056:
--

I can confirm your observation about function_clause. {{skip}} ends up calling 
{{read}} function of implementation protocol (binary/compact/json) down the 
road and each implementation only has {{read}} for known types.

> Skip() should throw TProtocolException.INVALID_DATA on unknown data types
> -
>
> Key: THRIFT-4056
> URL: https://issues.apache.org/jira/browse/THRIFT-4056
> Project: Thrift
>  Issue Type: Sub-task
>  Components: Erlang - Library
>Reporter: Jens Geyer
>Priority: Major
>




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

[jira] [Comment Edited] (THRIFT-4056) Skip() should throw TProtocolException.INVALID_DATA on unknown data types

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-4056 at 2/15/19 5:48 AM:
---

I can confirm your observation about {{function_clause}} error. {{skip}} ends 
up calling {{read}} function of implementation protocol (binary/compact/json) 
down the road and each implementation only has {{read}} for known types.


was (Author: nsuke):
I can confirm your observation about function_clause. {{skip}} ends up calling 
{{read}} function of implementation protocol (binary/compact/json) down the 
road and each implementation only has {{read}} for known types.

> Skip() should throw TProtocolException.INVALID_DATA on unknown data types
> -
>
> Key: THRIFT-4056
> URL: https://issues.apache.org/jira/browse/THRIFT-4056
> Project: Thrift
>  Issue Type: Sub-task
>  Components: Erlang - Library
>Reporter: Jens Geyer
>Priority: Major
>




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

[jira] [Assigned] (THRIFT-4621) THeader for Python

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa reassigned THRIFT-4621:


Assignee: Neil Williams

> THeader for Python
> --
>
> Key: THRIFT-4621
> URL: https://issues.apache.org/jira/browse/THRIFT-4621
> Project: Thrift
>  Issue Type: New Feature
>  Components: Python - Library
>Reporter: Neil Williams
>Assignee: Neil Williams
>Priority: Minor
> Fix For: 0.12.0
>
>
> I'm interested in porting THeader for the Python library. If that sounds OK, 
> I'll have a PR ready in not too long.



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

[jira] [Resolved] (THRIFT-4621) THeader for Python

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-4621.
--
   Resolution: Fixed
Fix Version/s: 0.12.0

committed, thanks

> THeader for Python
> --
>
> Key: THRIFT-4621
> URL: https://issues.apache.org/jira/browse/THRIFT-4621
> Project: Thrift
>  Issue Type: New Feature
>  Components: Python - Library
>Reporter: Neil Williams
>Assignee: Neil Williams
>Priority: Minor
> Fix For: 0.12.0
>
>
> I'm interested in porting THeader for the Python library. If that sounds OK, 
> I'll have a PR ready in not too long.



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

[jira] [Commented] (THRIFT-4581) HttpTransport with JsonProtocol - Dart Client <--> Cpp server.

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4581:
--

AFAIK Thrift http transport should not encode body with base64.

I think it is a Dart implementation problem.

> HttpTransport with JsonProtocol - Dart Client <--> Cpp server.
> --
>
> Key: THRIFT-4581
> URL: https://issues.apache.org/jira/browse/THRIFT-4581
> Project: Thrift
>  Issue Type: Question
>  Components: C++ - Library, Dart - Library
>Affects Versions: 0.11.0
> Environment: The {color:#205081}*client*{color} is a dart app set 
> with *httptransport* and *JsonProtocol.* The ide used is IntelliJ.
>  
> The {color:#205081}*server*{color} is a cpp program set with *httptransport* 
> and *JsonProtocol* as well. The problem is the message sent differs from the 
> message expected. The ide used is QTCreator.
>  
> Both client and server run on ubuntu 16.04 xenial. 
> AMD FX(tm)-8350 Eight-Core Processor
> 16 gb 
>Reporter: Rommel de Sene Trindade
>Priority: Trivial
>
> Dart httptransport uses base64 encoding to send http post data but Cpp 
> httptransport doesn't decode the base64 coded json message.
> Eg.
> Message sent by dart client:
> {code}
> POST /olp-0.4 HTTP/1.1
> 
> WzEsIkxvZ2luIiwxLDEseyIxIjp7InJlYyI6eyIxIjp7ImkzMiI6MH0sIjIiOnsiaTMyIjowfSwiNCI6eyJpMzIiOjB9LCI1Ijp7InN0ciI6InJvbW1lbHN0QGdtYWlsLmNvbSJ9LCI2Ijp7InN0ciI6ImRlc2VuIn0sIjciOnsiaTMyIjowfX19fV0=
> {code}
>  
> Message expected by cpp server:
> {code}
> POST /olp-0.4 HTTP/1.1
> 
> [1,"Login",1,0,\{"1": 
> {"rec":{"5":{"str":""},"6":\{"str":""},"7":\{"i32":0]
> {code}
>  
> The question is:
> What setup should be set on cpp server to read the message from thrift dart 
> lib?



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

[jira] [Commented] (THRIFT-4560) The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4560:
--

[~emmenlau] 

Your proposal sounds pretty good to me.

We can reduce the impact by defaulting to AUTO where we're currently defaulting 
to ON.

 

BTW in your example,
{quote}If the {{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in 
error, the build will fail
{quote}
it sounds like a Find*.cmake script bug (or bug in our cmake script in using 
the result of find_package), since we're not specifying REQUIRED option.

 

> The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build
> ---
>
> Key: THRIFT-4560
> URL: https://issues.apache.org/jira/browse/THRIFT-4560
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
> according to my understanding, the resulting logic is wrong and can lead to 
> problems. Consider the following example for building with Qt4 or Qt5 from 
> {{build/cmake/DefineOptions.cmake}}:
> {noformat}
> find_package(Qt5 QUIET COMPONENTS Core Network)
> CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
>"Qt5_FOUND" OFF)
> {noformat}
> If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have 
> Qt5 installed, they will not get an error. They will just get a warning that 
> the option {{WITH_QT5}} was unused.
> Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
> -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
> {{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
> will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.
> My expected behavior is that if {{WITH_QT5=OFF}} is specified, that no Qt5 
> checks are run and that a missing/broken Qt5 would not impact thrift in any 
> way.



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

[jira] [Closed] (THRIFT-3399) Import Haskell haddock comments and trivial refactorings

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa closed THRIFT-3399.

Resolution: Won't Fix

per PR comment

> Import Haskell haddock comments and trivial refactorings
> 
>
> Key: THRIFT-3399
> URL: https://issues.apache.org/jira/browse/THRIFT-3399
> Project: Thrift
>  Issue Type: Sub-task
>  Components: Haskell - Library
>    Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
>Priority: Minor
>
> fbthrift has some more commits from the main author of current version of 
> Apache Thrift haskell lib.
> Those commits are not at all new (mostly 1 year old) and contains following
> * hadrock comments
> * fixes some JSON protocols issues
> * pretty JSON protocols
> * some cleanup and potential performance improvement
> * a few fixes for code generation
> To avoid an unecessarily huge diff, I'll first merge comments and trivial 
> changes in this sub-task.



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

[jira] [Commented] (THRIFT-4576) PHP: untracked dependency: composer

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4576:
--

We handle such a case as a configure/cmake failure, not as a build error.

For npm and ant, we explicitly detect them and skip building nodejs or java lib 
respectively, if not available.

> PHP: untracked dependency: composer
> ---
>
> Key: THRIFT-4576
> URL: https://issues.apache.org/jira/browse/THRIFT-4576
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
> Environment: PHP 7.1.14
>Reporter: Aki Sukegawa
>Priority: Minor
>
> {quote}Making all in php
> Making all in test
> composer install --working-dir=../../..
> make[4]: composer: No such file or directory
> {quote}
> A workaround is to install composer, obviously.



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

[jira] [Updated] (THRIFT-4577) Outdated cipher string in python unit test

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-4577:
-
Summary: Outdated cipher string in python unit test  (was: py: outdated 
cipher string in python unit test)

> Outdated cipher string in python unit test
> --
>
> Key: THRIFT-4577
> URL: https://issues.apache.org/jira/browse/THRIFT-4577
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.11.0
> Environment: OpenSSL 1.1.0h
>    Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
>Priority: Minor
>
>  
> test_ciphers fails if system SSL doesn't support "DES-CBC3-SHA" which is 
> quite old.
> Adding an additional modern cipher fixes it.
> {code:java}
> == 
> ERROR: test_ciphers (__main__.TSSLSocketTest) 
> -- 
> Traceback (most recent call last): 
>   File 
> "/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
>  line 281, in _do_open 
>     return self._wrap_socket(plain_sock) 
>   File 
> "/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
>  line 179, in _wrap_socket 
>     self.ssl_context.set_ciphers(self.ciphers) 
> ssl.SSLError: ('No cipher can be selected.',) 
>  
> During handling of the above exception, another exception occurred: 
>  
> Traceback (most recent call last): 
>   File "test/test_sslsocket.py", line 268, in test_ciphers 
>     self._assert_connection_success(server, ca_certs=SERVER_CERT, 
> ciphers=TEST_CIPHERS) 
>   File "test/test_sslsocket.py", line 156, in _assert_connection_success 
>     client.open() 
>   File 
> "/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
>  line 289, in open 
>     super(TSSLSocket, self).open() 
>   File 
> "/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSocket.py",
>  line 101, in open 
>     handle = self._do_open(family, socktype) 
>   File 
> "/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
>  line 286, in _do_open 
>     raise TTransportException(TTransportException.NOT_OPEN, msg) 
> thrift.transport.TTransport.TTransportException: failed to initialize 
> SSL{code}
>  
>  



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

[jira] [Created] (THRIFT-4577) py: outdated cipher string in python unit test

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-4577:


 Summary: py: outdated cipher string in python unit test
 Key: THRIFT-4577
 URL: https://issues.apache.org/jira/browse/THRIFT-4577
 Project: Thrift
  Issue Type: Bug
  Components: Python - Library
Affects Versions: 0.11.0
 Environment: OpenSSL 1.1.0h
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa


 

test_ciphers fails if system SSL doesn't support "DES-CBC3-SHA" which is quite 
old.

Adding an additional modern cipher fixes it.
{code:java}
== 
ERROR: test_ciphers (__main__.TSSLSocketTest) 
-- 
Traceback (most recent call last): 
  File 
"/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
 line 281, in _do_open 
    return self._wrap_socket(plain_sock) 
  File 
"/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
 line 179, in _wrap_socket 
    self.ssl_context.set_ciphers(self.ciphers) 
ssl.SSLError: ('No cipher can be selected.',) 
 
During handling of the above exception, another exception occurred: 
 
Traceback (most recent call last): 
  File "test/test_sslsocket.py", line 268, in test_ciphers 
    self._assert_connection_success(server, ca_certs=SERVER_CERT, 
ciphers=TEST_CIPHERS) 
  File "test/test_sslsocket.py", line 156, in _assert_connection_success 
    client.open() 
  File 
"/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
 line 289, in open 
    super(TSSLSocket, self).open() 
  File 
"/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSocket.py",
 line 101, in open 
    handle = self._do_open(family, socktype) 
  File 
"/data/x/repo/thrift/lib/py/build/lib.linux-x86_64-3.6/thrift/transport/TSSLSocket.py",
 line 286, in _do_open 
    raise TTransportException(TTransportException.NOT_OPEN, msg) 
thrift.transport.TTransport.TTransportException: failed to initialize SSL{code}
 

 



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

[jira] [Created] (THRIFT-4576) PHP: untracked dependency: composer

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-4576:


 Summary: PHP: untracked dependency: composer
 Key: THRIFT-4576
 URL: https://issues.apache.org/jira/browse/THRIFT-4576
 Project: Thrift
  Issue Type: Bug
  Components: PHP - Library
 Environment: PHP 7.1.14
Reporter: Aki Sukegawa


{quote}Making all in php
Making all in test
composer install --working-dir=../../..
make[4]: composer: No such file or directory
{quote}
A workaround is to install composer, obviously.



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

[jira] [Commented] (THRIFT-4200) commit THRIFT-4034 makes bison++ 1.21 crash

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4200:
--

bison++ is a very old and unmaintained fork of bison.

Maybe we want to introduce a version requirement or something in cmake/autoconf 
to prevent bison++.

> commit THRIFT-4034 makes bison++ 1.21 crash
> ---
>
> Key: THRIFT-4200
> URL: https://issues.apache.org/jira/browse/THRIFT-4200
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.11.0
> Environment: - Linux 4.4.0-72-generic #93-Ubuntu SMP x86_64 x86_64 
> x86_64 GNU/Linux
> - Ubuntu 16.04.2 LTS xenial
> - bison++ 1.21.11-3.1 (as claimed by `dpkg -l bison*`) or 1.21.9-1 (as 
> claimed by `bison++ --version`)
> - dpkg -l g++: g++ 4:5.3.1-1ubuntu1 / g++ --version: g++ (Ubuntu 
> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> - cmake 3.5.1-1ubuntu3
>Reporter: nojhan
>Priority: Blocker
>
> When trying to build a freshly cloned Thrift repository:
> ./bootstrap.sh
> ./configure
> make
> It ends on this error:
> [...]
> /bin/bash ../../../ylwrap thrift/thrifty.yy y.tab.c thrift/thrifty.cc y.tab.h 
> `echo thrift/thrifty.cc | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e 
> s/c++$/h++/ -e s/c$/h/` y.output thrift/thrifty.output -- bison -y -d 
> *** Error in `bison': double free or corruption (!prev): 0x0085c380 
> ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f6ba63ca7e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7f6ba63d2e0a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6ba63d698c]
> /lib/x86_64-linux-gnu/libc.so.6(fclose+0x103)[0x7f6ba63c0363]
> bison[0x407b34]
> bison[0x40ec3a]
> bison[0x40ed37]
> bison[0x4012e4]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6ba6373830]
> bison[0x4013d4]
> === Memory map: 
> [...]
> "[...]/thrift/compiler/cpp/src/thrift/thrifty.yy", line 1: junk after `%%' in 
> definition section
> "[...]/thrift/compiler/cpp/src/thrift/thrifty.yy", line 1: no input grammar
> ../../../ylwrap : ligne 174 :  3041 Abandon (core dumped) 
> "$prog" "$@" "$input"
> Makefile:908 : la recette pour la cible « thrift/thrifty.cc » a échouée
> [...]
> A git bisect search indicates that:
> 330b3f814a33ab8a740fca4da29106bd7e219b1d is the first bad commit
> commit 330b3f814a33ab8a740fca4da29106bd7e219b1d
> Author: James E. King, III 
> Date:   Mon Jan 23 08:52:04 2017 -0500
> THRIFT-4034 compiler build fixes for macos sierra and some cmake cleanup 
> for compiler
> Compiler
> Patch: Robert Lu 
> 
> This closes #1161
> :100755 100755 e7ab87d35ef566143e83f9bf4aecb4fa741a8ceb 
> 82ce366ab3663f4881e3ef3549beec1ff96d5dac Mappveyor.yml
> :04 04 69fc0bea59360f17a92304fd5ecc85993a757db7 
> 88a3617a0a66a1d28440121e4f47e0eec4ff993f Mcompiler



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

[jira] [Updated] (THRIFT-4200) commit THRIFT-4034 makes bison++ 1.21 crash

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-4200:
-
Priority: Minor  (was: Blocker)

> commit THRIFT-4034 makes bison++ 1.21 crash
> ---
>
> Key: THRIFT-4200
> URL: https://issues.apache.org/jira/browse/THRIFT-4200
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.11.0
> Environment: - Linux 4.4.0-72-generic #93-Ubuntu SMP x86_64 x86_64 
> x86_64 GNU/Linux
> - Ubuntu 16.04.2 LTS xenial
> - bison++ 1.21.11-3.1 (as claimed by `dpkg -l bison*`) or 1.21.9-1 (as 
> claimed by `bison++ --version`)
> - dpkg -l g++: g++ 4:5.3.1-1ubuntu1 / g++ --version: g++ (Ubuntu 
> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> - cmake 3.5.1-1ubuntu3
>Reporter: nojhan
>Priority: Minor
>
> When trying to build a freshly cloned Thrift repository:
> ./bootstrap.sh
> ./configure
> make
> It ends on this error:
> [...]
> /bin/bash ../../../ylwrap thrift/thrifty.yy y.tab.c thrift/thrifty.cc y.tab.h 
> `echo thrift/thrifty.cc | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e 
> s/c++$/h++/ -e s/c$/h/` y.output thrift/thrifty.output -- bison -y -d 
> *** Error in `bison': double free or corruption (!prev): 0x0085c380 
> ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f6ba63ca7e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7f6ba63d2e0a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6ba63d698c]
> /lib/x86_64-linux-gnu/libc.so.6(fclose+0x103)[0x7f6ba63c0363]
> bison[0x407b34]
> bison[0x40ec3a]
> bison[0x40ed37]
> bison[0x4012e4]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6ba6373830]
> bison[0x4013d4]
> === Memory map: 
> [...]
> "[...]/thrift/compiler/cpp/src/thrift/thrifty.yy", line 1: junk after `%%' in 
> definition section
> "[...]/thrift/compiler/cpp/src/thrift/thrifty.yy", line 1: no input grammar
> ../../../ylwrap : ligne 174 :  3041 Abandon (core dumped) 
> "$prog" "$@" "$input"
> Makefile:908 : la recette pour la cible « thrift/thrifty.cc » a échouée
> [...]
> A git bisect search indicates that:
> 330b3f814a33ab8a740fca4da29106bd7e219b1d is the first bad commit
> commit 330b3f814a33ab8a740fca4da29106bd7e219b1d
> Author: James E. King, III 
> Date:   Mon Jan 23 08:52:04 2017 -0500
> THRIFT-4034 compiler build fixes for macos sierra and some cmake cleanup 
> for compiler
> Compiler
> Patch: Robert Lu 
> 
> This closes #1161
> :100755 100755 e7ab87d35ef566143e83f9bf4aecb4fa741a8ceb 
> 82ce366ab3663f4881e3ef3549beec1ff96d5dac Mappveyor.yml
> :04 04 69fc0bea59360f17a92304fd5ecc85993a757db7 
> 88a3617a0a66a1d28440121e4f47e0eec4ff993f Mcompiler



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

Re: [VOTE]: Move from legacy asf git to Apache GitBox

[Aki Sukegawa]

+1

On Wed, Mar 21, 2018, 10:27 PM Duru Can Celasun  wrote:

> +1
>
> On Wed, 21 Mar 2018, at 13:18, James E. King, III wrote:
> > Apache GitBox provides the Thrift project more control over the lifecycle
> > of pull requests and improve the team's ability to get things done in a
> > timely manner.  The goal is to improve team self-service in GitHub and
> > integrated CI workflows.  One important improvement for committers is
> that
> > it allows them to "Rebase and Merge" directly in GitHub, assuming the
> > commit description meets published guidelines.It also allows for more
> > control over GitHub features such as issues (note there are no plans to
> > switch from Apache Hira to GitHub Issues right now), and it allows pull
> > requests to be assigned to committers and labelled.
> >
> > I found one discussion link for reference from another Apache project
> > considering conversion back in July 2017:
> >
> >
> http://apache-nifi.1125220.n5.nabble.com/DISCUSS-Apache-Gitbox-td18273.html
> >
> > Please VOTE:
> >
> > [ ] +1 Move to Apache GitBox
> > [ ] +0
> > [ ] -1 Don't move to  Apache  GitBox because...
> >
> > Voting will end in 72 hours (excluding the weekend), March 26, 2018 at
> > 9:00:00 AM EDT
> > https://www.timeanddate.com/countdown/to?iso=20180326T09
> >
> > - Jim King (PMC Member)
>

Re: History of testOneway sleep?

[Aki Sukegawa]

The point of the test is that the client returns immediately while the
server is blocking. Removing server sleeps would let incorrect oneway
client implementations pass the test.

The server process is killed at the end so ideally we could avoid waiting
for the sleep. But in reality I think for many test servers we end up
waiting for the sleep before the subsequent RPC processing because they are
single-threaded.

On Sun, Nov 19, 2017 at 2:16 AM James E. King, III  wrote:

> Does anybody know why the cross tests have a built-in sleep in the one-way
> test?  This slows down every test, seemingly unnecessarily.  When I removed
> it from the cpp tests, the cpp server tests all zoom along nicely.  It's
> present in c_glib server, for example, and also in go, and probably
> others.  If we don't need all the tests to be sleeping 1 second, we should
> remove all the sleeping to speed up the tests.  We do 2,000+ cross tests,
> so that's a lot of sleep.
>

[jira] [Commented] (THRIFT-4256) Dependency on very old version of vector library

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4256:
--

It is because of a change in show introduced in vector 0.11. Admittedly it does 
not need to be exact 0.10.2, though.
https://github.com/haskell/vector/issues/87

Note that our CI uses GHC 7.6 or something old which does not support 
OverloadedLists. Those who are on newer GHC wouldn't experience the issue.
We would need to put version check for GHC to switch vector version constraint 
in thrift.cabal.


> Dependency on very old version of vector library
> 
>
> Key: THRIFT-4256
> URL: https://issues.apache.org/jira/browse/THRIFT-4256
> Project: Thrift
>  Issue Type: Improvement
>  Components: Haskell - Library
>Reporter: Tom Lippincott
>Priority: Minor
>
> Currently, Thrift.cabal has an exact dependency of vector==0.10.12.2, but 
> this version is much, much older than what other packages depend on.  This 
> makes it necessary to enable "allow-newer", which effectively ignores the 
> dependency, and then breaks when a package is uploaded to hackage, and 
> prevents inclusion of thrift in a stack curated package set.
> If there's no particular reason for it (and I've been successfully compiling 
> thrift with vector==0.12.0.2), could this dependency be set to a range, .e.g. 
> >=0.12.0?  I could then enter a request for thrift to be added to stack's 
> curated package sets.



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

[jira] [Comment Edited] (THRIFT-4026) TSSLSocket doesn't work with Python < 2.7.9

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-4026 at 3/19/17 2:19 AM:
---

[~jbapple] In our CI job #8, we're running make check on Python 2.7.6 with 
these two packages.
Does {{import ipaddress}} and {{import backports.ssl_match_hostname}} work on 
your environment ?


was (Author: nsuke):
[~jbapple] In our CI job #8, we're running make check on Python 2.7.6 with 
these two packages.
Does {{import ipaddress}} and {{import backports.ssl_match_hostname}} work on 
your environment ?

A test case skip logic might be flawed, it only checks availability of 
{{ipaddress}} while we need {{match_hostname}} too.

> TSSLSocket doesn't work with Python < 2.7.9
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Assignee: Aki Sukegawa
> Fix For: 0.11.0
>
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Comment Edited] (THRIFT-4026) TSSLSocket doesn't work with Python < 2.7.9

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-4026 at 3/19/17 2:12 AM:
---

[~jbapple] In our CI job #8, we're running make check on Python 2.7.6 with 
these two packages.
Does {{import ipaddress}} and {{import backports.ssl_match_hostname}} work on 
your environment ?

A test case skip logic might be flawed, it only checks availability of 
{{ipaddress}} while we need {{match_hostname}} too.


was (Author: nsuke):
[~jbapple] In our CI job #8, we're running make check on Python 2.7.6 with 
these two packages.
Does {{import ipaddress}} and {{import backports.ssl_match_hostname}} work on 
your environment ?

> TSSLSocket doesn't work with Python < 2.7.9
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Assignee: Aki Sukegawa
> Fix For: 0.11.0
>
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Commented] (THRIFT-4026) TSSLSocket doesn't work with Python < 2.7.9

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4026:
--

[~jbapple] In our CI job #8, we're running make check on Python 2.7.6 with 
these two packages.
Does {{import ipaddress}} and {{import backports.ssl_match_hostname}} work on 
your environment ?

> TSSLSocket doesn't work with Python < 2.7.9
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Assignee: Aki Sukegawa
> Fix For: 0.11.0
>
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Comment Edited] (THRIFT-4026) TSSLSocket doesn't work with Python < 2.7.9

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-4026 at 3/19/17 1:29 AM:
---

[~jbapple] are you verifying client certificates on server side ?
In that case, it is more of a problem of the error message and documentation.
On older versions of Python, you "Need ipaddress and 
backports.ssl_match_hostname module to verify client certificate."
IOW you need to install the two packages, e.g., using PIP.


was (Author: nsuke):
[~jbapple] are you verifying client certificates on server side ?
In that case, it is more of a problem of the error message and documentation.
You "Need ipaddress and backports.ssl_match_hostname module to verify client 
certificate."
IOW you need to install the two packages, e.g., using PIP.

> TSSLSocket doesn't work with Python < 2.7.9
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>    Reporter: Benoit Sigoure
>Assignee: Aki Sukegawa
> Fix For: 0.11.0
>
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Commented] (THRIFT-4026) TSSLSocket doesn't work with Python < 2.7.9

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4026:
--

[~jbapple] are you verifying client certificates on server side ?
In that case, it is more of a problem of the error message and documentation.
You "Need ipaddress and backports.ssl_match_hostname module to verify client 
certificate."
IOW you need to install the two packages, e.g., using PIP.

> TSSLSocket doesn't work with Python < 2.7.9
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Assignee: Aki Sukegawa
> Fix For: 0.11.0
>
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Commented] (THRIFT-4095) Add multiplexed and other missing protocols to Travis CI

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4095:
--

[~jking3] tests for header servers are included in our CI.
https://travis-ci.org/apache/thrift/jobs/201991012#L7702
They are located in test/features and can be run by test/test.py --features or 
make crossfeature
I'm afraid that the only documentation available is a single sentence in 
test/test.py --help .

To add tests to existing or new jobs, any contributor or committer can edit 
.travis-ci.yml and issue a pull request.

> Add multiplexed and other missing protocols to Travis CI
> 
>
> Key: THRIFT-4095
> URL: https://issues.apache.org/jira/browse/THRIFT-4095
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process
>Affects Versions: 0.11.0
> Environment: Travis CI
>Reporter: James E. King, III
>Assignee: Jake Farrell
>
> In THRIFT-3706 someone wants to contribute our first set of multiplexed cross 
> tests (c_glib client, java server).  These need to be represented in our 
> Travis CI builds, where we are limiting the protocols we test to keep build 
> jobs in a time box.
> Currently we have the following four build jobs running crosstest:
> * #1 uses the ubuntu image and runs "binary|header" on everything except 
> netcore and rust
> * #2 uses the debian image and does the same as #1
> * #3 uses the ubuntu image and runs "compact|json" on everything except 
> netcore and rust
> * #4 uses the debian image and does the same as #3
> The following protocols are not represented in the Travis CI builds and 
> should be added:
> * header
> * multiplexed
> There are not many of these.  They could be added to build job #2 which seems 
> to have enough headroom to run the few extra tests this would generate.



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

[jira] [Commented] (THRIFT-4089) Several issues with generated Python code: TFrozenDict, _fast_encode

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4089:
--

[~mvartak] no, Thrift runtime.
If you can locate Thrift.py you're importing, it should look like 
https://github.com/apache/thrift/blob/0.10.0/lib/py/src/Thrift.py if it is from 
correct version.
TFrozenDict is in this file.

> Several issues with generated Python code: TFrozenDict, _fast_encode
> 
>
> Key: THRIFT-4089
> URL: https://issues.apache.org/jira/browse/THRIFT-4089
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Affects Versions: 0.10.0
> Environment: Python 2.7, 3.5. OS-X
>Reporter: Manasi Vartak
>
> When you generate Python sources for a simple thrift file (e.g. Thrift 
> tutorial from https://thrift.apache.org/tutorial/py will also repro erros), 
> errors are thrown while running the PythonServer and PythonClient.
> 1.  When running the vanilla PythonServer, I get the following error:
> File "gen-py/shared/SharedService.py", line 9, in 
> from thrift.Thrift import TType, TMessageType, TFrozenDict, TException, 
> TApplicationException 
> ImportError: cannot import name TFrozenDict
> I see this error consistently for all generated thrift files. The error 
> disappears on removing TFrozenDict from the generated files (it is not used 
> anywhere in the file).
> 2. When running the vanilla PythonClient (the server is now running after the 
> above fix), I get the following error:
>  File "PythonClient.py", line 51, in main
> client.ping()
>   File "gen-py/tutorial/Calculator.py", line 73, in ping
> self.send_ping()
>   File "gen-py/tutorial/Calculator.py", line 79, in send_ping
> args.write(self._oprot)
>   File "gen-py/tutorial/Calculator.py", line 297, in write
> if oprot._fast_encode is not None and self.thrift_spec is not None:
> AttributeError: TBinaryProtocol instance has no attribute '_fast_encode'
> I am not sure why this error is being thrown/what can be done to fix it.
> These two errors, and mainly the latter one, are rendering the Server/Client 
> un-usable. Is this a known issue? And how do you recommend working around it?



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

[jira] [Commented] (THRIFT-4089) Several issues with generated Python code: TFrozenDict, _fast_encode

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4089:
--

Sounds like version mismatch between compiler and library: 0.10.0 compiler 
against older python lib.

> Several issues with generated Python code: TFrozenDict, _fast_encode
> 
>
> Key: THRIFT-4089
> URL: https://issues.apache.org/jira/browse/THRIFT-4089
> Project: Thrift
>  Issue Type: Bug
>Affects Versions: 0.10.0
> Environment: Python 2.7. OS-X
>Reporter: Manasi Vartak
>
> When you generate Python sources for a simple thrift file (e.g. Thrift 
> tutorial from https://thrift.apache.org/tutorial/py will also repro erros), 
> errors are thrown while running the PythonServer and PythonClient.
> 1.  When running the vanilla PythonServer, I get the following error:
> File "gen-py/shared/SharedService.py", line 9, in 
> from thrift.Thrift import TType, TMessageType, TFrozenDict, TException, 
> TApplicationException 
> ImportError: cannot import name TFrozenDict
> I see this error consistently for all generated thrift files. The error 
> disappears on removing TFrozenDict from the generated files (it is not used 
> anywhere in the file).
> 2. When running the vanilla PythonClient (the server is now running after the 
> above fix), I get the following error:
>  File "PythonClient.py", line 51, in main
> client.ping()
>   File "gen-py/tutorial/Calculator.py", line 73, in ping
> self.send_ping()
>   File "gen-py/tutorial/Calculator.py", line 79, in send_ping
> args.write(self._oprot)
>   File "gen-py/tutorial/Calculator.py", line 297, in write
> if oprot._fast_encode is not None and self.thrift_spec is not None:
> AttributeError: TBinaryProtocol instance has no attribute '_fast_encode'
> I am not sure why this error is being thrown/what can be done to fix it.
> These two errors, and mainly the latter one, are rendering the Server/Client 
> un-usable. Is this a known issue? And how do you recommend working around it?



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

[jira] [Updated] (THRIFT-4026) TSSLSocket doesn't work with Python < 2.7.9

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-4026:
-
Summary: TSSLSocket doesn't work with Python < 2.7.9  (was: TSSLSocket 
doesn't work with Python 2.7)

> TSSLSocket doesn't work with Python < 2.7.9
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Priority: Critical
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Commented] (THRIFT-4026) TSSLSocket doesn't work with Python 2.7

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-4026:
--

[~tsuna] thanks, it seems indeed a bug.

For anyone who wants to workaround this without managing local patch/fork or 
upgrading to python >= 2.7.9,
a recommended workaround is to install backports.ssl_match_hostname package.


> TSSLSocket doesn't work with Python 2.7
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Priority: Critical
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Assigned] (THRIFT-4026) TSSLSocket doesn't work with Python < 2.7.9

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa reassigned THRIFT-4026:


Assignee: Aki Sukegawa

> TSSLSocket doesn't work with Python < 2.7.9
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Assignee: Aki Sukegawa
>Priority: Critical
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a 
> {{TypeError}} in {{open()}}:
> {code}
>   File 
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
>  line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, 
> which cannot possibly be compatible with the signature of 
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
>  (which was added in Python 3.2).



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

[jira] [Updated] (THRIFT-4030) CI jobs do not reuse downloaded docker images

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-4030:
-
Summary: CI jobs do not reuse downloaded docker images  (was: CI jobs does 
not reuse downloaded docker images)

> CI jobs do not reuse downloaded docker images
> -
>
> Key: THRIFT-4030
> URL: https://issues.apache.org/jira/browse/THRIFT-4030
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>    Reporter: Aki Sukegawa
>Priority: Minor
>
> The main motivation for me to introduce this script was to avoid docker build 
> which was failing to often due to occasional apt download failures.
> But for some unknown reason apt is not failing any longer.



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

[jira] [Updated] (THRIFT-4030) CI jobs does not reuse downloaded docker images

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-4030:
-
Description: 
The main motivation for me to introduce this script was to avoid docker build 
which was failing to often due to occasional apt download failures.
But for some unknown reason apt is not failing any longer.



> CI jobs does not reuse downloaded docker images
> ---
>
> Key: THRIFT-4030
> URL: https://issues.apache.org/jira/browse/THRIFT-4030
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>    Reporter: Aki Sukegawa
>Priority: Minor
>
> The main motivation for me to introduce this script was to avoid docker build 
> which was failing to often due to occasional apt download failures.
> But for some unknown reason apt is not failing any longer.



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

[jira] [Created] (THRIFT-4030) CI jobs does not reuse downloaded docker images

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-4030:


 Summary: CI jobs does not reuse downloaded docker images
 Key: THRIFT-4030
 URL: https://issues.apache.org/jira/browse/THRIFT-4030
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Reporter: Aki Sukegawa
Priority: Minor






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

[jira] [Comment Edited] (THRIFT-3886) PHP cross test client returns 0 even when failing

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-3886 at 12/3/16 5:53 AM:
---

[~jensg] sorry, I've overlooked your comment too.
It's fine, this one is on top of my commit and covers much more cases.
A sub-task for the commit might have been cleaner, though.

[~hakon] I realised that this one is effectvely a test case for the other patch 
THRIFT-3348.
Can you rebase or merge your pull request on master so that we can see them 
succeed on CI ?


was (Author: nsuke):
[~jensg] sorry, I've overlooked your comment too.
It's fine, this one is on top of my commit and covers much more cases.
A sub-task for the commit might have been cleaner, though.

edit:
[~hakon] I realised that this one is effectvely a test case for the other patch 
THRIFT-3348.
Can you rebase or merge your pull request on master ?

> PHP cross test client returns 0 even when failing
> -
>
> Key: THRIFT-3886
> URL: https://issues.apache.org/jira/browse/THRIFT-3886
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library, Test Suite
>    Reporter: Aki Sukegawa
>
> PHP cross test client never fails on invalid values.
> update:
> Results for primitive values are now validated after PR #1054.
> Structs, containers, etc are still affected.



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

[jira] [Comment Edited] (THRIFT-3886) PHP cross test client returns 0 even when failing

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-3886 at 12/3/16 5:52 AM:
---

[~jensg] sorry, I've overlooked your comment too.
It's fine, this one is on top of my commit and covers much more cases.
A sub-task for the commit might have been cleaner, though.

edit:
[~hakon] I realised that this one is effectvely a test case for the other patch 
THRIFT-3348.
Can you rebase or merge your pull request on master ?


was (Author: nsuke):
[~jensg] sorry, I've overlooked your comment too.
It's fine, this one is on top of my commit and covers much more cases.
A sub-task for the commit might have been cleaner, though.

[~hakon] the failures seem to be Compact protocol tests for 
`-9223372036854775808`.
It turned out that PHP Compact protocol is turning that particular value into a 
floating point on PHP 5.5.
Will merge yours after fixing it.

> PHP cross test client returns 0 even when failing
> -
>
> Key: THRIFT-3886
> URL: https://issues.apache.org/jira/browse/THRIFT-3886
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library, Test Suite
>    Reporter: Aki Sukegawa
>
> PHP cross test client never fails on invalid values.
> update:
> Results for primitive values are now validated after PR #1054.
> Structs, containers, etc are still affected.



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

[jira] [Commented] (THRIFT-3886) PHP cross test client returns 0 even when failing

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3886:
--

[~jensg] sorry, I've overlooked your comment too.
It's fine, this one is on top of my commit and covers much more cases.
A sub-task for the commit might have been cleaner, though.

[~hakon] the failures seem to be Compact protocol tests for 
`-9223372036854775808`.
It turned out that PHP Compact protocol is turning that particular value into a 
floating point on PHP 5.5.
Will merge yours after fixing it.

> PHP cross test client returns 0 even when failing
> -
>
> Key: THRIFT-3886
> URL: https://issues.apache.org/jira/browse/THRIFT-3886
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library, Test Suite
>    Reporter: Aki Sukegawa
>
> PHP cross test client never fails on invalid values.
> update:
> Results for primitive values are now validated after PR #1054.
> Structs, containers, etc are still affected.



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

[jira] [Updated] (THRIFT-3207) Enable build with OpenSSL 1.1.x

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3207:
-
Summary: Enable build with OpenSSL 1.1.x  (was: Enable build with OpenSSL 
pre 1.1.0)

> Enable build with OpenSSL 1.1.x
> ---
>
> Key: THRIFT-3207
> URL: https://issues.apache.org/jira/browse/THRIFT-3207
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: Paweł Janicki
>Priority: Minor
>  Labels: easyfix
> Attachments: THRIFT-3207.patch
>
>
> As thrift requires OpenSSL v1.1.0 there are still some problems with 
> compiling latest official releases on Visual Studio 2013. We falled back to 
> other OpenSSL releases that source version can be compiled without problems.
> Unfortunately Thrift can not be build against OpenSSL pre 1.1.0 due to 
> missing TLSv1_1_method() and TLSv1_2_method().
> While OpenSSL in version 0.9.8 and 1.0.0 is supported till 
> [2015-12-31|https://www.openssl.org/about/releasestrat.html] and Open SSL in 
> version 1.0.1 and 1.0.2 is supported till 
> [2016-12-31|https://www.openssl.org/about/releasestrat.html] we found 
> reasonable to enable this releases to be used for Thrift builds.
> The proposed patch enables Thrift support of TLS 1.1 and 1.2 only when build 
> with OpenSSL 1.1.0 or newer.



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

[jira] [Resolved] (THRIFT-3829) Thrift does not install Python Libraries if Twisted is not installed

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3829.
--
   Resolution: Fixed
 Assignee: Aki Sukegawa
Fix Version/s: 0.10.0

Twisted hard requirement was lifted as part of THRIFT-3910 patch.

> Thrift does not install Python Libraries if Twisted is not installed
> 
>
> Key: THRIFT-3829
> URL: https://issues.apache.org/jira/browse/THRIFT-3829
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.3
> Environment: MAC OSX EL-CAPITAN
> 10.11.3
>Reporter: Souvik Ray
>Assignee: Aki Sukegawa
> Fix For: 0.10.0
>
>
> python --version
> Python 2.7.10



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

[jira] [Updated] (THRIFT-3829) Thrift does not install Python Libraries if Twisted is not installed

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3829:
-
Summary: Thrift does not install Python Libraries if Twisted is not 
installed  (was: Thrift does not install Python Libraries in MAC)

> Thrift does not install Python Libraries if Twisted is not installed
> 
>
> Key: THRIFT-3829
> URL: https://issues.apache.org/jira/browse/THRIFT-3829
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.3
> Environment: MAC OSX EL-CAPITAN
> 10.11.3
>Reporter: Souvik Ray
>
> python --version
> Python 2.7.10



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

[jira] [Commented] (THRIFT-3979) offer TExtendedBinaryProtocol for customers

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3979:
--

[~in-chief] as to your first question, Header protocol servers are compatible 
with Binary and Compact protocol clients.

> offer TExtendedBinaryProtocol for customers
> ---
>
> Key: THRIFT-3979
> URL: https://issues.apache.org/jira/browse/THRIFT-3979
> Project: Thrift
>  Issue Type: Story
>  Components: Wish List
>Affects Versions: 0.9.3
>Reporter: Xiaoshuang LU
>
> Sometimes, customers wanna put some options (username, password, id, etc.) in 
> each request and response. And these options ought to be transparent for 
> applications.
> Unfortunately, thrift protocol does not have good extensibility for extra 
> functionalities. I would like to propose the following solution to address 
> this issue.
> 1. TMessage adds a new field called "options"
> 2. customers set "options"
> 3. TExtendedBinaryProtocol writes "options" when "writeMessageBegin" invoked
> 4. TExtendedBinaryProtocol reads "options" when "readMessageBegin" invoked



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

[jira] [Commented] (THRIFT-3828) cmake fails when Boost_INCLUDE_DIRS (and other variables passed to include_directories()) is empty

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3828:
--

[~jking3] Looks like github comment edits do not come down here.
I'm using CMake 3.6.3.

According to [an upstream bug 
report|https://gitlab.kitware.com/cmake/cmake/issues/16291]:

{quote}
This didn't break the 99% of the standard builds (...) But when cross-compiling 
or when using a non-default system include directory, the build breaks.
{quote}
[~codyps] are you cross compiling or using non-default system includes ?

As to the workaround, I think we should avoid removing SYSTEM as much as we 
can, since it can lead to bloated warnings from external library headers.

WebKit project conceived a workaround for this without removing SYSTEM.
http://trac.webkit.org/changeset/205672/trunk/Source/cmake/OptionsCommon.cmake
https://bugs.webkit.org/show_bug.cgi?id=161697

> cmake fails when Boost_INCLUDE_DIRS (and other variables passed to 
> include_directories()) is empty 
> ---
>
> Key: THRIFT-3828
> URL: https://issues.apache.org/jira/browse/THRIFT-3828
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Reporter: Cody Schafer
>Assignee: James E. King, III
>Priority: Minor
> Attachments: 
> 0001-cmake-avoid-use-of-both-quoted-paths-and-SYSTEM-with.patch
>
>
> This is due to the current quoting of those variables when passed to 
> `include_directories()`. These variables may (and soon will, see below) be 
> empty in the case where the include directory is a system include path that 
> is implicitly included.
> I ran into this issue when trying to build thrift using gcc-6. gcc-6 doesn't 
> work with includes that are part of the platform/system include path (see 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 for one mention). To 
> resolve this, `FindBoost.cmake` will be adjusted to avoid adding those types 
> of directories to Boost_INCLUDE_DIRS.



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

[jira] [Commented] (THRIFT-3972) Remove unused mutex code from the C++ library to reduce the maintenance overhead of the project

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3972:
--

I've seen some usages in the past.
It seems that Hive and in turn Impala are using this.

> Remove unused mutex code from the C++ library to reduce the maintenance 
> overhead of the project
> ---
>
> Key: THRIFT-3972
> URL: https://issues.apache.org/jira/browse/THRIFT-3972
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> As part of looking into THRIFT-3038 a couple of unused classes were 
> identified, and it was suggested we use a different ticket to track their 
> removal:
> NoStarveReadWriteMutex
> ReadWriteMutex
> RWGuard
> Thrift's mission is to make cross-platform/cross-language RPC easy and not to 
> provide a cross-platform concurrency library, so there is no need to keep 
> unused concurrency related code in the project.



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

[jira] [Commented] (THRIFT-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3891:
--

A couple of comments:

1. Instead of adding isEventInitialized_ flag, {{if (eventFlags_ != 0)}} can do 
basically the same thing.
eventFlags_ avoids more unecessary cases although double event_del is harmless 
according to the doc.

2. After that we synchronize initialization using isStopRequested_, we no 
longer need to replace event_base_loopbreak with event_base_loopexit ?

> TNonblockingServer configured with more than one IO threads does not always 
> return from serve() upon stop()
> ---
>
> Key: THRIFT-3891
> URL: https://issues.apache.org/jira/browse/THRIFT-3891
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Buğra Gedik
>Priority: Minor
> Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is 
> race condition in which {{stop()}} does not properly unblock {{serve()}}. 
> The problem manifests itself when {{stop()}} is called (obviously from a 
> different thread) soon after {{serve()}}. 
> The core issue is that, {{event_base_loopbreak()}} is called within the 
> {{stop()}} sequence without checking whether the IO thread has actually 
> entered its event loop. The documentation of {{event_base_loopbreak()}} says 
> (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base) 
> act differently when no event loop is running: loopexit schedules the next 
> instance of the event loop to stop right after the next round of callbacks 
> are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only 
> stops a currently running loop, and has no effect if the event loop isn’t 
> running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).



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

[jira] [Comment Edited] (THRIFT-3965) VisualStudio project cannot build compiler CPP project

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-3965 at 11/10/16 1:06 AM:


FWIW it's not stale right now (see THRIFT-2155 ).
\+1 for removing both VC++ projects nonetheless. We don't need 3 build systems.


was (Author: nsuke):
FWIW it's not stale right now (see THRIFT-2155 ).
+1 for removing both VC++ projects nonetheless. We don't need 3 build systems.

> VisualStudio project cannot build compiler CPP project
> --
>
> Key: THRIFT-3965
> URL: https://issues.apache.org/jira/browse/THRIFT-3965
> Project: Thrift
>  Issue Type: Bug
>  Components: Compiler (General)
> Environment: Microsoft Visual Studio Enterprise 2015
> Version 14.0.25123.00 Update 2
> Microsoft .NET Framework
> Version 4.6.01055
> Installed Version: Enterprise
> Architecture and Modeling Tools   00322-8-0-AA924
> Microsoft Architecture and Modeling Tools
> 
> UML® and Unified Modeling Language™ are trademarks or registered trademarks 
> of the Object Management Group, Inc. in the United States and other countries.
> Visual Basic 2015   00322-8-0-AA924
> Microsoft Visual Basic 2015
> Visual C# 2015   00322-8-0-AA924
> Microsoft Visual C# 2015
> Visual C++ 2015   00322-8-0-AA924
> Microsoft Visual C++ 2015
> Application Insights Tools for Visual Studio Package   5.209.60613.1
> Application Insights Tools for Visual Studio
> ASP.NET and Web Tools 2015.1 (Beta8)   14.1.11106.0
> ASP.NET and Web Tools 2015.1 (Beta8)
> ASP.NET Web Frameworks and Tools 2012.2   4.1.41102.0
> For additional information, visit 
> http://go.microsoft.com/fwlink/?LinkID=309563
> ASP.NET Web Frameworks and Tools 2013   5.2.40314.0
> For additional information, visit http://www.asp.net/
> Common Azure Tools   1.7
> Provides common services for use by Azure Mobile Services and Microsoft Azure 
> Tools.
> JavaScript Language Service   2.0
> JavaScript Language Service
> JavaScript Project System   2.0
> JavaScript Project System
> Microsoft Azure Mobile Services Tools   1.4
> Microsoft Azure Mobile Services Tools
> NuGet Package Manager   3.4.4
> NuGet Package Manager in Visual Studio. For more information about NuGet, 
> visit http://docs.nuget.org/.
> PreEmptive Analytics Visualizer   1.2
> Microsoft Visual Studio extension to visualize aggregated summaries from the 
> PreEmptive Analytics product.
> SQL Server Data Tools   14.0.60311.1
> Microsoft SQL Server Data Tools
> TypeScript   1.8.31.0
> TypeScript tools for Visual Studio
>Reporter: Gary Gregory
>Assignee: James E. King, III
>  Labels: Windows
>
> Based on the current git master branch.
> The project's {{t_generator.h}} want to use the header file {{version.h}}:
> {code}
> #include "thrift/version.h"
> {code}
> The file does not exist but {{version.h.in}} is there and looks to be 
> expected by the CMake build's {{CMakeLists.txt}}:
> {code}
> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/src/thrift/version.h.in 
> ${CMAKE_CURRENT_BINARY_DIR}/thrift/version.h)
> {code}
> As a workaround I just copied {{version.h.in}} to {{version.h}}.
> It would be nice to fix this.



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

[jira] [Commented] (THRIFT-3965) VisualStudio project cannot build compiler CPP project

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3965:
--

FWIW it's not stale right now (see THRIFT-2155 ).
+1 for removing both VC++ projects nonetheless. We don't need 3 build systems.

> VisualStudio project cannot build compiler CPP project
> --
>
> Key: THRIFT-3965
> URL: https://issues.apache.org/jira/browse/THRIFT-3965
> Project: Thrift
>  Issue Type: Bug
>  Components: Compiler (General)
> Environment: Microsoft Visual Studio Enterprise 2015
> Version 14.0.25123.00 Update 2
> Microsoft .NET Framework
> Version 4.6.01055
> Installed Version: Enterprise
> Architecture and Modeling Tools   00322-8-0-AA924
> Microsoft Architecture and Modeling Tools
> 
> UML® and Unified Modeling Language™ are trademarks or registered trademarks 
> of the Object Management Group, Inc. in the United States and other countries.
> Visual Basic 2015   00322-8-0-AA924
> Microsoft Visual Basic 2015
> Visual C# 2015   00322-8-0-AA924
> Microsoft Visual C# 2015
> Visual C++ 2015   00322-8-0-AA924
> Microsoft Visual C++ 2015
> Application Insights Tools for Visual Studio Package   5.209.60613.1
> Application Insights Tools for Visual Studio
> ASP.NET and Web Tools 2015.1 (Beta8)   14.1.11106.0
> ASP.NET and Web Tools 2015.1 (Beta8)
> ASP.NET Web Frameworks and Tools 2012.2   4.1.41102.0
> For additional information, visit 
> http://go.microsoft.com/fwlink/?LinkID=309563
> ASP.NET Web Frameworks and Tools 2013   5.2.40314.0
> For additional information, visit http://www.asp.net/
> Common Azure Tools   1.7
> Provides common services for use by Azure Mobile Services and Microsoft Azure 
> Tools.
> JavaScript Language Service   2.0
> JavaScript Language Service
> JavaScript Project System   2.0
> JavaScript Project System
> Microsoft Azure Mobile Services Tools   1.4
> Microsoft Azure Mobile Services Tools
> NuGet Package Manager   3.4.4
> NuGet Package Manager in Visual Studio. For more information about NuGet, 
> visit http://docs.nuget.org/.
> PreEmptive Analytics Visualizer   1.2
> Microsoft Visual Studio extension to visualize aggregated summaries from the 
> PreEmptive Analytics product.
> SQL Server Data Tools   14.0.60311.1
> Microsoft SQL Server Data Tools
> TypeScript   1.8.31.0
> TypeScript tools for Visual Studio
>Reporter: Gary Gregory
>Assignee: James E. King, III
>  Labels: Windows
>
> Based on the current git master branch.
> The project's {{t_generator.h}} want to use the header file {{version.h}}:
> {code}
> #include "thrift/version.h"
> {code}
> The file does not exist but {{version.h.in}} is there and looks to be 
> expected by the CMake build's {{CMakeLists.txt}}:
> {code}
> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/src/thrift/version.h.in 
> ${CMAKE_CURRENT_BINARY_DIR}/thrift/version.h)
> {code}
> As a workaround I just copied {{version.h.in}} to {{version.h}}.
> It would be nice to fix this.



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

Re: [VOTE] Apache Thrift 0.10.0-rc0 release candidate

[Aki Sukegawa]

Just in case it wasn't clear, it's filed as THRIFT-3949 and fixed in master.

On Fri, Oct 21, 2016, 19:51 Roger Meier <ro...@bufferoverflow.ch> wrote:

> I agree with Aki, this should be fixed.
>
> -roger
>
> Quoting Aki Sukegawa <ns...@apache.org>:
>
> > -1
> >
> > CMake configuration fails due to missing compiler/cpp/test directory in
> > source tar ball.
> > Sorry, this should have added to EXTRA_DIST in THRIFT-2835 but I
> overlooked
> > this.
> > A patch is on the way.
> >
> > On Wed, Oct 19, 2016 at 11:09 AM Jake Farrell <jfarr...@apache.org>
> wrote:
> >
> >> All,
> >> I propose that we accept the following release candidate as the official
> >> Apache Thrift 0.10.0 release.
> >>
> >>
> >>
> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/thrift-0.10.0-rc0.tar.gz
> >>
> >>
> >> The release candidate was created from the 0.10.0 branch and can be
> >> cloned using:
> >>
> >> git clone -b 0.10.0 https://git-wip-us.apache.org/repos/asf/thrift.git
> >>
> >> The release candidates GPG signature can be found at:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/thrift-0.10.0-rc0.tar.gz.asc
> >>
> >> It has an MD5 sum of 3fbab9c36b2ea84cd443fc2cbff33fb3
> >>
> >> The CHANGES list for this release is available at:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=CHANGES;hb=0.10.0
> >>
> >> Packaged client libraries are available for testing at:
> >> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/lib/
> >>
> >> A prebuilt windows compiler is available at:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/compiler/windows/thrift-0.10.0-rc0.exe
> >>
> >>
> >> Please download, verify sig/sum, install and test the libraries of your
> >> choice.
> >>
> >> This vote will close in 72 hours on Sat Oct 22 03:00:00 UTC 2016.
> >>
> >> [ ] +1 Release this as Apache Thrift 0.10.0
> >> [ ] +0
> >> [ ] -1 Do not release this as Apache Thrift 0.10.0 because...
> >>
> >>
> >> -Jake
> >>
>
>
>

[jira] [Commented] (THRIFT-3775) 0.10.0 release candidate

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3775:
--

[~jfarrell]
Just resolved THRIFT-3949 on master. Can you cherry pick 59cb666 and create a 
new source tarball ?
Very sad to block the process myself, it's really plethora of packages and I 
can only imagine how hard it is.

> 0.10.0 release candidate
> 
>
> Key: THRIFT-3775
> URL: https://issues.apache.org/jira/browse/THRIFT-3775
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Reporter: Jake Farrell
>Assignee: Jake Farrell
>




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

[jira] [Resolved] (THRIFT-3949) missing make dist entry for compiler/cpp/test

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3949.
--
Resolution: Fixed

committed

> missing make dist entry for compiler/cpp/test
> -
>
> Key: THRIFT-3949
> URL: https://issues.apache.org/jira/browse/THRIFT-3949
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process, Compiler (General)
>Affects Versions: 0.10.0
>Reporter: Aki Sukegawa
>    Assignee: Aki Sukegawa
>Priority: Blocker
> Fix For: 0.10.0
>
>
> compiler/cpp/test directory is missing in source tar ball.
> Also modifying CI "make dist" job to do CMake build and test using extracted 
> source tarball too.



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

[jira] [Updated] (THRIFT-3949) missing make dist entry for compiler/cpp/test

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3949:
-
Description: 
compiler/cpp/test directory is missing in source tar ball.

Also modifying CI "make dist" job to do CMake build and test using extracted 
source tarball too.

  was:compiler/cpp/test directory is missing in source tar ball.


> missing make dist entry for compiler/cpp/test
> -
>
> Key: THRIFT-3949
> URL: https://issues.apache.org/jira/browse/THRIFT-3949
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process, Compiler (General)
>Affects Versions: 0.10.0
>Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
>Priority: Blocker
> Fix For: 0.10.0
>
>
> compiler/cpp/test directory is missing in source tar ball.
> Also modifying CI "make dist" job to do CMake build and test using extracted 
> source tarball too.



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

[jira] [Created] (THRIFT-3949) missing make dist entry for compiler/cpp/test

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3949:


 Summary: missing make dist entry for compiler/cpp/test
 Key: THRIFT-3949
 URL: https://issues.apache.org/jira/browse/THRIFT-3949
 Project: Thrift
  Issue Type: Bug
  Components: Build Process, Compiler (General)
Affects Versions: 0.10.0
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa
Priority: Blocker
 Fix For: 0.10.0


compiler/cpp/test directory is missing in source tar ball.



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

Re: [VOTE] Apache Thrift 0.10.0-rc0 release candidate

[Aki Sukegawa]

-1

CMake configuration fails due to missing compiler/cpp/test directory in
source tar ball.
Sorry, this should have added to EXTRA_DIST in THRIFT-2835 but I overlooked
this.
A patch is on the way.

On Wed, Oct 19, 2016 at 11:09 AM Jake Farrell  wrote:

> All,
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.10.0 release.
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/thrift-0.10.0-rc0.tar.gz
>
>
> The release candidate was created from the 0.10.0 branch and can be
> cloned using:
>
> git clone -b 0.10.0 https://git-wip-us.apache.org/repos/asf/thrift.git
>
> The release candidates GPG signature can be found at:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/thrift-0.10.0-rc0.tar.gz.asc
>
> It has an MD5 sum of 3fbab9c36b2ea84cd443fc2cbff33fb3
>
> The CHANGES list for this release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=CHANGES;hb=0.10.0
>
> Packaged client libraries are available for testing at:
> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/lib/
>
> A prebuilt windows compiler is available at:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.10.0/compiler/windows/thrift-0.10.0-rc0.exe
>
>
> Please download, verify sig/sum, install and test the libraries of your
> choice.
>
> This vote will close in 72 hours on Sat Oct 22 03:00:00 UTC 2016.
>
> [ ] +1 Release this as Apache Thrift 0.10.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.10.0 because...
>
>
> -Jake
>

Re: [Announcement]: New Committer - James King

[Aki Sukegawa]

Welcome !

On Wed, Oct 19, 2016, 00:09 Konrad Grochowski  wrote:

Welcome!

gl;hf

-KG


W dniu 2016-10-18 o 14:45, Jake Farrell pisze:
> On behalf of the Apache Thrift PMC, I would like to welcome our newest
> committer to the project:
>
>James King
>
> He has been working to help get builds back on track, contributing quality
> patches, reviewing submitted pull requests, and answering questions on
> the dev and user mailing lists. It is my honor to welcome him as a new
> committer.
>
> Congratulations and thank you for all your hard work
>
> -Jake
>

[jira] [Commented] (THRIFT-3940) Visual Studio project file for compiler is broken

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3940:
--

[~jensg] yes, according to the readme, users need to rename the file.
I didn't change this part of the behavior.

> Visual Studio project file for compiler is broken
> -
>
> Key: THRIFT-3940
> URL: https://issues.apache.org/jira/browse/THRIFT-3940
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process, Compiler (General)
>Affects Versions: 0.10.0
>Reporter: Aki Sukegawa
>    Assignee: Aki Sukegawa
> Fix For: 0.10.0
>
>




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

[jira] [Commented] (THRIFT-3944) TSSLSocket has dead code in checkHandshake

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3944:
--

The patch looks correct.

> If there's a reason that it's there, it needs to be re-implemented.

The code comment says that it is setting BIOs to non-blocking.
Since the socket is set to non-blocking right before this and the BIOs created 
by SSL_set_fd inherit the socket's non-blocking behavior, I don't think there's 
something we need to re-implement.


> TSSLSocket has dead code in checkHandshake
> --
>
> Key: THRIFT-3944
> URL: https://issues.apache.org/jira/browse/THRIFT-3944
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Ted Wang
>Assignee: Ted Wang
>Priority: Minor
>
> There is a block of code in checkHandshake that attempts to set read/write 
> memory bios to be nonblocking. This code doesn't do anything:
> https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/transport/TSSLSocket.cpp#L441
> Here's what this code looks like, and the problems:
> - BIO_new(BIO_s_mem()) creates a new memory BIO. Not sure why.
> - BIO_set_nbio() executes BIO_ctrl(..., BIO_C_SET_NBIO, ...). This errors out 
> and return 0 because mem_ctrl does not have a case for BIO_C_SET_NBIO. See: 
> https://github.com/openssl/openssl/blob/6f0ac0e2f27d9240516edb9a23b7863e7ad02898/crypto/bio/bss_mem.c#L226
> - SSL_set_bio() sets the SSL* to use the memory BIOs.
> - SSL_set_fd() creates a socket BIO, sets the FD on it, and uses 
> SSL_set_bio() to replace the memory BIOs.
> As far as I can tell, this block of code does nothing and will not change 
> functionality. If there's a reason that it's there, it needs to be 
> re-implemented.



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

[jira] [Resolved] (THRIFT-3900) Add Python SSL flags

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3900.
--
   Resolution: Fixed
 Assignee: Charles Hake
Fix Version/s: 0.10.0

Thanks, commited.

> Add Python SSL flags
> 
>
> Key: THRIFT-3900
> URL: https://issues.apache.org/jira/browse/THRIFT-3900
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Charles Hake
>Assignee: Charles Hake
>Priority: Minor
> Fix For: 0.10.0
>
> Attachments: thrift-python-ssl-flags.patch
>
>
> Currently the generated Python code allows use of TSSLSocket, but does not 
> take any of the additional arguments (e.g. the trusted certificates). 
> TSSLSockets are always instantiated with no certificate verification.



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

[jira] [Resolved] (THRIFT-3902) TSocket.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3902.
--
   Resolution: Fixed
 Assignee: Aki Sukegawa
Fix Version/s: 0.10.0

The described problem was caused by TSocket so I've renamed this.
If problem persists for TFramedTransport, please file another issue.

> TSocket.open throws NullPointerException
> 
>
> Key: THRIFT-3902
> URL: https://issues.apache.org/jira/browse/THRIFT-3902
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Assignee: Aki Sukegawa
>Priority: Critical
> Fix For: 0.10.0
>
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Updated] (THRIFT-3902) TSocket.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3902:
-
Summary: TSocket.open throws NullPointerException  (was: 
TFramedTransport.open throws NullPointerException)

> TSocket.open throws NullPointerException
> 
>
> Key: THRIFT-3902
> URL: https://issues.apache.org/jira/browse/THRIFT-3902
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Resolved] (THRIFT-3936) Cannot compile 0.10.0 development tip with VS2013 and earlier (snprintf, uint32_t)

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3936.
--
   Resolution: Fixed
Fix Version/s: 0.10.0

committed, thanks.

> Cannot compile 0.10.0 development tip with VS2013 and earlier (snprintf, 
> uint32_t)
> --
>
> Key: THRIFT-3936
> URL: https://issues.apache.org/jira/browse/THRIFT-3936
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.10.0
> Environment: Visual Studio 2013, VS2013, Visual Studio 2010, VS2010, 
> Windows
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.10.0
>
>   Original Estimate: 0.25h
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> A change introduced in July changed some code that won't compile on VS2013:
> https://github.com/apache/thrift/commit/e5176241c325837967a07d6d20e0e9a789fbd107
> snprintf is not available.
> A pull request was submitted for this by someone in the community (thank 
> you!):
> https://github.com/apache/thrift/pull/1096
> I recommended that the fix be done using PlatformSocket.h for abstraction of 
> the platform; I offered to submit a PR to do this.
> In addition I found that with VS2010 I could not compile anything using 
> TApplicationException.h because uint32_t is used within it, but it doesn't 
> include stdlib.h.



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

[jira] [Resolved] (THRIFT-3878) Compile error in TSSLSocket.cpp with new OpenSSL [CRYPTO_num_locks]

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3878.
--
   Resolution: Fixed
Fix Version/s: 0.10.0

committed, thanks.

> Compile error in TSSLSocket.cpp with new OpenSSL [CRYPTO_num_locks]
> ---
>
> Key: THRIFT-3878
> URL: https://issues.apache.org/jira/browse/THRIFT-3878
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: VS2013
> Thrift from git repo, SHA-1: 5a3f855b4e6882184f13c698855c877241144a12 (master)
> OpenSSL from git repo (master).
>Reporter: Sergey Fasman
>Assignee: James E. King, III
>Priority: Trivial
> Fix For: 0.10.0
>
>
> In TSSLSocket if use new OpenSSL library (downloaded and builded from git) 
> will be compile error.
> That because CRYPTO_num_locks is now macro-call instead of function.
> THRIFT -also from git repo (master).
> So I simply fix that:
> #ifdef CRYPTO_num_locks
>   mutexes = boost::shared_array(new Mutex[CRYPTO_num_locks()]);
> #else
>   mutexes = boost::shared_array(new Mutex[ ::CRYPTO_num_locks()]);
> #endif



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

[jira] [Resolved] (THRIFT-3831) build of test/cpp/src/TestClient.cpp fails with newer gcc on platforms with unsigned char due to narrowing conversions

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3831.
--
   Resolution: Fixed
 Assignee: Cody Schafer
Fix Version/s: 0.10.0

committed, thanks.

> build of test/cpp/src/TestClient.cpp fails with newer gcc on platforms with 
> unsigned char due to narrowing conversions
> --
>
> Key: THRIFT-3831
> URL: https://issues.apache.org/jira/browse/THRIFT-3831
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Reporter: Cody Schafer
>Assignee: Cody Schafer
> Fix For: 0.10.0
>
> Attachments: 0001-test-cpp-explicitly-use-signed-char.patch
>
>
> Specifically, we get a bunch of errors like:
> test/cpp/src/TestClient.cpp:404:15: error: narrowing conversion 
> of '-1' from 'int' to 'char' inside { } [-Wnarrowing]
> gcc faq talks about this: https://gcc.gnu.org/wiki/FAQ#Wnarrowing
> I've only seen this in gcc-6, but the faq seems to indicate it could occur in 
> gcc-5 as well.



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

[jira] [Created] (THRIFT-3940) Visual Studio project file for compiler is broken

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3940:


 Summary: Visual Studio project file for compiler is broken
 Key: THRIFT-3940
 URL: https://issues.apache.org/jira/browse/THRIFT-3940
 Project: Thrift
  Issue Type: Bug
  Components: Build Process, Compiler (General)
Affects Versions: 0.10.0
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa






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

[jira] [Commented] (THRIFT-3855) In the go simple server, if Stop() is called multiple times it hangs

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3855:
--

[~patrickb] thanks for describing the problems.
It seems to be broken by my commit last week (THRIFT-2835).
I'll update vcxproj and readme.
But I don't what was happening for your CMake build.
We're building it fine without "-DBIN_INSTALL_DIR=" flag on our windows CI (and 
without link errors).


> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: Paul Finkelshteyn
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[jira] [Comment Edited] (THRIFT-3937) Cannot compile 0.10.0 development tip with gcc-4.6.3 and boost-1.53

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-3937 at 9/29/16 4:57 PM:
---

[~jking3] our CI uses boost 1.53 on CentOS 7
https://travis-ci.org/apache/thrift/jobs/163474948#L406
So boost version does not need an update.

On the other hand, we list GCC 4.2 as minimum requirement that sounds unlikely 
to work.
Our CI uses 4.8 on CentOS 7 and Ubuntu 14.04.
I'd suggest listing what we're testing as the required version.

One way to keep GCC req sufficiently low would be to build boost 1.53 on our 
CentOS 6 CI (GCC 4.4) and then run C/C++/native extension builds.

Also a quick work around for GCC 4.6 or lower is to set WITH_PLUGIN default 
value to OFF if old GCC is found when configuring.


was (Author: nsuke):
[~jking3] our CI uses boost 1.53 on CentOS 7
https://travis-ci.org/apache/thrift/jobs/163474948#L406
So boost version does not need an update.

On the other hand, we list GCC 4.2 as minimum requirement that sounds unlikely 
to work.
Our CI uses 4.8 on CentOS 7 and Ubuntu 14.04.
I'd suggest listing what we're testing as the required version.

> Cannot compile 0.10.0 development tip with gcc-4.6.3 and boost-1.53
> ---
>
> Key: THRIFT-3937
> URL: https://issues.apache.org/jira/browse/THRIFT-3937
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Ubuntu 12.04.5 LTS with gcc-4.6.3 and boost 1.53.0, 
> Ubuntu 14.04.2 LTS with gcc-4.6.4 and boost-1.54.0
>Reporter: James E. King, III
>Assignee: Aki Sukegawa
>
> While building the tip using cmake:
> {noformat}
> [ 51%] Building CXX object 
> compiler/cpp/CMakeFiles/thriftc_static.dir/src/thrift/plugin/plugin_output.cc.o
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc: In 
> function ‘void plugin_output::convert(From*, To&) [with From = t_enum, To = 
> apache::thrift::plugin::t_enum]’:
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:181:3: 
> error: no matching function for call to 
> ‘transform(std::vector<t_enum_value*>::const_iterator, 
> std::vector<t_enum_value*>::const_iterator, 
> std::back_insert_iterator<std::vector 
> >, )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:181:3: 
> note: candidates are:
> /usr/include/c++/4.6/bits/stl_algo.h:4871:5: note: template class _OIter, class _UnaryOperation> _OIter std::transform(_IIter, _IIter, 
> _OIter, _UnaryOperation)
> /usr/include/c++/4.6/bits/stl_algo.h:4907:5: note: template class _IIter2, class _OIter, class _BinaryOperation> _OIter 
> std::transform(_IIter1, _IIter1, _IIter2, _OIter, _BinaryOperation)
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc: In 
> function ‘void plugin_output::convert(From*, To&) [with From = 
> t_const_value, To = apache::thrift::plugin::t_const_value]’:
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:212:5: 
> error: no matching function for call to 
> ‘transform(std::vector<t_const_value*>::const_iterator, 
> std::vector<t_const_value*>::const_iterator, 
> std::back_insert_iterator<std::vector 
> >, )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:212:5: 
> note: candidates are:
> /usr/include/c++/4.6/bits/stl_algo.h:4871:5: note: template class _OIter, class _UnaryOperation> _OIter std::transform(_IIter, _IIter, 
> _OIter, _UnaryOperation)
> /usr/include/c++/4.6/bits/stl_algo.h:4907:5: note: template class _IIter2, class _OIter, class _BinaryOperation> _OIter 
> std::transform(_IIter1, _IIter1, _IIter2, _OIter, _BinaryOperation)
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc: In 
> function ‘void plugin_output::convert(From*, To&) [with From = t_struct, To 
> = apache::thrift::plugin::t_struct]’:
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:235:3: 
> error: no matching function for call to 
> ‘transform(std::vector<t_field*>::const_iterator, 
> std::vector<t_field*>::const_iterator, 
> std::back_insert_iterator<std::vector >, 
> )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:235:3: 
> note: candidates are:
> /usr/include/c++/4.6/bits/stl_algo.h:4871:5: note: template class _OIter, class _UnaryOperation> _OIter std::transform(_IIter, _IIter, 
> _OIter, _UnaryOperation)
> /usr/include/c++/4.6/bits/stl_algo.h:4907:5: note: template class _IIter2, class _OIter, class _Bi

[jira] [Commented] (THRIFT-3937) Cannot compile 0.10.0 development tip with gcc-4.6.3 and boost-1.53

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3937:
--

[~jking3] our CI uses boost 1.53 on CentOS 7
https://travis-ci.org/apache/thrift/jobs/163474948#L406
So boost version does not need an update.

On the other hand, we list GCC 4.2 as minimum requirement that sounds unlikely 
to work.
Our CI uses 4.8 on CentOS 7 and Ubuntu 14.04.
I'd suggest listing what we're testing as the required version.

> Cannot compile 0.10.0 development tip with gcc-4.6.3 and boost-1.53
> ---
>
> Key: THRIFT-3937
> URL: https://issues.apache.org/jira/browse/THRIFT-3937
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Ubuntu 12.04.5 LTS with gcc-4.6.3 and boost 1.53.0, 
> Ubuntu 14.04.2 LTS with gcc-4.6.4 and boost-1.54.0
>Reporter: James E. King, III
>Assignee: Aki Sukegawa
>
> While building the tip using cmake:
> {noformat}
> [ 51%] Building CXX object 
> compiler/cpp/CMakeFiles/thriftc_static.dir/src/thrift/plugin/plugin_output.cc.o
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc: In 
> function ‘void plugin_output::convert(From*, To&) [with From = t_enum, To = 
> apache::thrift::plugin::t_enum]’:
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:181:3: 
> error: no matching function for call to 
> ‘transform(std::vector<t_enum_value*>::const_iterator, 
> std::vector<t_enum_value*>::const_iterator, 
> std::back_insert_iterator<std::vector 
> >, )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:181:3: 
> note: candidates are:
> /usr/include/c++/4.6/bits/stl_algo.h:4871:5: note: template class _OIter, class _UnaryOperation> _OIter std::transform(_IIter, _IIter, 
> _OIter, _UnaryOperation)
> /usr/include/c++/4.6/bits/stl_algo.h:4907:5: note: template class _IIter2, class _OIter, class _BinaryOperation> _OIter 
> std::transform(_IIter1, _IIter1, _IIter2, _OIter, _BinaryOperation)
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc: In 
> function ‘void plugin_output::convert(From*, To&) [with From = 
> t_const_value, To = apache::thrift::plugin::t_const_value]’:
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:212:5: 
> error: no matching function for call to 
> ‘transform(std::vector<t_const_value*>::const_iterator, 
> std::vector<t_const_value*>::const_iterator, 
> std::back_insert_iterator<std::vector 
> >, )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:212:5: 
> note: candidates are:
> /usr/include/c++/4.6/bits/stl_algo.h:4871:5: note: template class _OIter, class _UnaryOperation> _OIter std::transform(_IIter, _IIter, 
> _OIter, _UnaryOperation)
> /usr/include/c++/4.6/bits/stl_algo.h:4907:5: note: template class _IIter2, class _OIter, class _BinaryOperation> _OIter 
> std::transform(_IIter1, _IIter1, _IIter2, _OIter, _BinaryOperation)
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc: In 
> function ‘void plugin_output::convert(From*, To&) [with From = t_struct, To 
> = apache::thrift::plugin::t_struct]’:
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:235:3: 
> error: no matching function for call to 
> ‘transform(std::vector<t_field*>::const_iterator, 
> std::vector<t_field*>::const_iterator, 
> std::back_insert_iterator<std::vector >, 
> )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:235:3: 
> note: candidates are:
> /usr/include/c++/4.6/bits/stl_algo.h:4871:5: note: template class _OIter, class _UnaryOperation> _OIter std::transform(_IIter, _IIter, 
> _OIter, _UnaryOperation)
> /usr/include/c++/4.6/bits/stl_algo.h:4907:5: note: template class _IIter2, class _OIter, class _BinaryOperation> _OIter 
> std::transform(_IIter1, _IIter1, _IIter2, _OIter, _BinaryOperation)
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc: In 
> function ‘void plugin_output::convert(From*, To&) [with From = t_service, 
> To = apache::thrift::plugin::t_service]’:
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:267:3: 
> error: no matching function for call to 
> ‘transform(std::vector<t_function*>::const_iterator, 
> std::vector<t_function*>::const_iterator, 
> std::back_insert_iterator<std::vector >, 
> )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:

[jira] [Updated] (THRIFT-3938) Python TNonblockingServer does not work with SSL

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3938:
-
Description: Not exhausting socket read buffer and selecting for remaining 
data does not work for SSL sockets as it's often already consumed by underlying 
SSL buffer and does not yield another readable event.

> Python TNonblockingServer does not work with SSL
> 
>
> Key: THRIFT-3938
> URL: https://issues.apache.org/jira/browse/THRIFT-3938
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>    Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
>
> Not exhausting socket read buffer and selecting for remaining data does not 
> work for SSL sockets as it's often already consumed by underlying SSL buffer 
> and does not yield another readable event.



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

[jira] [Created] (THRIFT-3938) Python TNonblockingServer does not work with SSL

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3938:


 Summary: Python TNonblockingServer does not work with SSL
 Key: THRIFT-3938
 URL: https://issues.apache.org/jira/browse/THRIFT-3938
 Project: Thrift
  Issue Type: Bug
  Components: Python - Library
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa






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

[jira] [Created] (THRIFT-3934) Automatically resolve OpenSSL binary version on Windows CI

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3934:


 Summary: Automatically resolve OpenSSL binary version on Windows CI
 Key: THRIFT-3934
 URL: https://issues.apache.org/jira/browse/THRIFT-3934
 Project: Thrift
  Issue Type: Improvement
  Components: Build Process
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa


Currently Windows CI is broken because the version of OpenSSL binary is no 
longer available.
It happened twice within a week.
Some sort of automation would reduce such an emergency need for fixes.



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

[jira] [Comment Edited] (THRIFT-3507) THttpClient does not use proxy from http_proxy, https_proxy environment variables

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-3507 at 9/26/16 2:02 AM:
---

edit: never mind.

The patch actually just delegates everything to urllib, so I expect my concern 
to be already addressed.


-Reading http_proxy without reading no_proxy would result in another surprises 
and inconveniences,-




was (Author: nsuke):
Reading http_proxy without reading no_proxy would result in another surprises 
and inconveniences,
although better in that it can be worked around in users' code.

The real problem is that users have no way to use proxies in the current Thrift 
API.
As these environment variables are only conventions, start reading them now may 
not be a best solution.

> THttpClient does not use proxy from http_proxy, https_proxy environment 
> variables
> -
>
> Key: THRIFT-3507
> URL: https://issues.apache.org/jira/browse/THRIFT-3507
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.3
> Environment: Windows 7 + Cygwin x64 + Python 2.7.10
>Reporter: Fabricio Oliveira
>Priority: Critical
> Attachments: 
> 0001-python-THttpClient-Add-support-for-system-proxy-sett.patch, 
> THRIFT-3507-1.patch
>
>




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

[jira] [Commented] (THRIFT-3507) THttpClient does not use proxy from http_proxy, https_proxy environment variables

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3507:
--

Reading http_proxy without reading no_proxy would result in another surprises 
and inconveniences,
although better in that it can be worked around in users' code.

The real problem is that users have no way to use proxies in the current Thrift 
API.
As these environment variables are only conventions, start reading them now may 
not be a best solution.

> THttpClient does not use proxy from http_proxy, https_proxy environment 
> variables
> -
>
> Key: THRIFT-3507
> URL: https://issues.apache.org/jira/browse/THRIFT-3507
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.3
> Environment: Windows 7 + Cygwin x64 + Python 2.7.10
>Reporter: Fabricio Oliveira
>Priority: Critical
> Attachments: 
> 0001-python-THttpClient-Add-support-for-system-proxy-sett.patch, 
> THRIFT-3507-1.patch
>
>




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

[jira] [Commented] (THRIFT-3902) TFramedTransport.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3902:
--

[~hcma] it's not marked as resolved.
There were 2 identical issues.
I've marked the other one as a duplicate as this one had votes and watchers.


> TFramedTransport.open throws NullPointerException
> -
>
> Key: THRIFT-3902
> URL: https://issues.apache.org/jira/browse/THRIFT-3902
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Commented] (THRIFT-3902) TFramedTransport.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3902:
--

{code}
if (host_.length() == 0) {
{code}
This means that host_ is null.
Maybe you're passing null sometimes ?

But the code is admittedly strange in that it checks the length field without 
null check.
Also as the next thing it does is to throw exception right away, it could have 
checked the host argument in constructor since it's completely unusable with 
null or empty host.

> TFramedTransport.open throws NullPointerException
> -
>
> Key: THRIFT-3902
> URL: https://issues.apache.org/jira/browse/THRIFT-3902
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Resolved] (THRIFT-3901) TFramedTransport.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3901.
--
Resolution: Duplicate
  Assignee: Aki Sukegawa

> TFramedTransport.open throws NullPointerException
> -
>
> Key: THRIFT-3901
> URL: https://issues.apache.org/jira/browse/THRIFT-3901
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Assignee: Aki Sukegawa
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Commented] (THRIFT-3925) Client service recieves string instead of buffer when using TCompactProtocol with node.js library.

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3925:
--

I think it's resolved as part of THRIFT-3409 in master branch.
Unfortunately it's not released yet.

> Client service recieves string instead of buffer when using TCompactProtocol 
> with node.js library.
> --
>
> Key: THRIFT-3925
> URL: https://issues.apache.org/jira/browse/THRIFT-3925
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
>Reporter: Roman Poliakov
>Priority: Critical
> Attachments: 
> Fixed_issue_with_TCompactProtocol_returning_string_instead_of_Buffer_for_service_function_.patch
>
>
> Node.js implementation of TCompactProtocol instead of returning raw Buffer, 
> converts it to string, which leads to data corruption. 
> At the line: 
> https://github.com/apache/thrift/blob/0.9.3/lib/nodejs/lib/thrift/compact_protocol.js#L764
> you can see that it uses "readString" method of the transport instead of 
> using "read".



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

[jira] [Resolved] (THRIFT-3839) Performance issue with big message deserialization using php extension

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3839.
--
   Resolution: Fixed
 Assignee: Myroslav Kosinskyi
Fix Version/s: (was: 1.0)
   0.10.0

committed, thanks.
FWIW, serialization might be also affected.

> Performance issue with big message deserialization using php extension
> --
>
> Key: THRIFT-3839
> URL: https://issues.apache.org/jira/browse/THRIFT-3839
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.9.3
>Reporter: Myroslav Kosinskyi
>Assignee: Myroslav Kosinskyi
> Fix For: 0.10.0
>
>
> I have found performance issue when tried to deserialize big thrift binary 
> message with enabled thrift_protocol php extension.
> Messsage size was 10 mb and it took about 30 seconds to deserialize it.
> When i have done debug of php extension and php library i have found that 
> issue is because small read buffer is used in TBufferedTransport and i cannot 
> change it from TBinarySerializer::deserialize method.
> So i have added parameter $buffer_size to function 
> thrift_protocol_read_binary from php extension.
> And also this parameter i have added to method TBinarySerializer::deserialize 
> from php library.
> And i extended class Thrift\Transport\TMemoryBuffer by method putBack, so 
> this class will be used for desearilization without TBufferedTransport 
> warapper.
> After these changes it takes less than a second to deserizlize message with 
> 10 mb size id read buffer 512 kb.
> Here is the pull request https://github.com/apache/thrift/pull/1014



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

[jira] [Updated] (THRIFT-3839) Performance issue with big message deserialization using php extension

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3839:
-
Affects Version/s: (was: 1.0)

> Performance issue with big message deserialization using php extension
> --
>
> Key: THRIFT-3839
> URL: https://issues.apache.org/jira/browse/THRIFT-3839
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.9.3
>Reporter: Myroslav Kosinskyi
> Fix For: 1.0
>
>
> I have found performance issue when tried to deserialize big thrift binary 
> message with enabled thrift_protocol php extension.
> Messsage size was 10 mb and it took about 30 seconds to deserialize it.
> When i have done debug of php extension and php library i have found that 
> issue is because small read buffer is used in TBufferedTransport and i cannot 
> change it from TBinarySerializer::deserialize method.
> So i have added parameter $buffer_size to function 
> thrift_protocol_read_binary from php extension.
> And also this parameter i have added to method TBinarySerializer::deserialize 
> from php library.
> And i extended class Thrift\Transport\TMemoryBuffer by method putBack, so 
> this class will be used for desearilization without TBufferedTransport 
> warapper.
> After these changes it takes less than a second to deserizlize message with 
> 10 mb size id read buffer 512 kb.
> Here is the pull request https://github.com/apache/thrift/pull/1014



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

[jira] [Resolved] (THRIFT-3920) Ruby: Ensuring that HTTP failures will clear the http transport outbuf var

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3920.
--
   Resolution: Fixed
 Assignee: John 
Fix Version/s: 0.10.0

committed, thanks.

> Ruby: Ensuring that HTTP failures will clear the http transport outbuf var
> --
>
> Key: THRIFT-3920
> URL: https://issues.apache.org/jira/browse/THRIFT-3920
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.9.3
>Reporter: John 
>Assignee: John 
>Priority: Minor
> Fix For: 0.10.0
>
>
> PR: https://github.com/apache/thrift/pull/1048
> With the current implementation, any Net HTTP failure will raise from the 
> #flush() method without resetting the @outbuf variable.
> I think that resetting the @outbuf on these failures is more "expected" 
> behaviour. Especially if there is a malformed request that the downstream 
> server does not want to/can't handle. As far as I can tell, there is not way 
> to clear the @outbuf var apart from the #flush() method, so if that fails, 
> then you will just keep appending requests to the out buffer.



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

[jira] [Resolved] (THRIFT-3844) thrift_protocol cannot compile in 7.0.7

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3844.
--
   Resolution: Fixed
 Assignee: Robert Lu
Fix Version/s: 0.10.0

> thrift_protocol cannot compile in 7.0.7
> ---
>
> Key: THRIFT-3844
> URL: https://issues.apache.org/jira/browse/THRIFT-3844
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0
> Environment: PHP 7.0.7, x86-64, OS-X 10.11
>Reporter: Robert Lu
>Assignee: Robert Lu
> Fix For: 0.10.0
>
>
> When compile thrift_protocol extension with php7.0.7 in OS X 10.11,
> Report error:
> php_thrift_protocol7.cpp:290:27: error: no member named 'min' in namespace 
> 'std'; did you mean 'fmin'?
> and
> zend_hash.h:168:30: note: candidate function not viable: no known conversion 
> from 'unsigned long *' to 'zend_ulong *' (aka 'unsigned long long *') for 3rd 
> argument
> ZEND_API int   ZEND_FASTCALL zend_hash_get_current_key_ex(const HashTable 
> *ht, zend_string **str_index, zend_ulong *num_index, HashPosition *pos);
> *And I find someone in github solved this problom, but no one notice it, so I 
> create this issue*



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

[jira] [Updated] (THRIFT-3845) TBinaryProtocolAccelerated cannot use thrift_protocol ext

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3845:
-
Assignee: Robert Lu

> TBinaryProtocolAccelerated cannot use thrift_protocol ext
> -
>
> Key: THRIFT-3845
> URL: https://issues.apache.org/jira/browse/THRIFT-3845
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler, PHP - Library
>Affects Versions: 0.9.3
> Environment: PHP7 with thrift 0.9.3, with thrift_protocol, at OS X 
> 10.11
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Minor
>
> compiler generate phpcode:
>  instanceof TBinaryProtocolAccelerated
> to indicate use thrift_protocol, but when TBinaryProtocolAccelerated warped 
> in TMultiplexedProtocol, thrift_protocol doesn't used, because 
> TMultiplexedProtocol isn't TBinaryProtocolAccelerated's instence.



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

[jira] [Updated] (THRIFT-3844) thrift_protocol cannot compile in 7.0.7

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3844:
-
Affects Version/s: (was: 1.0)
   0.10.0

> thrift_protocol cannot compile in 7.0.7
> ---
>
> Key: THRIFT-3844
> URL: https://issues.apache.org/jira/browse/THRIFT-3844
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0
> Environment: PHP 7.0.7, x86-64, OS-X 10.11
>Reporter: Robert Lu
>
> When compile thrift_protocol extension with php7.0.7 in OS X 10.11,
> Report error:
> php_thrift_protocol7.cpp:290:27: error: no member named 'min' in namespace 
> 'std'; did you mean 'fmin'?
> and
> zend_hash.h:168:30: note: candidate function not viable: no known conversion 
> from 'unsigned long *' to 'zend_ulong *' (aka 'unsigned long long *') for 3rd 
> argument
> ZEND_API int   ZEND_FASTCALL zend_hash_get_current_key_ex(const HashTable 
> *ht, zend_string **str_index, zend_ulong *num_index, HashPosition *pos);
> *And I find someone in github solved this problom, but no one notice it, so I 
> create this issue*



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

[jira] [Resolved] (THRIFT-3929) PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing Backslash)

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3929.
--
   Resolution: Fixed
 Assignee: Ben Meynell
Fix Version/s: (was: 1.0)
   0.10.0

committed, thanks

> PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing 
> Backslash)
> 
>
> Key: THRIFT-3929
> URL: https://issues.apache.org/jira/browse/THRIFT-3929
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.9.3
> Environment: Distributor ID: Ubuntu
> Description:Ubuntu 14.04.4 LTS
> Release:14.04
> Codename:   trusty
>Reporter: Ben Meynell
>Assignee: Ben Meynell
>  Labels: easyfix
> Fix For: 0.10.0
>
>
> thrift --gen php:server,psr4,oop,validate,json,nsglobal="My\Special\Place" 
> -out ./src my.thrift
> Results in PHP files with namespaces defined as:
> namespace My\Special\Place\;
> Note the trailing backslash ("\"). This results in unparseable PHP:
> $ php -l src/My/Special/Place/Data.php
> Errors parsing src/My/Special/Place/Data.php
> The fix is to simply omit the trailing backslash from the generated code.



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

[jira] [Updated] (THRIFT-3929) PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing Backslash)

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3929:
-
Affects Version/s: (was: 1.0)
   0.9.3

> PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing 
> Backslash)
> 
>
> Key: THRIFT-3929
> URL: https://issues.apache.org/jira/browse/THRIFT-3929
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.9.3
> Environment: Distributor ID: Ubuntu
> Description:Ubuntu 14.04.4 LTS
> Release:14.04
> Codename:   trusty
>Reporter: Ben Meynell
>  Labels: easyfix
> Fix For: 1.0
>
>
> thrift --gen php:server,psr4,oop,validate,json,nsglobal="My\Special\Place" 
> -out ./src my.thrift
> Results in PHP files with namespaces defined as:
> namespace My\Special\Place\;
> Note the trailing backslash ("\"). This results in unparseable PHP:
> $ php -l src/My/Special/Place/Data.php
> Errors parsing src/My/Special/Place/Data.php
> The fix is to simply omit the trailing backslash from the generated code.



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

[jira] [Resolved] (THRIFT-3904) Typo in node tutorial leads to wrong transport being used

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3904.
--
   Resolution: Fixed
 Assignee: Marek Kedzierski
Fix Version/s: 0.10.0

committed, thanks !

> Typo in node tutorial leads to wrong transport being used
> -
>
> Key: THRIFT-3904
> URL: https://issues.apache.org/jira/browse/THRIFT-3904
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library, Tutorial
>Reporter: Mark Sonnabaum
>Assignee: Marek Kedzierski
> Fix For: 0.10.0
>
>
> In the node tutorial (tutorial/nodejs/NodeClient.js), lines like `transport = 
> thrift.TBufferedTransport()` cause transport to be undefined, which later get 
> replaced with the default, so this example does work.
> I found the issue when using `thrift.TFramedTransport()`, which was erroring 
> on the server side. It took me a while to figure out that the transport was 
> falling back to buffered, because I was actually assigning the transport to 
> undefined.
> Changing the lines to assign thrift.TFramedTransport instead of 
> thrift.TFramedTransport() fixed it for me.



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

[jira] [Created] (THRIFT-3919) C# TTLSServerSocket does not use clientTimeout

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3919:


 Summary: C# TTLSServerSocket does not use clientTimeout
 Key: THRIFT-3919
 URL: https://issues.apache.org/jira/browse/THRIFT-3919
 Project: Thrift
  Issue Type: Bug
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa


The clientTimeout arg is never used in constructors.



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

[jira] [Resolved] (THRIFT-3774) The generated code should have exception_names meta info

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3774.
--
   Resolution: Fixed
Fix Version/s: 0.10.0

Looks like the patch is already applied as part of THRIFT-3834 patch.
Sorry that we missed attribute in commit log.

> The generated code should have exception_names meta info
> 
>
> Key: THRIFT-3774
> URL: https://issues.apache.org/jira/browse/THRIFT-3774
> Project: Thrift
>  Issue Type: Improvement
>  Components: Erlang - Compiler
>Reporter: laozhp
>Assignee: laozhp
>Priority: Minor
> Fix For: 0.10.0
>
>




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

[jira] [Created] (THRIFT-3918) Run subset of make cross

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3918:


 Summary: Run subset of make cross
 Key: THRIFT-3918
 URL: https://issues.apache.org/jira/browse/THRIFT-3918
 Project: Thrift
  Issue Type: Improvement
  Components: Build Process
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa


To workaround timeouts on travis-ci, we can introduce "make cross-binary" etc.
Plain "make cross" behavior does not change.



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

[jira] [Created] (THRIFT-3917) Check backports.ssl_match_hostname module version

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3917:


 Summary: Check backports.ssl_match_hostname module version
 Key: THRIFT-3917
 URL: https://issues.apache.org/jira/browse/THRIFT-3917
 Project: Thrift
  Issue Type: Bug
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa
Priority: Minor


Either python > 3.5 or backports.ssl_match_hostname > 3.5 is needed for SSL IP 
address verification.
For python < 3.5, we check existence of backports.ssl_match_hostname but not 
its version.



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

[jira] [Created] (THRIFT-3911) Loosen Ruby dev dependency version requirements

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3911:


 Summary: Loosen Ruby dev dependency version requirements
 Key: THRIFT-3911
 URL: https://issues.apache.org/jira/browse/THRIFT-3911
 Project: Thrift
  Issue Type: Improvement
  Components: Build Process, Ruby - Library
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa
Priority: Trivial


Ruby gemspec complains when installing Thrift development dependencies that the 
version requirements are too restrictive.




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

[jira] [Created] (THRIFT-3910) Do not invoke pip as part of build process

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3910:


 Summary: Do not invoke pip as part of build process
 Key: THRIFT-3910
 URL: https://issues.apache.org/jira/browse/THRIFT-3910
 Project: Thrift
  Issue Type: Improvement
  Components: Build Process, Python - Library
Affects Versions: 0.10.0
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa


Currently, Python optional dependencies are put to requriements.txt which 
Autotool/CMake scripts invoke pip on.
The idea was to do the same as our other language builds do: install 
dependencies (Java, Ruby, Haskell etc).

In retrospect, each language has different convention/tooling and it's rather 
surprising or rude thing to do in Python IMO.
Instead, we can moved them to "extras_require" in setup.py so that one can 
install via "pip install thrift[all]" if they want to.



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

[jira] [Created] (THRIFT-3909) Fix c_glib static lib CMake build

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3909:


 Summary: Fix c_glib static lib CMake build
 Key: THRIFT-3909
 URL: https://issues.apache.org/jira/browse/THRIFT-3909
 Project: Thrift
  Issue Type: Bug
  Components: Build Process, C glib - Library
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa






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

[jira] [Created] (THRIFT-3908) Remove redundant dependencies from Dockerfile

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3908:


 Summary: Remove redundant dependencies from Dockerfile
 Key: THRIFT-3908
 URL: https://issues.apache.org/jira/browse/THRIFT-3908
 Project: Thrift
  Issue Type: Improvement
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa
Priority: Minor


A Docker build step for apt-get mono often fails on CI due to unknown reasons.
In an tentative attempt to alleviate this, we can remove unneeded apt packages 
and reduce download payload.

For mono:
* mono-complete was not necessary, mono-devel suffices
* we do not use xbuild and gmcs

Others:
* rake was already available without gem install rake. Also this somehow caused 
problem on Ubuntu Xenial.
* skip ruby doc for bundler as is often seen
* update-alternative java was for previous versions of Ubuntu and resulted in 
error message because no alternative is there



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

[jira] [Created] (THRIFT-3907) Skip Docker image build on CI when unchanged

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3907:


 Summary: Skip Docker image build on CI when unchanged
 Key: THRIFT-3907
 URL: https://issues.apache.org/jira/browse/THRIFT-3907
 Project: Thrift
  Issue Type: Improvement
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa


Previously we were able to reuse Docker layers from prebuilt images pulled from 
docker hub.
This has been reducing total build time by 3 hours out of 7~8 hours total.
After Docker 1.10 or so, it is no longer possible and we tend to easily 
saturate entire Apache's 30 jobs on Travis-CI.

Standard solution as of now is to use docker save/load.
This typically requires automated file upload on CI to some external storage.
Unfortunately it cannot be done with our current Travis-CI account settings.

To workaround this, we can put Dockerfile itself to Docker image and see if 
it's modified after the prebuild time and skip fresh builds if unchanged.



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

[jira] [Commented] (THRIFT-3906) Run C# tests with make check

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3906:
--

[~jensg] that makes sense. I'll relocate cross test apps. 

> Run C# tests with make check
> 
>
> Key: THRIFT-3906
> URL: https://issues.apache.org/jira/browse/THRIFT-3906
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process, C# - Library, Test Suite
>    Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
>
> Currently, one needs to invoke test scripts manually to run C# tests.
> Those tests should be part of make check so that CI can automatically check 
> sanity of patches.



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

[jira] [Created] (THRIFT-3906) Run C# tests with make check

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3906:


 Summary: Run C# tests with make check
 Key: THRIFT-3906
 URL: https://issues.apache.org/jira/browse/THRIFT-3906
 Project: Thrift
  Issue Type: Improvement
  Components: Build Process, C# - Library, Test Suite
Reporter: Aki Sukegawa
Assignee: Aki Sukegawa


Currently, one needs to invoke test scripts manually to run C# tests.
Those tests should be part of make check so that CI can automatically check 
sanity of patches.



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

[jira] [Updated] (THRIFT-3886) PHP cross test client returns 0 even when failing

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3886:
-
Description: 
PHP cross test client never fails on invalid values.

update:
Results for primitive values are now validated after PR #1054.
Structs, containers, etc are still affected.

  was:PHP cross test client never fails on invalid values.


> PHP cross test client returns 0 even when failing
> -
>
> Key: THRIFT-3886
> URL: https://issues.apache.org/jira/browse/THRIFT-3886
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library, Test Suite
>    Reporter: Aki Sukegawa
>
> PHP cross test client never fails on invalid values.
> update:
> Results for primitive values are now validated after PR #1054.
> Structs, containers, etc are still affected.



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