[jira] [Commented] (THRIFT-4858) Java TThreadPoolServer: confusing error message on closed socket
[
https://issues.apache.org/jira/browse/THRIFT-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
> 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 to the next line:
> {{ProcessFunction fn = processMap.get(msg.nam
[jira] [Updated] (THRIFT-4858) Java TThreadPoolServer: confusing error message on closed socket
[
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 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 to the next line:
> {{ProcessFunction fn = processMap.get(msg.name);}}
> For giggles, I decided to remove the ! from the logic, and sure
[jira] [Resolved] (THRIFT-4858) Java TThreadPoolServer calls TBaseProcesser twice, erroneously
[
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(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 to the next line:
> {{ProcessFunction fn
[jira] [Updated] (THRIFT-4858) Java TThreadPoolServer calls TBaseProcesser twice, erroneously
[
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 to the next line:
> {{ProcessFunction fn = processMap.get(msg.name);}}
> For giggles, I decided to remove the ! from the logic, and sure enough it
> gets by but it appears to perhaps cause other problems when a client calls a
> method with zero parameters (e.g. "ping()").
> *Other versions:* So fa
[jira] [Commented] (THRIFT-4858) Java TThreadPoolServer calls TBaseProcesser twice, erroneously
[
https://issues.apache.org/jira/browse/THRIFT-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 using a
> TBinaryProtocol) to the process function, there is nothing left to read and
> thus we never make it to the next line:
> {{ProcessFunction fn = processMap.get(msg.name);}}
> For giggles, I decided to remove the ! from the logic, and sure enough it
> gets b
[jira] [Commented] (THRIFT-4677) UnicodeDecodeError in Python3
[
https://issues.apache.org/jira/browse/THRIFT-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[
https://issues.apache.org/jira/browse/THRIFT-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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.
[
https://issues.apache.org/jira/browse/THRIFT-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[
https://issues.apache.org/jira/browse/THRIFT-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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 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 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
[ https://issues.apache.org/jira/browse/THRIFT-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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)
[jira] [Commented] (THRIFT-4256) Dependency on very old version of vector library
[ https://issues.apache.org/jira/browse/THRIFT-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[
https://issues.apache.org/jira/browse/THRIFT-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[ 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 too often due to occasional apt download failures. But for some unknown reason apt is not failing any longer. Although reusing reduces build time by ~10min for each job, we may well remove the script and always build images from scratch. was: 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 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 too often due to occasional apt download failures. > But for some unknown reason apt is not failing any longer. > Although reusing reduces build time by ~10min for each job, we may well > remove the script and always build images from scratch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-4030) CI jobs do not reuse downloaded docker images
[ 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
[ 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 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
[ https://issues.apache.org/jira/browse/THRIFT-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/THRIFT-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[
https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Commented] (THRIFT-3775) 0.10.0 release candidate
[ https://issues.apache.org/jira/browse/THRIFT-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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 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)
[jira] [Commented] (THRIFT-3940) Visual Studio project file for compiler is broken
[ https://issues.apache.org/jira/browse/THRIFT-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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)
[ 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]
[ 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
[
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 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
[
https://issues.apache.org/jira/browse/THRIFT-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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::const_iterator,
> std::vector::const_iterator,
> std::back_insert_iterator
> >, )’
> /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::const_iterator,
> std::vector::const_iterator,
> std::back_insert_iterator
> >, )’
> /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::const_iterator,
> std::vector::const_iterator,
> std::back_insert_iterator >,
> )’
> /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
[jira] [Commented] (THRIFT-3937) Cannot compile 0.10.0 development tip with gcc-4.6.3 and boost-1.53
[
https://issues.apache.org/jira/browse/THRIFT-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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::const_iterator,
> std::vector::const_iterator,
> std::back_insert_iterator
> >, )’
> /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::const_iterator,
> std::vector::const_iterator,
> std::back_insert_iterator
> >, )’
> /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::const_iterator,
> std::vector::const_iterator,
> std::back_insert_iterator >,
> )’
> /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::const_iterator,
> std::vector::const_iterator,
> std::back_insert_iterator >,
> )’
> /home/jking/thrift/compiler/cpp/src/thrift/plugin/plugin_output.cc:267: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
> fu
[jira] [Updated] (THRIFT-3938) Python TNonblockingServer does not work with SSL
[ 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 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 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
[ https://issues.apache.org/jira/browse/THRIFT-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/THRIFT-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/THRIFT-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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.
[ https://issues.apache.org/jira/browse/THRIFT-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)
[
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)
[
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-3046) Allow PSR4 class loading for generated classes (PHP)
[ https://issues.apache.org/jira/browse/THRIFT-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Sukegawa resolved THRIFT-3046. -- Resolution: Fixed Assignee: Alex Medvedev Fix Version/s: 0.10.0 > Allow PSR4 class loading for generated classes (PHP) > > > Key: THRIFT-3046 > URL: https://issues.apache.org/jira/browse/THRIFT-3046 > Project: Thrift > Issue Type: New Feature > Components: PHP - Compiler, PHP - Library >Affects Versions: 0.9.2 >Reporter: Alex Medvedev >Assignee: Alex Medvedev > Fix For: 0.10.0 > > Attachments: php-compiler-psr4-option.patch > > > Nowadays thrift PHP library contains it's own class loader > lib/php/lib/Thrift/ClassLoader/ThriftClassLoader.php for loading of generated > classes. This loader is based on psr0 approach and combines it with some > thrift specialties like locating all the structs and exceptions in Types.php > file and all the service classes (processor, interface, rest handler, *_args > and *_result) in single service file. > These points make thrift class loading not so flexible: > 1. It is not possible to use advantages of psr4 autoloading. For example we > cannot omit first part of class namespace inside procedure of translating > namespace to file system paths. It can be useful when we are locating > generated client classes in some vendor package inside the application. > 2. This approach makes impossible to use all the power of Composer class > loader (except the case when we providing preliminarily prepared classmap for > the thrift classes) to load classes and forces to register ThriftClassLoader > each time when we use generated classes. > The patch attached allows generation of all the PHP classes in separate files > in case of 'psr4' option is provided. Such generated classes can be loaded > with standard composer (or any other psr4-compatible) class loader. > Because of big amount of *_args and *_result classes thrift compiler with > psr4-option generates significant amount of files. Nevertheless we can > consider refactoring (omiting) of these classes in separate PR (may be we can > implement java-style approach there). -- 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
[ 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 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
[ 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 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 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 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 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 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 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 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
[ https://issues.apache.org/jira/browse/THRIFT-3906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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)
[jira] [Resolved] (THRIFT-3883) Go TestAllConnection can fail with port 9090 collision
[
https://issues.apache.org/jira/browse/THRIFT-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Sukegawa resolved THRIFT-3883.
--
Resolution: Fixed
Assignee: Aki Sukegawa
Fix Version/s: 0.10.0
committed a quick workaround.
> Go TestAllConnection can fail with port 9090 collision
> --
>
> Key: THRIFT-3883
> URL: https://issues.apache.org/jira/browse/THRIFT-3883
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library, Test Suite
> Environment: Travis-CI
>Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
> Labels: test-stability
> Fix For: 0.10.0
>
>
> Just observed a new type of flaky test on Travis-CI.
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/145533626/log.txt
> {code}
> GOPATH=`pwd` /usr/local/go/bin/go test -v common/...
> === RUN TestAllConnection
> --- FAIL: TestAllConnection (0.00s)
> clientserver_test.go:51: common.test_unit{host:"127.0.0.1", port:9090,
> domain_socket:"", transport:"", protocol:"binary", ssl:false}
> clientserver_test.go:65: Unable to start server%!(EXTRA
> *net.OpError=listen tcp 127.0.0.1:9090: bind: address already in use)
> FAIL
> exit status 1
> FAIL common 0.004s
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3885) PHP: Error when readI64 in TCompactProtocol
[ https://issues.apache.org/jira/browse/THRIFT-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Sukegawa resolved THRIFT-3885. -- Resolution: Duplicate Assignee: Aki Sukegawa > PHP: Error when readI64 in TCompactProtocol > --- > > Key: THRIFT-3885 > URL: https://issues.apache.org/jira/browse/THRIFT-3885 > Project: Thrift > Issue Type: Bug > Components: PHP - Library >Affects Versions: 0.7, 0.8, 0.9, 0.9.1, 0.9.2, 0.9.3 > Environment: all >Reporter: Chen Zhiming >Assignee: Aki Sukegawa > Labels: patch > > In line 618 of readI64 of TCompactProtocol, the number of shift bit is error. > It must be > $hi |= (($byte & 0x7f) >> (7 - ($shift - 25))); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3827) php CompactProtocol readI64 function has bug, when value has 32bit ~64bit, Example：value=1461563457000
[ https://issues.apache.org/jira/browse/THRIFT-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Sukegawa resolved THRIFT-3827. -- Resolution: Fixed Assignee: lnn1123 Fix Version/s: 0.10.0 committed, thanks ! > php CompactProtocol readI64 function has bug, when value has 32bit ~64bit, > Example：value=1461563457000 > --- > > Key: THRIFT-3827 > URL: https://issues.apache.org/jira/browse/THRIFT-3827 > Project: Thrift > Issue Type: Bug > Components: PHP - Library >Affects Versions: 0.9.3 > Environment: PHP 5.6.15 64bits >Reporter: lnn1123 >Assignee: lnn1123 > Fix For: 0.10.0 > > > when Varint(int64_val) more than five bytes parseing error, > parse the five byte should be $hi |= (($byte & 0x7f) >> ($shift - 24)); > becouse the five byte high bits should be high four bits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3883) Go TestAllConnection can fail with port 9090 collision
[
https://issues.apache.org/jira/browse/THRIFT-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422178#comment-15422178
]
Aki Sukegawa commented on THRIFT-3883:
--
Recently it's happening for most builds. A possible contributing factor is
Travis-CI image change.
{quote}
Due to the outage earlier today,
https://www.traviscistatus.com/incidents/2p40l49r3yxd, many users are seeing
builds fail due to differences in the new default sudo-enabled Precise and
Trusty images. (...)
Aug 9, 23:48 UTC
{quote}
https://www.traviscistatus.com/
> Go TestAllConnection can fail with port 9090 collision
> --
>
> Key: THRIFT-3883
> URL: https://issues.apache.org/jira/browse/THRIFT-3883
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library, Test Suite
> Environment: Travis-CI
>Reporter: Aki Sukegawa
> Labels: test-stability
>
> Just observed a new type of flaky test on Travis-CI.
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/145533626/log.txt
> {code}
> GOPATH=`pwd` /usr/local/go/bin/go test -v common/...
> === RUN TestAllConnection
> --- FAIL: TestAllConnection (0.00s)
> clientserver_test.go:51: common.test_unit{host:"127.0.0.1", port:9090,
> domain_socket:"", transport:"", protocol:"binary", ssl:false}
> clientserver_test.go:65: Unable to start server%!(EXTRA
> *net.OpError=listen tcp 127.0.0.1:9090: bind: address already in use)
> FAIL
> exit status 1
> FAIL common 0.004s
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
