[jira] [Commented] (THRIFT-4480) NodeJS warning on binary_protocol writeMessageEnd when seqid = 0

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4480:


GitHub user bforbis opened a pull request:

https://github.com/apache/thrift/pull/1487

THRIFT-4480 - Handle seqid = 0



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bforbis/thrift THRIFT-4480

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1487.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1487


commit 8dbe2ef0a0b5a7baf3ce9fe7df6a246f855d6599
Author: Brian Forbis 
Date:   2018-01-31T05:34:55Z

THRIFT-4480 - Handle seqid = 0




> NodeJS warning on binary_protocol writeMessageEnd when seqid = 0
> 
>
> Key: THRIFT-4480
> URL: https://issues.apache.org/jira/browse/THRIFT-4480
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.11.0
>Reporter: Brian Forbis
>Priority: Minor
>
> The nodeJS implementation of binary protocol has some internal state that 
> keeps track of the `seqid` between calls to `writeMessageBegin` and 
> `writeMessageEnd`. There is a line that will emit a warning if the seqid 
> can't be unset:
> {code:java}
> TBinaryProtocol.prototype.writeMessageEnd = function() {
> if (this._seqid) {
> this._seqid = null;
> } else {
> log.warning('No seqid to unset');
> }
> };{code}
>  
> but it does not take into account that the seqid can be set to "0" which is a 
> falsey value. This causes warnings to be emitted for valid messages.
> This bug can be reproduced by connecting a perl client to a nodeJS server. 
> Perl will always send a sequenceID of 0, causing the warning to occur every 
> time the node server responds to an RPC request.
>  
> Even though this warn line has been in the nodeJS library for several 
> releases, the bug only affects thrift version 11 because until that version 
> the logger had not been implemented yet and would swallow all warnings.
>  



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

[GitHub] thrift pull request #1487: THRIFT-4480 - Handle seqid = 0

[bforbis]

GitHub user bforbis opened a pull request:

https://github.com/apache/thrift/pull/1487

THRIFT-4480 - Handle seqid = 0



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bforbis/thrift THRIFT-4480

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1487.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1487


commit 8dbe2ef0a0b5a7baf3ce9fe7df6a246f855d6599
Author: Brian Forbis 
Date:   2018-01-31T05:34:55Z

THRIFT-4480 - Handle seqid = 0




---

[jira] [Commented] (THRIFT-4484) C++ codegen invalid for optional self-membership

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4484:


Github user ringerc commented on the issue:

https://github.com/apache/thrift/pull/84
  
Created as https://issues.apache.org/jira/browse/THRIFT-4484


