[GitHub] thrift issue #1380: Support x64 build mode on Windows with DMD v2.076.0.
Github user Heromyth commented on the issue: https://github.com/apache/thrift/pull/1380 Yes, it still needs more works. I'll check them all. ---
[jira] [Commented] (THRIFT-4187) Dart -> Rust Framed cross tests fail
[ https://issues.apache.org/jira/browse/THRIFT-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386835#comment-16386835 ] ASF GitHub Bot commented on THRIFT-4187: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1269 This needs to be rebased and completed. > Dart -> Rust Framed cross tests fail > > > Key: THRIFT-4187 > URL: https://issues.apache.org/jira/browse/THRIFT-4187 > Project: Thrift > Issue Type: Bug > Components: Rust - Library >Reporter: Allen George >Assignee: Allen George >Priority: Minor > > For some reason the Dart (client) -> Rust (server) framed-transport cross > tests fail. Initial investigation shows that *somehow* the dart client think > the socket was closed, which means it doesn't read the message from the > underlying transport. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1269: THRIFT-4187 Allow dart framed transport to read incomple...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1269 This needs to be rebased and completed. ---
[jira] [Commented] (THRIFT-4488) Performance impact of Nagle disabled
[
https://issues.apache.org/jira/browse/THRIFT-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386745#comment-16386745
]
Rocco Corsi commented on THRIFT-4488:
-
Issue was discussed some time ago here
https://issues.apache.org/jira/browse/THRIFT-904
Discussion in THRIFT-904 mentions that TFramed might have a two packet on the
wire issue (due to two writes being used) and that would lead one to conclude
that TBuffered would all be written with one call. Don't know if this applies
to both C# and C++, but I assume both are now implementing the same and this
issue (TFramed with two write calls) is all fixed.
Wondering if there could be something wrong in our OS or application that could
cause these packets to be broken up into many very small packets (usually one
data byte per packet), or if this is a real Thrift issue?!?
> Performance impact of Nagle disabled
>
>
> Key: THRIFT-4488
> URL: https://issues.apache.org/jira/browse/THRIFT-4488
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.10.0
>Reporter: Rocco Corsi
>Priority: Major
>
> Running a SUSE 12 SP2 x86_64 C++ Thrift Server that is using OpenSSL. Our
> thrift service uses all Oneway methods exclusively, so a Java client sends
> request Oneway and C++ server responds with Oneway method calls too.
> Noticed that the packets from Java client API method calls were mostly
> contained within one or two packets, but C++ server responses are being split
> over many packets. Often 1 data byte per packet. This is not really a good
> use of SSL protocol. Under high load, too many extra packets can exhaust
> random data cache and stale SSL library.
> As an experiment, re-enabled Nagle's Algorithm on C++ Thrift server (modified
> TServerSocket.cpp) and did tests at various load levels with various number
> of java clients. Comparing results with Nagle disabled and enabled,
> performance improvements varied from -10% to +40%, most of the results were
> on the plus side.
> Additionally, also working with wireshark developer to decode thrift traffic
> and the large number of packets that need to be reassembled is causing huge
> headaches to program the dissector. Hopefully he can fix that, but seems
> very difficult from what he tells me.
> Our C++ Thrift Server is based on TBufferedProtocol and TBinaryProtocol.
> Briefly tried changing to TFramed, but that didn't appear to make any
> difference, and client didn't work any longer (we did try to change it to
> match server, maybe we did something wrong).
> Is there a problem with the way we are creating our C++ Thrift server
> (TBuffered + TBinary), see further below for more complete info? Shouldn't
> the TBufferedProcotol send complete API messages and prevent the large number
> of packets? Is TBinaryProtocol the problem?
> Would it be asking too much to allow Thrift Server user the choice to enable
> Nagle or not during server creation?
> or
> Is there a problem with TBufferedProtocol or TBinaryProtocol or something
> else we are doing wrong?
> Thanks for your time.
> This is how we create our C++ Thrift server
> {code:java}
> shared_ptr handlerFactory(new
> NappServiceHandlerFactory());
> shared_ptr processorFactory(new
> toNappProcessorFactory(handlerFactory));
> shared_ptr transportFactory(new
> TBufferedTransportFactory());
> shared_ptr protocolFactory(new
> TBinaryProtocolFactory());
> shared_ptr
> threadManager(ThreadManager::newSimpleThreadManager(NUMBER_OF_SERVER_THREADS));
> shared_ptr threadFactory =
> shared_ptr(new PlatformThreadFactory());
> threadManager->threadFactory(threadFactory);
> threadManager->start();
> shared_ptr socket(
> nappServerSocketBuilder->buildSSLServerSocket(
> nappServerSocketBuilder->getPortNumber(), s_sslConfig));
> shared_ptr serverTransport(socket);
> shared_ptr server( new TThreadPoolServer(processorFactory,
> serverTransport,
> transportFactory,
> protocolFactory,
> threadManager));
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (THRIFT-4354) TSocket block on read
[
https://issues.apache.org/jira/browse/THRIFT-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reassigned THRIFT-4354:
--
Assignee: James E. King, III (was: Robert Lu)
> TSocket block on read
> -
>
> Key: THRIFT-4354
> URL: https://issues.apache.org/jira/browse/THRIFT-4354
> Project: Thrift
> Issue Type: Bug
> Components: PHP - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: php7.0 + macOS
>Reporter: Robert Lu
>Assignee: James E. King, III
>Priority: Major
>
> When \Thrift\Transport\TSocket::read is called, it will block until receive
> $len
> byte([TSocket.php#L273-L276|https://github.com/apache/thrift/blob/master/lib/php/lib/Thrift/Transport/TSocket.php#L273-L276])
> But, sometimes, other call TSocket::read with large length,
> such as
> [TBufferedTransport|https://github.com/apache/thrift/blob/39310dad793ca69b4b7217a3b54430e682e5e2a4/lib/php/lib/Thrift/Transport/TBufferedTransport.php#L136-L138]:
> {code}
> if (TStringFuncFactory::create()->strlen($this->rBuf_) === 0) {
> $this->rBuf_ = $this->transport_->read($this->rBufSize_);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (THRIFT-4507) TWaitableNamedPipeImpl::read race condition can cause hang in ~TWaitableNamedPipeImpl
Jeremy Spiegel created THRIFT-4507:
--
Summary: TWaitableNamedPipeImpl::read race condition can cause
hang in ~TWaitableNamedPipeImpl
Key: THRIFT-4507
URL: https://issues.apache.org/jira/browse/THRIFT-4507
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.11.0
Reporter: Jeremy Spiegel
If the other side of the pipe disconnects in between a call to endAsyncRead and
beginAsyncRead, then the beginAsyncRead will throw, but
~TWaitableNamedPipeImpl will hang inside GetOverlappedResult. Here is some test
code that reproduces the issue:
{code}
std::promise serverStarted, clientStarted, serverReadStarted,
clientDestroyed;
std::thread serverThread([&] {
auto server =
boost::make_shared("pipe-test", 64 *
1024, 1);
server->listen();
serverStarted.set_value();
auto serverConnection = server->accept();
clientStarted.get_future().wait();
uint8_t buf[1024];
serverConnection->read(buf, 1);
serverReadStarted.set_value();
clientDestroyed.get_future().wait();
try {
serverConnection->read(buf, 1023);
} catch (const apache::thrift::transport::TTransportException&) {
}
});
serverStarted.get_future().wait();
{
auto client =
boost::make_shared("pipe-test");
client->open();
uint8_t buf[1024]{};
client->write(buf, 1024);
clientStarted.set_value();
serverReadStarted.get_future().wait();
}
clientDestroyed.set_value();
serverThread.join();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1380: Support x64 build mode on Windows with DMD v2.076.0.
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1380 The tutorials didn't get updated and as a result fail to build in the autotools build (build/docket/script/autotools.sh) which is what some of the Travis CI build jobs do. I am attempting to fix this. ---
[jira] [Resolved] (THRIFT-4505) python build on Vagrant Windows boxes fails
[ https://issues.apache.org/jira/browse/THRIFT-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4505. Resolution: Fixed > python build on Vagrant Windows boxes fails > --- > > Key: THRIFT-4505 > URL: https://issues.apache.org/jira/browse/THRIFT-4505 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.11.0 > Environment: vagrant, windows >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Minor > Fix For: 0.12.0 > > > The Windows version of os library doesn't have attribute link. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Common Lisp support is being added to Apache Thrift!
Hi folks, We're adding another language to the Apache Thrift stable! Folks can now use Apache Thrift to communicate with Common Lisp applications. The addition of Common Lisp brings the supported number of languages to a very impressive total of 26. This addition is currently available in the development tip (master) and not yet in an official release, but adding support for a new language is a milestone event for the project so I felt it should be broadcast out. I have updated the language matrix on the web site to reflect this addition and also did some work figuring out which thrift version each language first appeared in: http://thrift.apache.org/docs/Languages.html Thanks, Jim
[jira] [Resolved] (THRIFT-4506) Remove assertion in Java SASL code that would be ignored in release builds
[ https://issues.apache.org/jira/browse/THRIFT-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4506. Resolution: Fixed > Remove assertion in Java SASL code that would be ignored in release builds > -- > > Key: THRIFT-4506 > URL: https://issues.apache.org/jira/browse/THRIFT-4506 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Minor > Labels: SASL, security > Fix For: 0.12.0 > > > There is an assertion in the SASL transport for Java that will only be > processed in debug builds, at > https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/transport/TSaslTransport.java#L298. > The preceeding while loop can be changed to guarantee this assertion in all > builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4506) Remove assertion in Java SASL code that would be ignored in release builds
James E. King, III created THRIFT-4506: -- Summary: Remove assertion in Java SASL code that would be ignored in release builds Key: THRIFT-4506 URL: https://issues.apache.org/jira/browse/THRIFT-4506 Project: Thrift Issue Type: Bug Components: Java - Library Affects Versions: 0.11.0 Reporter: James E. King, III Assignee: James E. King, III Fix For: 0.12.0 There is an assertion in the SASL transport for Java that will only be processed in debug builds, at https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/transport/TSaslTransport.java#L298. The preceeding while loop can be changed to guarantee this assertion in all builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1448: Thrift-4441: Support compilation without Boost
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1448 Thanks, that's incredibly helpful when it comes to merging it. ---
[GitHub] thrift issue #1448: Thrift-4441: Support compilation without Boost
Github user Typz commented on the issue: https://github.com/apache/thrift/pull/1448 Squashed everything in one big patch. ---
[GitHub] thrift issue #1499: Fix python build on Vagrant Windows boxes
Github user earada commented on the issue: https://github.com/apache/thrift/pull/1499 @jeking3 I'm sorry, I'll follow the instructions next time. Thanks! ---
[jira] [Commented] (THRIFT-4489) Unix domain socket support for NodeJS client
[ https://issues.apache.org/jira/browse/THRIFT-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386077#comment-16386077 ] ASF GitHub Bot commented on THRIFT-4489: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1491 Where does the "--type uds" option get passed into the python test client or server in order to convince it to use domain sockets? In other test suites like cpp, only "--domain_socket" is required in order to force it to use "domain". > Unix domain socket support for NodeJS client > > > Key: THRIFT-4489 > URL: https://issues.apache.org/jira/browse/THRIFT-4489 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.11.0 >Reporter: Daniel Shih >Assignee: James E. King, III >Priority: Major > > I would like to use Unix domain sockets for NodeJS client, > Here is the proposed PR: https://github.com/apache/thrift/pull/1491 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1491: THRIFT-4489: Add UDS support for nodejs thrift client
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1491 Where does the "--type uds" option get passed into the python test client or server in order to convince it to use domain sockets? In other test suites like cpp, only "--domain_socket" is required in order to force it to use "domain". ---
[GitHub] thrift pull request #1499: Fix python build on Vagrant Windows boxes
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1499 ---
[jira] [Commented] (THRIFT-4505) python build on Vagrant Windows boxes fails
[ https://issues.apache.org/jira/browse/THRIFT-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386070#comment-16386070 ] ASF GitHub Bot commented on THRIFT-4505: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1499 THRIFT-4505 > python build on Vagrant Windows boxes fails > --- > > Key: THRIFT-4505 > URL: https://issues.apache.org/jira/browse/THRIFT-4505 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.11.0 > Environment: vagrant, windows >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Minor > Fix For: 0.12.0 > > > The Windows version of os library doesn't have attribute link. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1499: Fix python build on Vagrant Windows boxes
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1499 THRIFT-4505 ---
[jira] [Created] (THRIFT-4505) python build on Vagrant Windows boxes fails
James E. King, III created THRIFT-4505: -- Summary: python build on Vagrant Windows boxes fails Key: THRIFT-4505 URL: https://issues.apache.org/jira/browse/THRIFT-4505 Project: Thrift Issue Type: Bug Components: Python - Library Affects Versions: 0.11.0 Environment: vagrant, windows Reporter: James E. King, III Assignee: James E. King, III Fix For: 0.12.0 The Windows version of os library doesn't have attribute link. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1499: Fix python build on Vagrant Windows boxes
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1499 Hi, in the future please follow the instructions at https://thrift.apache.org/docs/HowToContribute, particularly opening a Jira ticket and tracking the pull request against it. I will do this for you this time. Thanks for the submission. ---
[jira] [Commented] (THRIFT-4436) Deserialization of nested list discards content
[
https://issues.apache.org/jira/browse/THRIFT-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386062#comment-16386062
]
ASF GitHub Bot commented on THRIFT-4436:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1457
> Deserialization of nested list discards content
> ---
>
> Key: THRIFT-4436
> URL: https://issues.apache.org/jira/browse/THRIFT-4436
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Philip Frank
>Assignee: James E. King, III
>Priority: Major
> Fix For: 0.12.0
>
>
> I'm trying to transmit a list of lists, like this:
> {code}
> service HelloSvc {
> list test()
> }
> {code}
> Using XHR Transport and JSON Protocol, with a service implementation in
> Python like this:
> {code}
> class HelloSvcHandler:
> def __init__(self):
> pass
> def test(self,):
> return [
> ["s1", "s2"],
> ["s3", "s4"],
> ["s5"]
> ]
> {code}
> The serialized response looks good to me (seen in browser development tools):
> {code}
> [1,"test",2,0,{"0":{"lst":["lst",3,["str",2,"s1","s2"],["str",2,"s3","s4"],["str",1,"s5"]]}}]
> {code}
> However, when deserialized to JavaScript, the result looks like this:
> {code}
> [["s1","s2"],[],[]]
> {code}
> I would expect it to look like this:
> {code}
> [["s1","s2"],["s3","s4"],["s5"]]
> {code}
> It looks to me like during JSON deserialization, all but the first entry in
> the list of lists lose their content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-4436) Deserialization of nested list discards content
[
https://issues.apache.org/jira/browse/THRIFT-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4436.
Resolution: Fixed
Fix Version/s: 0.12.0
Committed - thanks.
> Deserialization of nested list discards content
> ---
>
> Key: THRIFT-4436
> URL: https://issues.apache.org/jira/browse/THRIFT-4436
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Philip Frank
>Assignee: James E. King, III
>Priority: Major
> Fix For: 0.12.0
>
>
> I'm trying to transmit a list of lists, like this:
> {code}
> service HelloSvc {
> list test()
> }
> {code}
> Using XHR Transport and JSON Protocol, with a service implementation in
> Python like this:
> {code}
> class HelloSvcHandler:
> def __init__(self):
> pass
> def test(self,):
> return [
> ["s1", "s2"],
> ["s3", "s4"],
> ["s5"]
> ]
> {code}
> The serialized response looks good to me (seen in browser development tools):
> {code}
> [1,"test",2,0,{"0":{"lst":["lst",3,["str",2,"s1","s2"],["str",2,"s3","s4"],["str",1,"s5"]]}}]
> {code}
> However, when deserialized to JavaScript, the result looks like this:
> {code}
> [["s1","s2"],[],[]]
> {code}
> I would expect it to look like this:
> {code}
> [["s1","s2"],["s3","s4"],["s5"]]
> {code}
> It looks to me like during JSON deserialization, all but the first entry in
> the list of lists lose their content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift pull request #1457: THRIFT-4436: port nodejs changes from THRIFT-3748...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1457 ---
[jira] [Assigned] (THRIFT-4436) Deserialization of nested list discards content
[
https://issues.apache.org/jira/browse/THRIFT-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reassigned THRIFT-4436:
--
Assignee: James E. King, III
> Deserialization of nested list discards content
> ---
>
> Key: THRIFT-4436
> URL: https://issues.apache.org/jira/browse/THRIFT-4436
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Philip Frank
>Assignee: James E. King, III
>Priority: Major
>
> I'm trying to transmit a list of lists, like this:
> {code}
> service HelloSvc {
> list test()
> }
> {code}
> Using XHR Transport and JSON Protocol, with a service implementation in
> Python like this:
> {code}
> class HelloSvcHandler:
> def __init__(self):
> pass
> def test(self,):
> return [
> ["s1", "s2"],
> ["s3", "s4"],
> ["s5"]
> ]
> {code}
> The serialized response looks good to me (seen in browser development tools):
> {code}
> [1,"test",2,0,{"0":{"lst":["lst",3,["str",2,"s1","s2"],["str",2,"s3","s4"],["str",1,"s5"]]}}]
> {code}
> However, when deserialized to JavaScript, the result looks like this:
> {code}
> [["s1","s2"],[],[]]
> {code}
> I would expect it to look like this:
> {code}
> [["s1","s2"],["s3","s4"],["s5"]]
> {code}
> It looks to me like during JSON deserialization, all but the first entry in
> the list of lists lose their content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