> C++ codegen invalid for optional self-membership
> 
>
> Key: THRIFT-4484
> URL: https://issues.apache.org/jira/browse/THRIFT-4484
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Compiler
>Affects Versions: 0.11.0
> Environment: Thrift 0.10.0 tested, but I don't see a change in 
> 0.11.0. Fedora 25. gcc 6.4.1. x86_64.
>Reporter: Craig Ringer
>Priority: Minor
>
> Support was added for self-referential objects in in 
> [https://github.com/apache/thrift/pull/84] "Tree/Recursive struct support in 
> thrift".
>  
> The tests cover objects that are co-recursive, objects that have lists of 
> themselves, etc. But there's no test for optional self-containment e.g.
> {code}
> struct RecSelf {
>1: i16 item
>2: optional RecSelf 
>  }
> {code}
> This works fine for languages like Java and Go. But in C++ it generates 
> nonsensical code that cannot compile because it contains a by-value member of 
> its self and a separate {{isset}} member.
> For example, from opentracing jaeger's IDL:
> {code}
> struct Downstream {
> 1: required string serviceName
> 2: required string serverRole
> 3: required string host
> 4: required string port
> 5: required Transport transport
> 6: optional Downstream downstream
> }
> {code}
> code-generation produces
> {code}
> class Downstream {
>  public:
>  
>   /* blah elided blah */
>   virtual ~Downstream() throw();
>   std::string serviceName;
>   std::string serverRole;
>   std::string host;
>   std::string port;
>   Transport::type transport;
>   Downstream downstream;
>   _Downstream__isset __isset;
>   /* blah elided blah */
> };
> {code}
> Compilation fails with
> {code}
> tracetest_types.h:64:14: error: field ‘downstream’ has incomplete type 
> ‘jaegertracing::crossdock::thrift::Downstream’
>Downstream downstream;
>   ^~
> tracetest_types.h:47:7: note: definition of ‘class 
> jaegertracing::crossdock::thrift::Downstream’ is not complete until the 
> closing brace
>  class Downstream {
>^~
> {code}
> I'd argue that the {{__isset}} model is not ideal, and a 
> {{std::expected}}-like "optional" or "maybe" construct would be a lot better. 
> But presumably there are historical reasons for that.
> The simplest correct solution would be to generate
> {code}
> class Downstream {
>   /* ... */
>   std::shared_ptr downstream;
>   /* ... */
> };
> {code}
> instead.



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

[jira] [Updated] (THRIFT-4484) C++ codegen invalid for optional self-membership

[Craig Ringer (JIRA)]

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

Craig Ringer updated THRIFT-4484:
-
Description: 
Support was added for self-referential objects in in 
[https://github.com/apache/thrift/pull/84] "Tree/Recursive struct support in 
thrift".

 
The tests cover objects that are co-recursive, objects that have lists of 
themselves, etc. But there's no test for optional self-containment e.g.

{code}
struct RecSelf {
   1: i16 item
   2: optional RecSelf 
 }
{code}

This works fine for languages like Java and Go. But in C++ it generates 
nonsensical code that cannot compile because it contains a by-value member of 
its self and a separate {{isset}} member.

For example, from opentracing jaeger's IDL:

{code}
struct Downstream {
1: required string serviceName
2: required string serverRole
3: required string host
4: required string port
5: required Transport transport
6: optional Downstream downstream
}
{code}

code-generation produces

{code}
class Downstream {
 public:
 
  /* blah elided blah */

  virtual ~Downstream() throw();
  std::string serviceName;
  std::string serverRole;
  std::string host;
  std::string port;
  Transport::type transport;
  Downstream downstream;

  _Downstream__isset __isset;

  /* blah elided blah */
};
{code}

Compilation fails with

{code}
tracetest_types.h:64:14: error: field ‘downstream’ has incomplete type 
‘jaegertracing::crossdock::thrift::Downstream’
   Downstream downstream;
  ^~

tracetest_types.h:47:7: note: definition of ‘class 
jaegertracing::crossdock::thrift::Downstream’ is not complete until the closing 
brace
 class Downstream {
   ^~
{code}

I'd argue that the {{__isset}} model is not ideal, and a {{std::expected}}-like 
"optional" or "maybe" construct would be a lot better. But presumably there are 
historical reasons for that.

The simplest correct solution would be to generate

{code}

class Downstream {
  /* ... */

  std::shared_ptr downstream;

  /* ... */
};

{code}

instead.

  was:
Support was added for self-referential objects in in 
[https://github.com/apache/thrift/pull/84] "Tree/Recursive struct support in 
thrift".

 

The tests cover objects that are co-recursive, objects that have lists of 
themselves, etc. But there's no test for optional self-containment e.g.

{{{
struct RecSelf {
   1: i16 item
   2: optional RecSelf 
 }
}}}

This works fine for languages like Java and Go. But in C++ it generates 
nonsensical code that cannot compile because it contains a by-value member of 
its self and a separate {{isset}} member.

For example, from opentracing jaeger's IDL:

{{{
struct Downstream {
1: required string serviceName
2: required string serverRole
3: required string host
4: required string port
5: required Transport transport
6: optional Downstream downstream
}
}}}

code-generation produces

{{{
class Downstream {
 public:
 
  /* blah elided blah */

  virtual ~Downstream() throw();
  std::string serviceName;
  std::string serverRole;
  std::string host;
  std::string port;
  Transport::type transport;
  Downstream downstream;

  _Downstream__isset __isset;

  /* blah elided blah */
};
}}}

Compilation fails with

{{{
tracetest_types.h:64:14: error: field ‘downstream’ has incomplete type 
‘jaegertracing::crossdock::thrift::Downstream’
   Downstream downstream;
  ^~

tracetest_types.h:47:7: note: definition of ‘class 
jaegertracing::crossdock::thrift::Downstream’ is not complete until the closing 
brace
 class Downstream {
   ^~
}}}

I'd argue that the {{__isset}} model is not ideal, and a {{std::expected}}-like 
"optional" or "maybe" construct would be a lot better. But presumably there are 
historical reasons for that.

The simplest correct solution would be to generate

{{{

class Downstream {
  /* ... */

  std::shared_ptr downstream;

  /* ... */
};

}}}

instead.


> C++ codegen invalid for optional self-membership
> 
>
> Key: THRIFT-4484
> URL: https://issues.apache.org/jira/browse/THRIFT-4484
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Compiler
>Affects Versions: 0.11.0
> Environment: Thrift 0.10.0 tested, but I don't see a change in 
> 0.11.0. Fedora 25. gcc 6.4.1. x86_64.
>Reporter: Craig Ringer
>Priority: Minor
>
> Support was added for self-referential objects in in 
> [https://github.com/apache/thrift/pull/84] "Tree/Recursive struct support in 
> thrift".
>  
> The tests cover objects that are co-recursive, objects that have lists of 
> themselves, etc. But there's no test for optional self-containment e.g.
> {code}
> struct RecSelf {
>1: i16 item
>2: optional RecSelf 
>  }
> {code}
> This works fine for languages like Java and Go. But in C++ it 

[GitHub] thrift issue #84: Tree/Recursive struct support in thrift

[ringerc]

Github user ringerc commented on the issue:

https://github.com/apache/thrift/pull/84
  
Created as https://issues.apache.org/jira/browse/THRIFT-4484


---

[jira] [Created] (THRIFT-4484) C++ codegen invalid for optional self-membership

[Craig Ringer (JIRA)]

Craig Ringer created THRIFT-4484:


 Summary: C++ codegen invalid for optional self-membership
 Key: THRIFT-4484
 URL: https://issues.apache.org/jira/browse/THRIFT-4484
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Compiler
Affects Versions: 0.11.0
 Environment: Thrift 0.10.0 tested, but I don't see a change in 0.11.0. 
Fedora 25. gcc 6.4.1. x86_64.
Reporter: Craig Ringer


Support was added for self-referential objects in in 
[https://github.com/apache/thrift/pull/84] "Tree/Recursive struct support in 
thrift".

 

The tests cover objects that are co-recursive, objects that have lists of 
themselves, etc. But there's no test for optional self-containment e.g.

{{{
struct RecSelf {
   1: i16 item
   2: optional RecSelf 
 }
}}}

This works fine for languages like Java and Go. But in C++ it generates 
nonsensical code that cannot compile because it contains a by-value member of 
its self and a separate {{isset}} member.

For example, from opentracing jaeger's IDL:

{{{
struct Downstream {
1: required string serviceName
2: required string serverRole
3: required string host
4: required string port
5: required Transport transport
6: optional Downstream downstream
}
}}}

code-generation produces

{{{
class Downstream {
 public:
 
  /* blah elided blah */

  virtual ~Downstream() throw();
  std::string serviceName;
  std::string serverRole;
  std::string host;
  std::string port;
  Transport::type transport;
  Downstream downstream;

  _Downstream__isset __isset;

  /* blah elided blah */
};
}}}

Compilation fails with

{{{
tracetest_types.h:64:14: error: field ‘downstream’ has incomplete type 
‘jaegertracing::crossdock::thrift::Downstream’
   Downstream downstream;
  ^~

tracetest_types.h:47:7: note: definition of ‘class 
jaegertracing::crossdock::thrift::Downstream’ is not complete until the closing 
brace
 class Downstream {
   ^~
}}}

I'd argue that the {{__isset}} model is not ideal, and a {{std::expected}}-like 
"optional" or "maybe" construct would be a lot better. But presumably there are 
historical reasons for that.

The simplest correct solution would be to generate

{{{

class Downstream {
  /* ... */

  std::shared_ptr downstream;

  /* ... */
};

}}}

instead.



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

[GitHub] thrift issue #84: Tree/Recursive struct support in thrift

[ringerc]

Github user ringerc commented on the issue:

https://github.com/apache/thrift/pull/84
  
I see a bunch of mutual recursive structure support in the tests, but 
nothing for an optional single self-referential member, like

```
struct RecSelf {
   1: i16 item
   2: optional RecSelf 
 }
```

Thift does not appear to generate sensible code for this. The example I am 
working with is from the opentracing jaeger toolset, namely the IDL

```
struct Downstream {
1: required string serviceName
2: required string serverRole
3: required string host
4: required string port
5: required Transport transport
6: optional Downstream downstream
}
```

This works fine in Java, Go, etc. But in C++ it produces the nonsensical 
code

```
class Downstream {
 public:
 
  /* blah elided blah */

  virtual ~Downstream() throw();
  std::string serviceName;
  std::string serverRole;
  std::string host;
  std::string port;
  Transport::type transport;
  Downstream downstream;

  _Downstream__isset __isset;

  /* blah elided blah */
};
```

in which the class is a by-value member of its self.

I think the ideal solution here would be to adopt something like 
`std::optional` (c++17 proposal) as a `thrift::optional` and use that instead 
of the `__isset` stuff for optional members. But backwards compatibility could 
be a problem.


---

[jira] [Created] (THRIFT-4483) Java TSaslTransport does not respect SASL RAW_SEND_SIZE

[Dan Burkert (JIRA)]

Dan Burkert created THRIFT-4483:
---

 Summary: Java TSaslTransport does not respect SASL RAW_SEND_SIZE
 Key: THRIFT-4483
 URL: https://issues.apache.org/jira/browse/THRIFT-4483
 Project: Thrift
  Issue Type: Bug
Affects Versions: 0.11.0
Reporter: Dan Burkert


The Java {{TSaslTransport}}, when auth-conf or auth-int is enabled, doesn't 
respect the SASL negotiated maximum send buffer size.  The result is that the 
Thrift SASL transport will transmit SASL encoded frames larger than the buffer 
size, the receiver may not be able to decode.

The JDK's {{SaslOutputStream}} handles this correctly by 'packetizing' the 
outgoing message; see 
[SaslOutputStream.write|https://github.com/dmlloyd/openjdk/blob/342a565a2da8abd69c4ab85e285bb5f03b48b2c9/src/java.naming/share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java#L74-L102]
 for an example, especially how the {{recvMaxBufSize}} field is used.

This is problematic for Thrift implementations which use RFC 4422 compliant 
SASL implementations such as Cyrus SASL, since large messages sent by the Java 
implementation can't be received.



--
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.

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1380
  
I can't (well, won't) merge a PR with 100 commits.  I also fixed dmd 
invocation on linux earlier today and fixed the link ordering issue.  So if you 
can rebase and squash to one commit, that would be helpful.  Linux is using 
2.077.1 on the artful build; 2.078.0 and higher fail with a backwards 
incompatibility issue, I believe.


---

[jira] [Created] (THRIFT-4482) error making c++ library on windows 8.1 using cygwin

[Michel Max (JIRA)]

Michel Max created THRIFT-4482:
--

 Summary: error making c++ library on windows 8.1 using cygwin
 Key: THRIFT-4482
 URL: https://issues.apache.org/jira/browse/THRIFT-4482
 Project: Thrift
  Issue Type: Bug
  Components: Build Process, C++ - Library
Affects Versions: 0.11.0
 Environment: Windows 8.1, thrift 0.11.0

cygwin64, boost 1_66, GNU make 4.2.1, g++ 6.4.0, automake 1.15.1, autoconf 2.69
Reporter: Michel Max


src/thrift/transport/THttpServer.cpp: In member function 'virtual void 
apache::thrift::transport::THttpServer::parseHeader(char*)':
src/thrift/transport/THttpServer.cpp:50:74: error: 'strcasestr' was not 
declared in this scope
   #define THRIFT_strcasestr(haystack, needle) strcasestr(haystack, needle)
  ^
src/thrift/transport/THttpServer.cpp:62:9: note: in expansion of macro 
'THRIFT_strcasestr'
 if (THRIFT_strcasestr(value, "chunked") != NULL) {
 ^
make[4]: *** [Makefile:1350: src/thrift/transport/THttpServer.lo] Error 1

 

This is a part of the console output, but it is the entire error. This happened 
during the execution of make in the root directory.



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

[jira] [Created] (THRIFT-4481) TBinaryProtocol.writeMessageEnd isn't trowable exception

[Anton Shchyrov (JIRA)]

Anton Shchyrov created THRIFT-4481:
--

 Summary: TBinaryProtocol.writeMessageEnd isn't trowable exception
 Key: THRIFT-4481
 URL: https://issues.apache.org/jira/browse/THRIFT-4481
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.11.0
Reporter: Anton Shchyrov


In base class TProtocol method writeMessageEnd can throw exception TException

{{public abstract void writeStructEnd() throws TException;}}

In this class this method is overridden by an empty implementation and already 
can not throw exceptions

{{public void writeMessageEnd() {}}
{{}}}

I want to extend the capabilities of the class TBinaryProtocol and override 
this method. But I can not throw an exception from it or call a method that can 
throw an exception

A similar remark on all methods of a class TBinaryProtocol with an empty body



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

[jira] [Commented] (THRIFT-4337) Able to set keyStore and trustStore as InputStream in the TSSLTransportFactory.TSSLTransportParameters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4337:


GitHub user dmvolod opened a pull request:

https://github.com/apache/thrift/pull/1486

THRIFT-4337: Able to set keyStore and trustStore as InputStream in the 
TSSLTransportFactory.TSSLTransportParameters

Plus some tests cleanup

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dmvolod/thrift THRIFT-4337

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1486.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1486


commit 9effb959985d13441029883d0e7151f287511c3c
Author: Dmitry Volodin 
Date:   2018-01-30T15:59:41Z

THRIFT-4337: Able to set keyStore and trustStore as InputStream in the
TSSLTransportFactory.TSSLTransportParameters




> Able to set keyStore and trustStore as InputStream in the 
> TSSLTransportFactory.TSSLTransportParameters
> --
>
> Key: THRIFT-4337
> URL: https://issues.apache.org/jira/browse/THRIFT-4337
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Priority: Major
>
> There are a lot cases available, when requires to set keyStore and trustStore 
> not only as file location, but as InputStream. It's easy and good to add this 
> feature to the Thrift Java library. 



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

[GitHub] thrift pull request #1486: THRIFT-4337: Able to set keyStore and trustStore ...

[dmvolod]

GitHub user dmvolod opened a pull request:

https://github.com/apache/thrift/pull/1486

THRIFT-4337: Able to set keyStore and trustStore as InputStream in the 
TSSLTransportFactory.TSSLTransportParameters

Plus some tests cleanup

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dmvolod/thrift THRIFT-4337

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1486.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1486


commit 9effb959985d13441029883d0e7151f287511c3c
Author: Dmitry Volodin 
Date:   2018-01-30T15:59:41Z

THRIFT-4337: Able to set keyStore and trustStore as InputStream in the
TSSLTransportFactory.TSSLTransportParameters




---

[jira] [Updated] (THRIFT-4480) NodeJS warning on binary_protocol writeMessageEnd when seqid = 0

[Brian Forbis (JIRA)]

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

Brian Forbis updated THRIFT-4480:
-
Priority: Minor  (was: Trivial)

> NodeJS warning on binary_protocol writeMessageEnd when seqid = 0
> 
>
> Key: THRIFT-4480
> URL: https://issues.apache.org/jira/browse/THRIFT-4480
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.11.0
>Reporter: Brian Forbis
>Priority: Minor
>
> The nodeJS implementation of binary protocol has some internal state that 
> keeps track of the `seqid` between calls to `writeMessageBegin` and 
> `writeMessageEnd`. There is a line that will emit a warning if the seqid 
> can't be unset:
> {code:java}
> TBinaryProtocol.prototype.writeMessageEnd = function() {
> if (this._seqid) {
> this._seqid = null;
> } else {
> log.warning('No seqid to unset');
> }
> };{code}
>  
> but it does not take into account that the seqid can be set to "0" which is a 
> falsey value. This causes warnings to be emitted for valid messages.
> This bug can be reproduced by connecting a perl client to a nodeJS server. 
> Perl will always send a sequenceID of 0, causing the warning to occur every 
> time the node server responds to an RPC request.
>  
> Even though this warn line has been in the nodeJS library for several 
> releases, the bug only affects thrift version 11 because until that version 
> the logger had not been implemented yet and would swallow all warnings.
>  



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

[jira] [Created] (THRIFT-4480) NodeJS warning on binary_protocol writeMessageEnd when seqid = 0

[Brian Forbis (JIRA)]

Brian Forbis created THRIFT-4480:


 Summary: NodeJS warning on binary_protocol writeMessageEnd when 
seqid = 0
 Key: THRIFT-4480
 URL: https://issues.apache.org/jira/browse/THRIFT-4480
 Project: Thrift
  Issue Type: Bug
  Components: Node.js - Library
Affects Versions: 0.11.0
Reporter: Brian Forbis


The nodeJS implementation of binary protocol has some internal state that keeps 
track of the `seqid` between calls to `writeMessageBegin` and 
`writeMessageEnd`. There is a line that will emit a warning if the seqid can't 
be unset:
{code:java}
TBinaryProtocol.prototype.writeMessageEnd = function() {
if (this._seqid) {
this._seqid = null;
} else {
log.warning('No seqid to unset');
}
};{code}
 

but it does not take into account that the seqid can be set to "0" which is a 
falsey value. This causes warnings to be emitted for valid messages.

This bug can be reproduced by connecting a perl client to a nodeJS server. Perl 
will always send a sequenceID of 0, causing the warning to occur every time the 
node server responds to an RPC request.

 

Even though this warn line has been in the nodeJS library for several releases, 
the bug only affects thrift version 11 because until that version the logger 
had not been implemented yet and would swallow all warnings.

 



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

[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4474:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1479
  
If we are making breaking changes, they need to be documented very clearly 
in the php/README.md file as part of any commit.  See my breaking changes for 
0.10.0 and 0.11.0 in the perl/README.md for an example of what I mean.  I'm not 
certain anybody on the mailing list is listening at this point, but if anyone 
has an interest in php breaking changes, you need to chime in.


> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via 
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The 
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which 
> can only load via classmap), add {{classmap}} option.



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

[GitHub] thrift issue #1479: THRIFT-4474: generate PHP code use PSR-4 style default

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1479
  
If we are making breaking changes, they need to be documented very clearly 
in the php/README.md file as part of any commit.  See my breaking changes for 
0.10.0 and 0.11.0 in the perl/README.md for an example of what I mean.  I'm not 
certain anybody on the mailing list is listening at this point, but if anyone 
has an interest in php breaking changes, you need to chime in.


---

[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4474:


Github user RobberPhex commented on the issue:

https://github.com/apache/thrift/pull/1479
  
Personally, I think we can mark classmap/old-style PHP compiler deprecated. 
And can be removed in future.

And, ThriftClassLoader can also be removed in future, to migrate composer 
autoloader.


> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via 
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The 
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which 
> can only load via classmap), add {{classmap}} option.



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

[GitHub] thrift issue #1479: THRIFT-4474: generate PHP code use PSR-4 style default

[RobberPhex]

Github user RobberPhex commented on the issue:

https://github.com/apache/thrift/pull/1479
  
Personally, I think we can mark classmap/old-style PHP compiler deprecated. 
And can be removed in future.

And, ThriftClassLoader can also be removed in future, to migrate composer 
autoloader.


---

[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4474:


Github user RobberPhex commented on the issue:

https://github.com/apache/thrift/pull/1479
  
There are some break changes:

1. for generated code, old struct is `Types.php` for all args, results, 
`.php` for `ServiceIf`, `ServiceClient`, etc.
  new struct is `.php` for ``. Maybe cause some code 
analyzer doesn't work.
2. for ThriftClassloader. before, user use 
`$loader->registerDefinition('namespace', '')`. 
  At new struct, **it doesn't work**. user can use 
`$composerLoader->addPsr4('namespace', '')` or 
`$thriftLoader->registerNamespace('namespace', '')`.
3. for composer loader, generated code loaded via classmap. With new 
struct, composer's classmap can also load psr-4 code. (of cause psr-4 is 
recommended).



> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via 
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The 
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which 
> can only load via classmap), add {{classmap}} option.



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

[GitHub] thrift issue #1479: THRIFT-4474: generate PHP code use PSR-4 style default

[RobberPhex]

Github user RobberPhex commented on the issue:

https://github.com/apache/thrift/pull/1479
  
There are some break changes:

1. for generated code, old struct is `Types.php` for all args, results, 
`.php` for `ServiceIf`, `ServiceClient`, etc.
  new struct is `.php` for ``. Maybe cause some code 
analyzer doesn't work.
2. for ThriftClassloader. before, user use 
`$loader->registerDefinition('namespace', '')`. 
  At new struct, **it doesn't work**. user can use 
`$composerLoader->addPsr4('namespace', '')` or 
`$thriftLoader->registerNamespace('namespace', '')`.
3. for composer loader, generated code loaded via classmap. With new 
struct, composer's classmap can also load psr-4 code. (of cause psr-4 is 
recommended).



---

[GitHub] thrift issue #1484: TBufferedTransport must have underlying transport

[RobberPhex]

Github user RobberPhex commented on the issue:

https://github.com/apache/thrift/pull/1484
  
CI isn't stable.

It's so headache. :(


---

[jira] [Resolved] (THRIFT-4308) D language docker images need demios for libevent and openssl fixed to re-enable make cross on dlang

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4308.

   Resolution: Fixed
Fix Version/s: 0.12.0

> D language docker images need demios for libevent and openssl fixed to 
> re-enable make cross on dlang
> 
>
> Key: THRIFT-4308
> URL: https://issues.apache.org/jira/browse/THRIFT-4308
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process, D - Library
>Affects Versions: 0.11.0
> Environment: docker:ubuntu-xenial
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Major
> Fix For: 0.12.0
>
>
> I had to disable the deimos hooks for libevent and openssl because they were 
> causing build failures in 0.11.0.  A result of this change is that dlang is 
> NOT tested in "make cross" at all, because the test executables are only 
> generated if openssl support exists, and it does not.
> It turns out this is some sort of link ordering issue.  On further diagnosis, 
> the dmd command outputs this build line when you add -v:
> {noformat}
> root@f82a62661052:/thrift/src/lib/d/test# cc client_pool_test.o -o 
> client_pool_test -m64 -levent -lssl -lcrypto -L/usr/lib/x86_64-linux-gnu 
> -Xlinker --export-dynamic ../../../lib/d/libthriftd.a ../libthriftd-event.a 
> ../libthriftd-ssl.a -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread 
> -lm -lrt -ldl
> ../libthriftd-event.a(libevent_1_846.o): In function 
> `_D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager':
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0x11):
>  undefined reference to `event_base_new'
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0xa3):
>  undefined reference to `event_new'
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0xb1):
>  undefined reference to `event_add'
> {noformat}
> If you add -Wl,--start-group before the event library, OR move event, ssl, 
> and crypto to the end of the library list, the link completes.



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

[jira] [Commented] (THRIFT-4308) D language docker images need demios for libevent and openssl fixed to re-enable make cross on dlang

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4308:


Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1483


> D language docker images need demios for libevent and openssl fixed to 
> re-enable make cross on dlang
> 
>
> Key: THRIFT-4308
> URL: https://issues.apache.org/jira/browse/THRIFT-4308
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process, D - Library
>Affects Versions: 0.11.0
> Environment: docker:ubuntu-xenial
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Major
> Fix For: 0.12.0
>
>
> I had to disable the deimos hooks for libevent and openssl because they were 
> causing build failures in 0.11.0.  A result of this change is that dlang is 
> NOT tested in "make cross" at all, because the test executables are only 
> generated if openssl support exists, and it does not.
> It turns out this is some sort of link ordering issue.  On further diagnosis, 
> the dmd command outputs this build line when you add -v:
> {noformat}
> root@f82a62661052:/thrift/src/lib/d/test# cc client_pool_test.o -o 
> client_pool_test -m64 -levent -lssl -lcrypto -L/usr/lib/x86_64-linux-gnu 
> -Xlinker --export-dynamic ../../../lib/d/libthriftd.a ../libthriftd-event.a 
> ../libthriftd-ssl.a -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread 
> -lm -lrt -ldl
> ../libthriftd-event.a(libevent_1_846.o): In function 
> `_D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager':
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0x11):
>  undefined reference to `event_base_new'
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0xa3):
>  undefined reference to `event_new'
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0xb1):
>  undefined reference to `event_add'
> {noformat}
> If you add -Wl,--start-group before the event library, OR move event, ssl, 
> and crypto to the end of the library list, the link completes.



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

[GitHub] thrift pull request #1483: THRIFT-4308: re-enable dlang deimos build support...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1483


---

[GitHub] thrift issue #1483: THRIFT-4308: re-enable dlang deimos build support for li...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1483
  
The concurrency test failed, which is a known intermittent issue.


---

[jira] [Commented] (THRIFT-4308) D language docker images need demios for libevent and openssl fixed to re-enable make cross on dlang

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4308:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1483
  
The concurrency test failed, which is a known intermittent issue.


> D language docker images need demios for libevent and openssl fixed to 
> re-enable make cross on dlang
> 
>
> Key: THRIFT-4308
> URL: https://issues.apache.org/jira/browse/THRIFT-4308
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process, D - Library
>Affects Versions: 0.11.0
> Environment: docker:ubuntu-xenial
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Major
>
> I had to disable the deimos hooks for libevent and openssl because they were 
> causing build failures in 0.11.0.  A result of this change is that dlang is 
> NOT tested in "make cross" at all, because the test executables are only 
> generated if openssl support exists, and it does not.
> It turns out this is some sort of link ordering issue.  On further diagnosis, 
> the dmd command outputs this build line when you add -v:
> {noformat}
> root@f82a62661052:/thrift/src/lib/d/test# cc client_pool_test.o -o 
> client_pool_test -m64 -levent -lssl -lcrypto -L/usr/lib/x86_64-linux-gnu 
> -Xlinker --export-dynamic ../../../lib/d/libthriftd.a ../libthriftd-event.a 
> ../libthriftd-ssl.a -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread 
> -lm -lrt -ldl
> ../libthriftd-event.a(libevent_1_846.o): In function 
> `_D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager':
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0x11):
>  undefined reference to `event_base_new'
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0xa3):
>  undefined reference to `event_new'
> src/thrift/async/libevent.d:(.text._D6thrift5async8libevent21TLibeventAsyncManager6__ctorMFZC6thrift5async8libevent21TLibeventAsyncManager+0xb1):
>  undefined reference to `event_add'
> {noformat}
> If you add -Wl,--start-group before the event library, OR move event, ssl, 
> and crypto to the end of the library list, the link completes.



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

[jira] [Updated] (THRIFT-4477) TBufferedTransport must have underlying transport

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4477:
---
Priority: Minor  (was: Major)

> TBufferedTransport must have underlying transport
> -
>
> Key: THRIFT-4477
> URL: https://issues.apache.org/jira/browse/THRIFT-4477
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.11.0
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Minor
> Fix For: 0.12.0
>
>
> for TBufferedTransport,
> the underlying transport cannot be null. many methods used underlying 
> transport directly, if it's null, will cause error. And a null as underlying 
> transport for TBufferedTransport makes no sense.
> So, TBufferedTransport must have underlying transport



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

[jira] [Commented] (THRIFT-4477) TBufferedTransport must have underlying transport

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4477:


Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1484


> TBufferedTransport must have underlying transport
> -
>
> Key: THRIFT-4477
> URL: https://issues.apache.org/jira/browse/THRIFT-4477
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.11.0
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
> Fix For: 0.12.0
>
>
> for TBufferedTransport,
> the underlying transport cannot be null. many methods used underlying 
> transport directly, if it's null, will cause error. And a null as underlying 
> transport for TBufferedTransport makes no sense.
> So, TBufferedTransport must have underlying transport



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

[GitHub] thrift pull request #1484: TBufferedTransport must have underlying transport

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1484


---

[jira] [Resolved] (THRIFT-4477) TBufferedTransport must have underlying transport

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4477.

   Resolution: Fixed
Fix Version/s: 0.12.0

Committed - thanks.

> TBufferedTransport must have underlying transport
> -
>
> Key: THRIFT-4477
> URL: https://issues.apache.org/jira/browse/THRIFT-4477
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.11.0
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
> Fix For: 0.12.0
>
>
> for TBufferedTransport,
> the underlying transport cannot be null. many methods used underlying 
> transport directly, if it's null, will cause error. And a null as underlying 
> transport for TBufferedTransport makes no sense.
> So, TBufferedTransport must have underlying transport



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

[GitHub] thrift issue #1484: TBufferedTransport must have underlying transport

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1484
  
The build failures are unrelated.  mingw on Windows has been failing; 
go-dart is a new possibly intermittant cross test failure.


---

[GitHub] thrift pull request #1484: TBufferedTransport must have underlying transport

[jeking3]

Github user jeking3 commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1484#discussion_r164729770
  
--- Diff: lib/php/lib/Transport/TBufferedTransport.php ---
@@ -22,6 +22,7 @@
 
 namespace Thrift\Transport;
 
+use Thrift\Exception\TTransportException;
--- End diff --

My question was more for learning, and whether or not the "use" is needed 
for that to work.  I think I understand it now.


---

[GitHub] thrift pull request #1484: TBufferedTransport must have underlying transport

[jeking3]

Github user jeking3 commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1484#discussion_r164729591
  
--- Diff: lib/php/lib/Factory/TStringFuncFactory.php ---
@@ -21,8 +21,9 @@
 
 namespace Thrift\Factory;
 
-use Thrift\StringFunc\Mbstring;
 use Thrift\StringFunc\Core;
+use Thrift\StringFunc\Mbstring;
--- End diff --

In general fewer changes are better but in this case no, I don't care.  I 
do the same cleanup when I'm in files sometimes. :)


---

[jira] [Commented] (THRIFT-4429) Make TThreadPoolServer.executorService_ available in inherited classes and refactor methods to be able customization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4429:


GitHub user dmvolod opened a pull request:

https://github.com/apache/thrift/pull/1485

THRIFT-4429: Make TThreadPoolServer.executorService_ available in inherited 
classes and refactor methods to be able customization

Plus some classes cleanup from unused imports

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dmvolod/thrift THRIFT-4429

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1485.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1485


commit 63d30a0f4882ad60a399481e168759b7d293c33e
Author: Dmitry Volodin 
Date:   2018-01-30T09:09:36Z

THRIFT-4429: Make TThreadPoolServer.executorService_ available in
inherited classes and refactor methods to be able customization




> Make TThreadPoolServer.executorService_ available in inherited classes and 
> refactor methods to be able customization
> 
>
> Key: THRIFT-4429
> URL: https://issues.apache.org/jira/browse/THRIFT-4429
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Dmitry Volodin
>Priority: Minor
>
> In some cases (for example in Apache Camel component for Thrift) there is a 
> requirement, when it is necessary not only to transfer executorService from 
> the external system through the Args in TThreadPoolServer , but to organize 
> control them from outside. In this case, it's possible to create a class 
> which is inherited from TThreadPoolServer, but not possible to access invoker 
> in overloaded method.
> Also a good approach to split main execution code to the several methods to 
> be able to invoke them separately in appropriate sequence.



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

[GitHub] thrift pull request #1485: THRIFT-4429: Make TThreadPoolServer.executorServi...

[dmvolod]

GitHub user dmvolod opened a pull request:

https://github.com/apache/thrift/pull/1485

THRIFT-4429: Make TThreadPoolServer.executorService_ available in inherited 
classes and refactor methods to be able customization

Plus some classes cleanup from unused imports

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dmvolod/thrift THRIFT-4429

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1485.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1485


commit 63d30a0f4882ad60a399481e168759b7d293c33e
Author: Dmitry Volodin 
Date:   2018-01-30T09:09:36Z

THRIFT-4429: Make TThreadPoolServer.executorService_ available in
inherited classes and refactor methods to be able customization




---