[jira] [Commented] (THRIFT-4251) Java Epoll Selector Bug

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4251:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1313
  
It means nobody replied to my requests for comments, so I assumed nobody
has an issue or nobody cares; whatever the case, I committed it to the
project. :)

On Thu, Sep 21, 2017 at 9:33 PM, xiaohu-zhang 
wrote:

> MY english is poor. could you please explain what is the it's been
> crickets mean ? thank you very much!
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> , or 
mute
> the thread
> 

> .
>



> Java Epoll Selector Bug
> ---
>
> Key: THRIFT-4251
> URL: https://issues.apache.org/jira/browse/THRIFT-4251
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.10.0
> Environment: Linux version 3.10.0-327.el7.x86_64 
> (buil...@kbuilder.dev.centos.org)
> java version "1.8.0_131"
>Reporter: JohnnyLiao
>Assignee: James E. King, III
>  Labels: epoll, jdk, selector
> Fix For: 0.11.0
>
>
> Thrift java unsolve the infamous epoll bug. It's consum 100% cpu resource 
> when this occured. It seems to affect any NIO based Java server applications 
> running in the specified environment. Some projects provide workarounds for 
> similar JDK bugs, for example replaces the current Selector of this 
> SelectorThread.select with newly created Selector.
> Stack Trace：
> "Thread-46" #95 prio=5 os_prio=0 tid=0x7fc79cd02800 nid=0xb1 runnable 
> [0x7fc580bd1000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x8012f748> (a sun.nio.ch.Util$3)
> - locked <0x8012f738> (a 
> java.util.Collections$UnmodifiableSet)
> - locked <0x80120f58> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:570)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)



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

[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1313
  
It means nobody replied to my requests for comments, so I assumed nobody
has an issue or nobody cares; whatever the case, I committed it to the
project. :)

On Thu, Sep 21, 2017 at 9:33 PM, xiaohu-zhang 
wrote:

> MY english is poor. could you please explain what is the it's been
> crickets mean ? thank you very much!
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> , or 
mute
> the thread
> 

> .
>



---

[jira] [Commented] (THRIFT-4251) Java Epoll Selector Bug

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4251:


Github user xiaohu-zhang commented on the issue:

https://github.com/apache/thrift/pull/1313
  
MY english is poor. could you please explain what is the it's been crickets 
mean ? thank you very much!


> Java Epoll Selector Bug
> ---
>
> Key: THRIFT-4251
> URL: https://issues.apache.org/jira/browse/THRIFT-4251
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.10.0
> Environment: Linux version 3.10.0-327.el7.x86_64 
> (buil...@kbuilder.dev.centos.org)
> java version "1.8.0_131"
>Reporter: JohnnyLiao
>Assignee: James E. King, III
>  Labels: epoll, jdk, selector
> Fix For: 0.11.0
>
>
> Thrift java unsolve the infamous epoll bug. It's consum 100% cpu resource 
> when this occured. It seems to affect any NIO based Java server applications 
> running in the specified environment. Some projects provide workarounds for 
> similar JDK bugs, for example replaces the current Selector of this 
> SelectorThread.select with newly created Selector.
> Stack Trace：
> "Thread-46" #95 prio=5 os_prio=0 tid=0x7fc79cd02800 nid=0xb1 runnable 
> [0x7fc580bd1000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x8012f748> (a sun.nio.ch.Util$3)
> - locked <0x8012f738> (a 
> java.util.Collections$UnmodifiableSet)
> - locked <0x80120f58> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:570)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)



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

[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...

[xiaohu-zhang]

Github user xiaohu-zhang commented on the issue:

https://github.com/apache/thrift/pull/1313
  
MY english is poor. could you please explain what is the it's been crickets 
mean ? thank you very much!


---

[GitHub] thrift issue #1263: D lib updated for x64 build mode on windows

[Heromyth]

Github user Heromyth commented on the issue:

https://github.com/apache/thrift/pull/1263
  
So sad, there is a bug in phobos64.lib. It will make the examples failed.


---

[GitHub] thrift issue #1261: Replace the use of Indirect Object Syntax calls to new()

[djzort]

Github user djzort commented on the issue:

https://github.com/apache/thrift/pull/1261
  
I will get to it :)


---

[GitHub] thrift issue #1367: Fix a crash on client close

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1367
  
@dhull thank you!  Now we just need a Jira item for the change, and 
hopefully it sails through CI.


---

[GitHub] thrift issue #1367: Fix a crash on client close

[dhull]

Github user dhull commented on the issue:

https://github.com/apache/thrift/pull/1367
  
This fix looks correct to me. The `read` and `read_exact` functions both 
pull the wrapped transport out of their state, and need to put the updated 
wrapped transport back into their state on return. The change fixes that in the 
error code path in the `read` function.


---

[GitHub] thrift issue #1261: Replace the use of Indirect Object Syntax calls to new()

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1261
  
Post the Jira issue (THRIFT-) in here when you have one as well - 
thanks.


---

[GitHub] thrift issue #1367: Fix a crash on client close

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1367
  
Thanks for the fix - changes need a Jira ticket so we can track them 
through release notes.  See:

https://thrift.apache.org/docs/HowToContribute

Thanks!


---

[jira] [Created] (THRIFT-4339) Thrift Framed Transport in Erlang crashes server when client disconnects

[Anthony Molinaro (JIRA)]

Anthony Molinaro created THRIFT-4339:


 Summary: Thrift Framed Transport in Erlang crashes server when 
client disconnects
 Key: THRIFT-4339
 URL: https://issues.apache.org/jira/browse/THRIFT-4339
 Project: Thrift
  Issue Type: Bug
  Components: Erlang - Library
Affects Versions: 0.10.0
Reporter: Anthony Molinaro
Assignee: Anthony Molinaro
 Fix For: 0.11.0


I came across this when attempting to upgrade to 0.10.0.

Essentially when a client was disconnecting, it could lead to the server 
crashing later on.  This looks like it's a result of the refactoring of the 
records and maybe a copy/paste error.  The fix is super minor and is in this 
pull request

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

It would probably be a good idea to merge this prior to 0.11.0.



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

[GitHub] thrift pull request #1367: Fix a crash on client close

[djnym]

GitHub user djnym opened a pull request:

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

Fix a crash on client close

When a client closes a connection to a framed server the server was
crashing because the fact that the transport was framed was being
lost.  Looking through the file I noticed that the block from lines
87-95, looked different from the one from 59-66.  The culprit was
that when an error was occuring in the 59-66 block it was being
propagated up without rewrapping.  That would cause a failure
much further up the chain.  This patch fixes it.

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

$ git pull https://github.com/djnym/thrift erlang-framed-transport-fix

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

https://github.com/apache/thrift/pull/1367.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 #1367


commit 6662e2498e8866bbf8b81ca40108db9a69a10fa3
Author: Anthony Molinaro 
Date:   2017-09-21T23:13:33Z

Fix a crash on client close

When a client closes a connection to a framed server the server was
crashing because the fact that the transport was framed was being
lost.  Looking through the file I noticed that the block from lines
87-95, looked different from the one from 59-66.  The culprit was
that when an error was occuring in the 59-66 block it was being
propagated up without rewrapping.  That would cause a failure
much further up the chain.  This patch fixes it.




---

[jira] [Commented] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4233:


Github user asfgit closed the pull request at:

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


> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> 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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[jira] [Commented] (THRIFT-4326) Ruby BufferedTransport not safe for reuse after reading corrupted input

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4326:


Github user benweint commented on the issue:

https://github.com/apache/thrift/pull/1352
  
Ah, interesting! It looks like the nodejs tests are using a Ruby server as 
part of some integration testing? I'll see if I can repro this failure locally 
and figure out what's up. Thanks!


> Ruby BufferedTransport not safe for reuse after reading corrupted input
> ---
>
> Key: THRIFT-4326
> URL: https://issues.apache.org/jira/browse/THRIFT-4326
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.10.0
> Environment: Originally observed with Thrift 0.9.3 on Linux with Ruby 
> 2.3.4, but have also reproduced on Mac OS X with Thrift 0.10.0.
>Reporter: Ben Weintraub
>
> We've experimented with the Ruby {{BufferedTransport}} class as a wrapper 
> around the {{HttpClientTransport}} class, and found that we were getting 
> clusters sporadic {{Thrift::ProtocolException}} errors in Ruby client 
> processes after network issues caused corruption of some Thrift response 
> bodies.
> Using a bare {{HttpClientTransport}} makes these issues disappear.
> For a given service, we retain a long-lived protocol instance 
> ({{CompactProtocol}} in our case), which in turn holds a reference to a 
> long-lived {{BufferedTransport}} instance.
> The problem seems to stem from the case where the Thrift client is 
> interrupted (e.g. by a Ruby timeout exception) before consuming to the end of 
> the {{@rbuf}} instance variable in {{BufferedTransport}}, leaving {{@index}} 
> pointing to the middle of the read buffer, and meaning that when the 
> transport is re-used upon the next service call, the {{BufferedTransport}} 
> continues reading where it left off in the old buffer, rather than calling 
> through to the wrapped {{HttpClientTransport}} to read the new response 
> obtained from the last call to {{#flush}}.
> Now I know {{Timeout}} is fundamentally unsafe in Ruby and can lead to all 
> kinds of issues like this, but I've also found that this same issue can be 
> triggered by another fairly plausible scenario: if the Thrift service returns 
> a well-formed Thrift response but with N extra bytes of garbage tacked onto 
> the end, then the next N following service calls through the same 
> {{BufferedTransport}} instance will fail with a 
> {{Thrift::ProtocolException}}, as the {{BufferedTransport}} will continue 
> attempting to read the left-over bytes in {{@rbuf}}.
> The naive solution seems like it would be to just reset {{@rbuf}} from 
> {{#flush}}.



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

[jira] [Resolved] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4233.

   Resolution: Fixed
Fix Version/s: 0.11.0

> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> 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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[GitHub] thrift pull request #1366: THRIFT-4233 Make THsHaServer.invoker available (g...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift issue #1352: THRIFT-4326 Allow safer reuse of BufferedTransport insta...

[benweint]

Github user benweint commented on the issue:

https://github.com/apache/thrift/pull/1352
  
Ah, interesting! It looks like the nodejs tests are using a Ruby server as 
part of some integration testing? I'll see if I can repro this failure locally 
and figure out what's up. Thanks!


---

[jira] [Commented] (THRIFT-4326) Ruby BufferedTransport not safe for reuse after reading corrupted input

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4326:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1352
  
@benweint so this error is reproducible in the ubuntu-xenial docker image, 
and it looks like it is related to ruby and wasn't happening before, so it's 
likely related to these changes.
```

===
*** Following 2 failures were unexpected ***:
If it is introduced by you, please fix it before submitting the code.

===
server-client:  protocol: transport:   result:
rb-nodejs   json  buffered-ip  
failure(1)
rb-nodejs   binarybuffered-ip  
failure(1)

===
```


> Ruby BufferedTransport not safe for reuse after reading corrupted input
> ---
>
> Key: THRIFT-4326
> URL: https://issues.apache.org/jira/browse/THRIFT-4326
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.10.0
> Environment: Originally observed with Thrift 0.9.3 on Linux with Ruby 
> 2.3.4, but have also reproduced on Mac OS X with Thrift 0.10.0.
>Reporter: Ben Weintraub
>
> We've experimented with the Ruby {{BufferedTransport}} class as a wrapper 
> around the {{HttpClientTransport}} class, and found that we were getting 
> clusters sporadic {{Thrift::ProtocolException}} errors in Ruby client 
> processes after network issues caused corruption of some Thrift response 
> bodies.
> Using a bare {{HttpClientTransport}} makes these issues disappear.
> For a given service, we retain a long-lived protocol instance 
> ({{CompactProtocol}} in our case), which in turn holds a reference to a 
> long-lived {{BufferedTransport}} instance.
> The problem seems to stem from the case where the Thrift client is 
> interrupted (e.g. by a Ruby timeout exception) before consuming to the end of 
> the {{@rbuf}} instance variable in {{BufferedTransport}}, leaving {{@index}} 
> pointing to the middle of the read buffer, and meaning that when the 
> transport is re-used upon the next service call, the {{BufferedTransport}} 
> continues reading where it left off in the old buffer, rather than calling 
> through to the wrapped {{HttpClientTransport}} to read the new response 
> obtained from the last call to {{#flush}}.
> Now I know {{Timeout}} is fundamentally unsafe in Ruby and can lead to all 
> kinds of issues like this, but I've also found that this same issue can be 
> triggered by another fairly plausible scenario: if the Thrift service returns 
> a well-formed Thrift response but with N extra bytes of garbage tacked onto 
> the end, then the next N following service calls through the same 
> {{BufferedTransport}} instance will fail with a 
> {{Thrift::ProtocolException}}, as the {{BufferedTransport}} will continue 
> attempting to read the left-over bytes in {{@rbuf}}.
> The naive solution seems like it would be to just reset {{@rbuf}} from 
> {{#flush}}.



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

[GitHub] thrift issue #1352: THRIFT-4326 Allow safer reuse of BufferedTransport insta...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1352
  
@benweint so this error is reproducible in the ubuntu-xenial docker image, 
and it looks like it is related to ruby and wasn't happening before, so it's 
likely related to these changes.
```

===
*** Following 2 failures were unexpected ***:
If it is introduced by you, please fix it before submitting the code.

===
server-client:  protocol: transport:   result:
rb-nodejs   json  buffered-ip  
failure(1)
rb-nodejs   binarybuffered-ip  
failure(1)

===
```


---

[jira] [Commented] (THRIFT-4326) Ruby BufferedTransport not safe for reuse after reading corrupted input

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4326:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1352
  
Ugh, clearly we STILL have some build issues.  They are in js though.  I'll 
pull your commit into my local system and try to reproduce this build issue 
and/or get a clean set of cross tests so I can commit this.  Thanks for your 
patience.


> Ruby BufferedTransport not safe for reuse after reading corrupted input
> ---
>
> Key: THRIFT-4326
> URL: https://issues.apache.org/jira/browse/THRIFT-4326
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.10.0
> Environment: Originally observed with Thrift 0.9.3 on Linux with Ruby 
> 2.3.4, but have also reproduced on Mac OS X with Thrift 0.10.0.
>Reporter: Ben Weintraub
>
> We've experimented with the Ruby {{BufferedTransport}} class as a wrapper 
> around the {{HttpClientTransport}} class, and found that we were getting 
> clusters sporadic {{Thrift::ProtocolException}} errors in Ruby client 
> processes after network issues caused corruption of some Thrift response 
> bodies.
> Using a bare {{HttpClientTransport}} makes these issues disappear.
> For a given service, we retain a long-lived protocol instance 
> ({{CompactProtocol}} in our case), which in turn holds a reference to a 
> long-lived {{BufferedTransport}} instance.
> The problem seems to stem from the case where the Thrift client is 
> interrupted (e.g. by a Ruby timeout exception) before consuming to the end of 
> the {{@rbuf}} instance variable in {{BufferedTransport}}, leaving {{@index}} 
> pointing to the middle of the read buffer, and meaning that when the 
> transport is re-used upon the next service call, the {{BufferedTransport}} 
> continues reading where it left off in the old buffer, rather than calling 
> through to the wrapped {{HttpClientTransport}} to read the new response 
> obtained from the last call to {{#flush}}.
> Now I know {{Timeout}} is fundamentally unsafe in Ruby and can lead to all 
> kinds of issues like this, but I've also found that this same issue can be 
> triggered by another fairly plausible scenario: if the Thrift service returns 
> a well-formed Thrift response but with N extra bytes of garbage tacked onto 
> the end, then the next N following service calls through the same 
> {{BufferedTransport}} instance will fail with a 
> {{Thrift::ProtocolException}}, as the {{BufferedTransport}} will continue 
> attempting to read the left-over bytes in {{@rbuf}}.
> The naive solution seems like it would be to just reset {{@rbuf}} from 
> {{#flush}}.



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

[GitHub] thrift issue #1352: THRIFT-4326 Allow safer reuse of BufferedTransport insta...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1352
  
Ugh, clearly we STILL have some build issues.  They are in js though.  I'll 
pull your commit into my local system and try to reproduce this build issue 
and/or get a clean set of cross tests so I can commit this.  Thanks for your 
patience.


---

[GitHub] thrift pull request #1253: THRIFT-3357: Generate EnumSet/EnumMap where eleme...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (THRIFT-3357) Generate EnumSet/EnumMap where elements/keys are enums

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3357:


Github user asfgit closed the pull request at:

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


> Generate EnumSet/EnumMap where elements/keys are enums
> --
>
> Key: THRIFT-3357
> URL: https://issues.apache.org/jira/browse/THRIFT-3357
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> Generate EnumSet/EnumMap instead of HashSet/HashMap where elements/keys are 
> enums.
> This makes these maps/sets memory efficient and faster.



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

[jira] [Assigned] (THRIFT-3357) Generate EnumSet/EnumMap where elements/keys are enums

[James E. King, III (JIRA)]

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

James E. King, III reassigned THRIFT-3357:
--

Assignee: James E. King, III

> Generate EnumSet/EnumMap where elements/keys are enums
> --
>
> Key: THRIFT-3357
> URL: https://issues.apache.org/jira/browse/THRIFT-3357
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> Generate EnumSet/EnumMap instead of HashSet/HashMap where elements/keys are 
> enums.
> This makes these maps/sets memory efficient and faster.



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

[jira] [Resolved] (THRIFT-3357) Generate EnumSet/EnumMap where elements/keys are enums

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-3357.

   Resolution: Fixed
Fix Version/s: 0.11.0

Committed, thanks.

> Generate EnumSet/EnumMap where elements/keys are enums
> --
>
> Key: THRIFT-3357
> URL: https://issues.apache.org/jira/browse/THRIFT-3357
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> Generate EnumSet/EnumMap instead of HashSet/HashMap where elements/keys are 
> enums.
> This makes these maps/sets memory efficient and faster.



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

[GitHub] thrift issue #1366: THRIFT-4233 Make THsHaServer.invoker available (get meth...

[dmvolod]

Github user dmvolod commented on the issue:

https://github.com/apache/thrift/pull/1366
  
@jeking3 , please review. The static is not acceptable to getInvoker as 
invoker is not static context


---

[jira] [Commented] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4233:


Github user dmvolod commented on the issue:

https://github.com/apache/thrift/pull/1366
  
@jeking3 , please review. The static is not acceptable to getInvoker as 
invoker is not static context


> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Assignee: James E. King, III
>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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[jira] [Commented] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4233:


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

https://github.com/apache/thrift/pull/1294#discussion_r140350410
  
--- Diff: lib/java/src/org/apache/thrift/server/THsHaServer.java ---
@@ -154,7 +154,10 @@ protected static ExecutorService 
createInvokerPool(Args options) {
 
 return invoker;
   }
-
+  
+  protected ExecutorService getInvoker() {
--- End diff --

Yes, you are right. I will close this PR, as I'm unable to add commit to 
this PR (remove remote repo) and create a new one.
Thank you.


> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Assignee: James E. King, III
>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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[jira] [Commented] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4233:


Github user dmvolod closed the pull request at:

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


> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Assignee: James E. King, III
>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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[GitHub] thrift pull request #1294: THRIFT-4233 Make THsHaServer.invoker available (g...

[dmvolod]

Github user dmvolod closed the pull request at:

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


---

[GitHub] thrift pull request #1294: THRIFT-4233 Make THsHaServer.invoker available (g...

[dmvolod]

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

https://github.com/apache/thrift/pull/1294#discussion_r140350410
  
--- Diff: lib/java/src/org/apache/thrift/server/THsHaServer.java ---
@@ -154,7 +154,10 @@ protected static ExecutorService 
createInvokerPool(Args options) {
 
 return invoker;
   }
-
+  
+  protected ExecutorService getInvoker() {
--- End diff --

Yes, you are right. I will close this PR, as I'm unable to add commit to 
this PR (remove remote repo) and create a new one.
Thank you.


---

[jira] [Commented] (THRIFT-4187) Dart -> Rust Framed cross tests fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4187:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1269
  
This pull request needs to be completed.  *nudge*


> 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
(v6.4.14#64029)

[GitHub] thrift issue #1263: D lib updated for x64 build mode on windows

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1263
  
@Heromyth any progress on this?


---

[GitHub] thrift issue #1269: THRIFT-4187 Allow dart framed transport to read incomple...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1269
  
This pull request needs to be completed.  *nudge*


---

[jira] [Commented] (THRIFT-4206) Strings in container fields are not decoded properly with py:dynamic and py:utf8strings

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4206:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1273
  
Could you rebase on master and refresh the PR so we get a clean build, now 
that CI is stable again?  Thanks.


> Strings in container fields are not decoded properly with py:dynamic and 
> py:utf8strings
> ---
>
> Key: THRIFT-4206
> URL: https://issues.apache.org/jira/browse/THRIFT-4206
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
>Reporter: Elvis Pranskevichus
> Fix For: 0.11.0
>
>
> {{_read_by_ttype}} and {{_write_by_ttype}} must be using the *element* spec
> and not the container spec when determining the correct read/write
> handler.



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

[GitHub] thrift issue #1273: THRIFT-4206: Fix decoding of strings in containers with ...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1273
  
Could you rebase on master and refresh the PR so we get a clean build, now 
that CI is stable again?  Thanks.


---

[jira] [Commented] (THRIFT-4207) Accelerated version of TBinaryProtocol allows invalid input to string fields.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4207:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
Could you rebase on master and refresh the PR so we get a clean build, now 
that CI is stable again?  Thanks.


> Accelerated version of TBinaryProtocol allows invalid input to string fields.
> -
>
> Key: THRIFT-4207
> URL: https://issues.apache.org/jira/browse/THRIFT-4207
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.10.0
>Reporter: Elvis Pranskevichus
> Fix For: 0.11.0
>
>
> {{TBinaryProtocolAccelerated}} and {{TCompactProtocolAccelerated}} currently 
> accept arbitrary bytes as input to string fields even when {{py:utf8strings}} 
> is on.



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

[GitHub] thrift issue #1274: THRIFT-4207: Make sure Python Accelerated protocol does ...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
Could you rebase on master and refresh the PR so we get a clean build, now 
that CI is stable again?  Thanks.


---

[GitHub] thrift issue #1289: fix TypeError when a py3 str is passed to the function.

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1289
  
Could you open a Jira ticker for this?

https://thrift.apache.org/docs/HowToContribute

Also could you rebase on master and refresh the PR so we get a clean build, 
now that CI is stable again?  Thanks.


---

[jira] [Commented] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4233:


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

https://github.com/apache/thrift/pull/1294#discussion_r140344024
  
--- Diff: lib/java/src/org/apache/thrift/server/THsHaServer.java ---
@@ -154,7 +154,10 @@ protected static ExecutorService 
createInvokerPool(Args options) {
 
 return invoker;
   }
-
+  
+  protected ExecutorService getInvoker() {
--- End diff --

This could probably be static, given the method above is also static?  
Thoughts?


> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Assignee: James E. King, III
>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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[GitHub] thrift pull request #1294: THRIFT-4233 Make THsHaServer.invoker available (g...

[jeking3]

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

https://github.com/apache/thrift/pull/1294#discussion_r140344024
  
--- Diff: lib/java/src/org/apache/thrift/server/THsHaServer.java ---
@@ -154,7 +154,10 @@ protected static ExecutorService 
createInvokerPool(Args options) {
 
 return invoker;
   }
-
+  
+  protected ExecutorService getInvoker() {
--- End diff --

This could probably be static, given the method above is also static?  
Thoughts?


---

[jira] [Assigned] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[James E. King, III (JIRA)]

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

James E. King, III reassigned THRIFT-4233:
--

Assignee: James E. King, III

> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Dmitry Volodin
>Assignee: James E. King, III
>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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[jira] [Updated] (THRIFT-4233) Make THsHaServer.invoker available (get method only) in inherited classes

[James E. King, III (JIRA)]

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

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

> Make THsHaServer.invoker available (get method only) in inherited classes
> -
>
> Key: THRIFT-4233
> URL: https://issues.apache.org/jira/browse/THRIFT-4233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.10.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 THsHaServer , but to organize control 
> them from outside. In this case, it's possible to create a class which is 
> inherited from THsHaServer, but not possible to access invoker in overloaded 
> gracefullyShutdownInvokerPool(). As workaround the TNonblockingServer must be 
> extended but requires to create several methods from scratch.
> It's necessary to add code below to THsHaServer
> {code:java}
> protected ExecutorService getInvoker() {
>   return invoker;
> }
> {code}
> I'm ready to add this code as PR.



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

[GitHub] thrift issue #1306: Fix Nodejs generation to auto deal with args class insta...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1306
  
@wenshin first of all my apologies for having no comments or interactions 
since you submitted the PR a month ago.  As you may have seen we had some CI 
build issues which are now resolved, and your PR has a conflict.  Could you 
rebase this on the current master and push to refresh this PR and kick a build?

Also, changes need Jira tickets.  See:

https://thrift.apache.org/docs/HowToContribute


---

[GitHub] thrift issue #1311: Fix for constant assignments to optional fields in Go.

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1311
  
@davinchia we've cleared out the CI build issues, so if you could squash 
your changes to one commit then rebase on master, then do a force push to 
refresh this pull request, it'll kick off a new build.  Squashing will make it 
easier to apply the patch when the build completes successfully.


---

[jira] [Commented] (THRIFT-4251) Java Epoll Selector Bug

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4251:


Github user asfgit closed the pull request at:

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


> Java Epoll Selector Bug
> ---
>
> Key: THRIFT-4251
> URL: https://issues.apache.org/jira/browse/THRIFT-4251
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.10.0
> Environment: Linux version 3.10.0-327.el7.x86_64 
> (buil...@kbuilder.dev.centos.org)
> java version "1.8.0_131"
>Reporter: JohnnyLiao
>Assignee: James E. King, III
>  Labels: epoll, jdk, selector
> Fix For: 0.11.0
>
>
> Thrift java unsolve the infamous epoll bug. It's consum 100% cpu resource 
> when this occured. It seems to affect any NIO based Java server applications 
> running in the specified environment. Some projects provide workarounds for 
> similar JDK bugs, for example replaces the current Selector of this 
> SelectorThread.select with newly created Selector.
> Stack Trace：
> "Thread-46" #95 prio=5 os_prio=0 tid=0x7fc79cd02800 nid=0xb1 runnable 
> [0x7fc580bd1000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x8012f748> (a sun.nio.ch.Util$3)
> - locked <0x8012f738> (a 
> java.util.Collections$UnmodifiableSet)
> - locked <0x80120f58> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:570)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)



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

[jira] [Updated] (THRIFT-4251) Java Epoll Selector Bug

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4251:
---
Summary: Java Epoll Selector Bug  (was: Epoll Selector Bug)

> Java Epoll Selector Bug
> ---
>
> Key: THRIFT-4251
> URL: https://issues.apache.org/jira/browse/THRIFT-4251
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.10.0
> Environment: Linux version 3.10.0-327.el7.x86_64 
> (buil...@kbuilder.dev.centos.org)
> java version "1.8.0_131"
>Reporter: JohnnyLiao
>Assignee: James E. King, III
>  Labels: epoll, jdk, selector
> Fix For: 0.11.0
>
>
> Thrift java unsolve the infamous epoll bug. It's consum 100% cpu resource 
> when this occured. It seems to affect any NIO based Java server applications 
> running in the specified environment. Some projects provide workarounds for 
> similar JDK bugs, for example replaces the current Selector of this 
> SelectorThread.select with newly created Selector.
> Stack Trace：
> "Thread-46" #95 prio=5 os_prio=0 tid=0x7fc79cd02800 nid=0xb1 runnable 
> [0x7fc580bd1000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x8012f748> (a sun.nio.ch.Util$3)
> - locked <0x8012f738> (a 
> java.util.Collections$UnmodifiableSet)
> - locked <0x80120f58> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:570)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)



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

[jira] [Resolved] (THRIFT-4251) Epoll Selector Bug

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4251.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.11.0

Committed, thanks for the fix.

> Epoll Selector Bug
> --
>
> Key: THRIFT-4251
> URL: https://issues.apache.org/jira/browse/THRIFT-4251
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.10.0
> Environment: Linux version 3.10.0-327.el7.x86_64 
> (buil...@kbuilder.dev.centos.org)
> java version "1.8.0_131"
>Reporter: JohnnyLiao
>Assignee: James E. King, III
>  Labels: epoll, jdk, selector
> Fix For: 0.11.0
>
>
> Thrift java unsolve the infamous epoll bug. It's consum 100% cpu resource 
> when this occured. It seems to affect any NIO based Java server applications 
> running in the specified environment. Some projects provide workarounds for 
> similar JDK bugs, for example replaces the current Selector of this 
> SelectorThread.select with newly created Selector.
> Stack Trace：
> "Thread-46" #95 prio=5 os_prio=0 tid=0x7fc79cd02800 nid=0xb1 runnable 
> [0x7fc580bd1000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x8012f748> (a sun.nio.ch.Util$3)
> - locked <0x8012f738> (a 
> java.util.Collections$UnmodifiableSet)
> - locked <0x80120f58> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:570)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)



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

[GitHub] thrift pull request #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThrea...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (THRIFT-4251) Epoll Selector Bug

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4251:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1313
  
So I asked on the mailing list and it's been crickets, so I'm going to 
merge this.  It passed all the tests.


> Epoll Selector Bug
> --
>
> Key: THRIFT-4251
> URL: https://issues.apache.org/jira/browse/THRIFT-4251
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.10.0
> Environment: Linux version 3.10.0-327.el7.x86_64 
> (buil...@kbuilder.dev.centos.org)
> java version "1.8.0_131"
>Reporter: JohnnyLiao
>  Labels: epoll, jdk, selector
>
> Thrift java unsolve the infamous epoll bug. It's consum 100% cpu resource 
> when this occured. It seems to affect any NIO based Java server applications 
> running in the specified environment. Some projects provide workarounds for 
> similar JDK bugs, for example replaces the current Selector of this 
> SelectorThread.select with newly created Selector.
> Stack Trace：
> "Thread-46" #95 prio=5 os_prio=0 tid=0x7fc79cd02800 nid=0xb1 runnable 
> [0x7fc580bd1000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x8012f748> (a sun.nio.ch.Util$3)
> - locked <0x8012f738> (a 
> java.util.Collections$UnmodifiableSet)
> - locked <0x80120f58> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:570)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)



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

[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1313
  
So I asked on the mailing list and it's been crickets, so I'm going to 
merge this.  It passed all the tests.


---

[jira] [Commented] (THRIFT-4326) Ruby BufferedTransport not safe for reuse after reading corrupted input

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4326:


Github user benweint commented on the issue:

https://github.com/apache/thrift/pull/1352
  
Yup, rebased!


> Ruby BufferedTransport not safe for reuse after reading corrupted input
> ---
>
> Key: THRIFT-4326
> URL: https://issues.apache.org/jira/browse/THRIFT-4326
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.10.0
> Environment: Originally observed with Thrift 0.9.3 on Linux with Ruby 
> 2.3.4, but have also reproduced on Mac OS X with Thrift 0.10.0.
>Reporter: Ben Weintraub
>
> We've experimented with the Ruby {{BufferedTransport}} class as a wrapper 
> around the {{HttpClientTransport}} class, and found that we were getting 
> clusters sporadic {{Thrift::ProtocolException}} errors in Ruby client 
> processes after network issues caused corruption of some Thrift response 
> bodies.
> Using a bare {{HttpClientTransport}} makes these issues disappear.
> For a given service, we retain a long-lived protocol instance 
> ({{CompactProtocol}} in our case), which in turn holds a reference to a 
> long-lived {{BufferedTransport}} instance.
> The problem seems to stem from the case where the Thrift client is 
> interrupted (e.g. by a Ruby timeout exception) before consuming to the end of 
> the {{@rbuf}} instance variable in {{BufferedTransport}}, leaving {{@index}} 
> pointing to the middle of the read buffer, and meaning that when the 
> transport is re-used upon the next service call, the {{BufferedTransport}} 
> continues reading where it left off in the old buffer, rather than calling 
> through to the wrapped {{HttpClientTransport}} to read the new response 
> obtained from the last call to {{#flush}}.
> Now I know {{Timeout}} is fundamentally unsafe in Ruby and can lead to all 
> kinds of issues like this, but I've also found that this same issue can be 
> triggered by another fairly plausible scenario: if the Thrift service returns 
> a well-formed Thrift response but with N extra bytes of garbage tacked onto 
> the end, then the next N following service calls through the same 
> {{BufferedTransport}} instance will fail with a 
> {{Thrift::ProtocolException}}, as the {{BufferedTransport}} will continue 
> attempting to read the left-over bytes in {{@rbuf}}.
> The naive solution seems like it would be to just reset {{@rbuf}} from 
> {{#flush}}.



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

[GitHub] thrift issue #1352: THRIFT-4326 Allow safer reuse of BufferedTransport insta...

[benweint]

Github user benweint commented on the issue:

https://github.com/apache/thrift/pull/1352
  
Yup, rebased!


---

[GitHub] thrift issue #1315: THRIFT-4264: Fix PHP tests requiring sockets.so

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1315
  
@norrs now that the CI builds have been stabilized, if you could rebase on 
master and refresh this PR, we'll try to get a clean build out of it.


---

[jira] [Commented] (THRIFT-4264) PHP - Support both shared & static linking of sockets library

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4264:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1315
  
@norrs now that the CI builds have been stabilized, if you could rebase on 
master and refresh this PR, we'll try to get a clean build out of it.


> PHP - Support both shared & static linking of sockets library
> -
>
> Key: THRIFT-4264
> URL: https://issues.apache.org/jira/browse/THRIFT-4264
> Project: Thrift
>  Issue Type: Test
>  Components: PHP - Library
>Affects Versions: 0.11.0
>Reporter: Roy Sindre Norangshol
>Priority: Minor
>
> THRIFT-4218 introduced TCP_NODELAY for the PHP client socket by the usage of 
> {code:java}
> socket_import_stream()
> {code}. This requires PHP to be buildt with --enable-sockets or 
> --enable-sockets=shared.
> Test environment should support usage of both ways of compiling PHP.



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

[GitHub] thrift pull request #1333: Add c++ compiler no_skeleton flag option (THRIFT-...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift issue #1318: Added async nonblocking ssl support in java client

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1318
  
@Jens-G does the current cross suite exercise asynchronous sufficiently to 
test these changes?


---

[jira] [Commented] (THRIFT-4287) Add c++ compiler "no_skeleton" flag option

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4287:


Github user asfgit closed the pull request at:

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


> Add c++ compiler "no_skeleton" flag option
> --
>
> Key: THRIFT-4287
> URL: https://issues.apache.org/jira/browse/THRIFT-4287
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.10.0
>Reporter: Or Yahud
>Assignee: James E. King, III
>  Labels: c++, cmd, thrift
> Fix For: 0.11.0
>
>
> Add c++ compiler "no_skeleton" flag option in case you don't wont thrift to 
> generate a "*.skeleton.cpp" file.



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

[jira] [Assigned] (THRIFT-4287) Add c++ compiler "no_skeleton" flag option

[James E. King, III (JIRA)]

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

James E. King, III reassigned THRIFT-4287:
--

Assignee: James E. King, III

> Add c++ compiler "no_skeleton" flag option
> --
>
> Key: THRIFT-4287
> URL: https://issues.apache.org/jira/browse/THRIFT-4287
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.10.0
>Reporter: Or Yahud
>Assignee: James E. King, III
>  Labels: c++, cmd, thrift
> Fix For: 0.11.0
>
>
> Add c++ compiler "no_skeleton" flag option in case you don't wont thrift to 
> generate a "*.skeleton.cpp" file.



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

[jira] [Commented] (THRIFT-4288) Implement log utilities.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4288:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1334
  
@Equim-chan now that the CI build environment has been stabilized, could 
you rebase on master and refresh this PR so we can get a clean build on it?  
Thanks.


> Implement log utilities.
> 
>
> Key: THRIFT-4288
> URL: https://issues.apache.org/jira/browse/THRIFT-4288
> Project: Thrift
>  Issue Type: Improvement
>  Components: Node.js - Library
>Reporter: Kangcheng Wang
>Priority: Minor
>  Labels: newbie
>
> Implement log.js which was empty.
> Apply log.js to all existing log operations.



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

[GitHub] thrift issue #1334: THRIFT-4288: Implement log.js

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1334
  
@Equim-chan now that the CI build environment has been stabilized, could 
you rebase on master and refresh this PR so we can get a clean build on it?  
Thanks.


---

[jira] [Commented] (THRIFT-4309) All Python files should be compatible with Python 3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4309:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1339
  
@cclauss now that the CI build issues should be squared away, could you 
rebase on master so we get another CI build?  Thanks.


> All Python files should be compatible with Python 3
> ---
>
> Key: THRIFT-4309
> URL: https://issues.apache.org/jira/browse/THRIFT-4309
> Project: Thrift
>  Issue Type: Improvement
>  Components: Python - Compiler, Python - Library
>Reporter: cclauss
>Priority: Minor
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> Python 3 is now 8 years old and is the current and future of the language.  
> Examples and other Python files in this project should be compatible with 
> Python 3 and where possible also with Python 2.
> https://docs.python.org/3/howto/pyporting.html is one of many guides on the 
> topic.



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

[GitHub] thrift issue #1339: THRIFT-4309 Python print() function

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1339
  
@cclauss now that the CI build issues should be squared away, could you 
rebase on master so we get another CI build?  Thanks.


---

[jira] [Resolved] (THRIFT-4327) Improve TimerManager API to allow removing specific task

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4327.

   Resolution: Fixed
Fix Version/s: 0.11.0

> Improve TimerManager API to allow removing specific task
> 
>
> Key: THRIFT-4327
> URL: https://issues.apache.org/jira/browse/THRIFT-4327
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: Francois Ferrand
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> The TimerManager::remove() method removes all timers with the specified 
> callback, and does so by traversing the list of timers.
> This should be improved by returning a "handle" in `TimerManager::add`, and 
> supporting efficiently removing a single timer from its handle:
> {code:java}
> class TimerManager {
>  Timer add(shared_ptr task, const struct timeval& value);
>  void remove(Timer t);
> }
> {code}



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

[jira] [Commented] (THRIFT-4326) Ruby BufferedTransport not safe for reuse after reading corrupted input

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4326:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1352
  
@benweint would you be able to rebase on master?  The CI build issues 
should be resolved now.


> Ruby BufferedTransport not safe for reuse after reading corrupted input
> ---
>
> Key: THRIFT-4326
> URL: https://issues.apache.org/jira/browse/THRIFT-4326
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.10.0
> Environment: Originally observed with Thrift 0.9.3 on Linux with Ruby 
> 2.3.4, but have also reproduced on Mac OS X with Thrift 0.10.0.
>Reporter: Ben Weintraub
>
> We've experimented with the Ruby {{BufferedTransport}} class as a wrapper 
> around the {{HttpClientTransport}} class, and found that we were getting 
> clusters sporadic {{Thrift::ProtocolException}} errors in Ruby client 
> processes after network issues caused corruption of some Thrift response 
> bodies.
> Using a bare {{HttpClientTransport}} makes these issues disappear.
> For a given service, we retain a long-lived protocol instance 
> ({{CompactProtocol}} in our case), which in turn holds a reference to a 
> long-lived {{BufferedTransport}} instance.
> The problem seems to stem from the case where the Thrift client is 
> interrupted (e.g. by a Ruby timeout exception) before consuming to the end of 
> the {{@rbuf}} instance variable in {{BufferedTransport}}, leaving {{@index}} 
> pointing to the middle of the read buffer, and meaning that when the 
> transport is re-used upon the next service call, the {{BufferedTransport}} 
> continues reading where it left off in the old buffer, rather than calling 
> through to the wrapped {{HttpClientTransport}} to read the new response 
> obtained from the last call to {{#flush}}.
> Now I know {{Timeout}} is fundamentally unsafe in Ruby and can lead to all 
> kinds of issues like this, but I've also found that this same issue can be 
> triggered by another fairly plausible scenario: if the Thrift service returns 
> a well-formed Thrift response but with N extra bytes of garbage tacked onto 
> the end, then the next N following service calls through the same 
> {{BufferedTransport}} instance will fail with a 
> {{Thrift::ProtocolException}}, as the {{BufferedTransport}} will continue 
> attempting to read the left-over bytes in {{@rbuf}}.
> The naive solution seems like it would be to just reset {{@rbuf}} from 
> {{#flush}}.



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

[jira] [Updated] (THRIFT-4327) Improve TimerManager API to allow removing specific task

[James E. King, III (JIRA)]

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

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

> Improve TimerManager API to allow removing specific task
> 
>
> Key: THRIFT-4327
> URL: https://issues.apache.org/jira/browse/THRIFT-4327
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: Francois Ferrand
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> The TimerManager::remove() method removes all timers with the specified 
> callback, and does so by traversing the list of timers.
> This should be improved by returning a "handle" in `TimerManager::add`, and 
> supporting efficiently removing a single timer from its handle:
> {code:java}
> class TimerManager {
>  Timer add(shared_ptr task, const struct timeval& value);
>  void remove(Timer t);
> }
> {code}



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

[GitHub] thrift issue #1352: THRIFT-4326 Allow safer reuse of BufferedTransport insta...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1352
  
@benweint would you be able to rebase on master?  The CI build issues 
should be resolved now.


---

[jira] [Commented] (THRIFT-4327) Improve TimerManager API to allow removing specific task

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4327:


Github user asfgit closed the pull request at:

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


> Improve TimerManager API to allow removing specific task
> 
>
> Key: THRIFT-4327
> URL: https://issues.apache.org/jira/browse/THRIFT-4327
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: Francois Ferrand
>Assignee: James E. King, III
>
> The TimerManager::remove() method removes all timers with the specified 
> callback, and does so by traversing the list of timers.
> This should be improved by returning a "handle" in `TimerManager::add`, and 
> supporting efficiently removing a single timer from its handle:
> {code:java}
> class TimerManager {
>  Timer add(shared_ptr task, const struct timeval& value);
>  void remove(Timer t);
> }
> {code}



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

[GitHub] thrift pull request #1353: THRIFT-4327: add API to efficiently remove a sing...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Updated] (THRIFT-4338) c_glib config.h header leaking into lib/cpp build and others

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4338:
---
Environment: docker ubuntu-xenial, autoconf build  (was: docker 
ubuntu-xenial)

> c_glib config.h header leaking into lib/cpp build and others
> 
>
> Key: THRIFT-4338
> URL: https://issues.apache.org/jira/browse/THRIFT-4338
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: docker ubuntu-xenial, autoconf build
>Reporter: James E. King, III
>Priority: Minor
>
> I was building in lib/cpp and saw the command line contained:
> {noformat}
> g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src/thrift 
> -I../../../lib/c_glib/src/thrift  -I/usr/include -I../../../lib/cpp/src 
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.  -Wall -Wextra -pedantic -g 
> -O2 -Wno-deprecated-register -MT SecurityTest.o -MD -MP -MF $depbase.Tpo -c 
> -o SecurityTest.o SecurityTest.cpp &&\
> {noformat}
> In configure.ac at the global level we have:
> {noformat}
> AC_CONFIG_HEADERS(config.h:config.hin)
> AC_CONFIG_HEADERS(lib/cpp/src/thrift/config.h:config.hin)
> AC_CONFIG_HEADERS(lib/c_glib/src/thrift/config.h:config.hin)
> {noformat}
> This is causing the lib/cpp include path to refer to something in c_glib.  
> Similarly if these options carry into c_glib then a lib/cpp header would 
> potentially be accessible in the c_glib build.



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

[jira] [Created] (THRIFT-4338) c_glib config.h header leaking into lib/cpp build and others

[James E. King, III (JIRA)]

James E. King, III created THRIFT-4338:
--

 Summary: c_glib config.h header leaking into lib/cpp build and 
others
 Key: THRIFT-4338
 URL: https://issues.apache.org/jira/browse/THRIFT-4338
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Affects Versions: 0.10.0
 Environment: docker ubuntu-xenial
Reporter: James E. King, III
Priority: Minor


I was building in lib/cpp and saw the command line contained:
{noformat}
g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src/thrift 
-I../../../lib/c_glib/src/thrift  -I/usr/include -I../../../lib/cpp/src 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.  -Wall -Wextra -pedantic -g 
-O2 -Wno-deprecated-register -MT SecurityTest.o -MD -MP -MF $depbase.Tpo -c -o 
SecurityTest.o SecurityTest.cpp &&\
{noformat}

In configure.ac at the global level we have:
{noformat}
AC_CONFIG_HEADERS(config.h:config.hin)
AC_CONFIG_HEADERS(lib/cpp/src/thrift/config.h:config.hin)
AC_CONFIG_HEADERS(lib/c_glib/src/thrift/config.h:config.hin)
{noformat}

This is causing the lib/cpp include path to refer to something in c_glib.  
Similarly if these options carry into c_glib then a lib/cpp header would 
potentially be accessible in the c_glib build.




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

[jira] [Assigned] (THRIFT-4327) Improve TimerManager API to allow removing specific task

[James E. King, III (JIRA)]

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

James E. King, III reassigned THRIFT-4327:
--

Assignee: James E. King, III

> Improve TimerManager API to allow removing specific task
> 
>
> Key: THRIFT-4327
> URL: https://issues.apache.org/jira/browse/THRIFT-4327
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: Francois Ferrand
>Assignee: James E. King, III
>
> The TimerManager::remove() method removes all timers with the specified 
> callback, and does so by traversing the list of timers.
> This should be improved by returning a "handle" in `TimerManager::add`, and 
> supporting efficiently removing a single timer from its handle:
> {code:java}
> class TimerManager {
>  Timer add(shared_ptr task, const struct timeval& value);
>  void remove(Timer t);
> }
> {code}



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

[jira] [Commented] (THRIFT-4232) ./configure does bad ant version check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4232:


Github user asfgit closed the pull request at:

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


> ./configure does bad ant version check
> --
>
> Key: THRIFT-4232
> URL: https://issues.apache.org/jira/browse/THRIFT-4232
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: OSX 10.12.5, running ant 1.10.1
>Reporter: David Woodward
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> On line 18869 of the configure script, it checks that the ant version is >= 
> 1.7. It uses some kind of string comparison. This breaks for my current ant 
> version (1.10). It seems to think that 1.10 is not >= 1.7. I think this is 
> because it's comparing strings without taking into account what the strings 
> actually mean. Something like this might be a possible patch:
> https://stackoverflow.com/questions/16989598/bash-comparing-version-numbers
> This should be fixed because it means that people with new ant versions can't 
> build the java thrift library.
> Also it should be checked to see if other parts of the configure process are 
> using these kinds of faulty version checks.



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

[jira] [Resolved] (THRIFT-4232) ./configure does bad ant version check

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4232.

   Resolution: Fixed
Fix Version/s: 0.11.0

> ./configure does bad ant version check
> --
>
> Key: THRIFT-4232
> URL: https://issues.apache.org/jira/browse/THRIFT-4232
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: OSX 10.12.5, running ant 1.10.1
>Reporter: David Woodward
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> On line 18869 of the configure script, it checks that the ant version is >= 
> 1.7. It uses some kind of string comparison. This breaks for my current ant 
> version (1.10). It seems to think that 1.10 is not >= 1.7. I think this is 
> because it's comparing strings without taking into account what the strings 
> actually mean. Something like this might be a possible patch:
> https://stackoverflow.com/questions/16989598/bash-comparing-version-numbers
> This should be fixed because it means that people with new ant versions can't 
> build the java thrift library.
> Also it should be checked to see if other parts of the configure process are 
> using these kinds of faulty version checks.



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

[jira] [Assigned] (THRIFT-4232) ./configure does bad ant version check

[James E. King, III (JIRA)]

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

James E. King, III reassigned THRIFT-4232:
--

Assignee: James E. King, III

> ./configure does bad ant version check
> --
>
> Key: THRIFT-4232
> URL: https://issues.apache.org/jira/browse/THRIFT-4232
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: OSX 10.12.5, running ant 1.10.1
>Reporter: David Woodward
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> On line 18869 of the configure script, it checks that the ant version is >= 
> 1.7. It uses some kind of string comparison. This breaks for my current ant 
> version (1.10). It seems to think that 1.10 is not >= 1.7. I think this is 
> because it's comparing strings without taking into account what the strings 
> actually mean. Something like this might be a possible patch:
> https://stackoverflow.com/questions/16989598/bash-comparing-version-numbers
> This should be fixed because it means that people with new ant versions can't 
> build the java thrift library.
> Also it should be checked to see if other parts of the configure process are 
> using these kinds of faulty version checks.



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

[GitHub] thrift pull request #1354: THRIFT-4232 ./configure does bad ant version chec...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4329:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1361
  
Now that the build issues seem to be out of the way, I've merged the 
previous 3 PRs from you and I'd ask that you squash and rebase this on the 
current master and submit it again.  I'd like to see a clean CI build - this 
one failed in more places than can be explained by the previous errors.


> c_glib Doesn't have a multiplexed processor
> ---
>
> Key: THRIFT-4329
> URL: https://issues.apache.org/jira/browse/THRIFT-4329
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 1.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
> Fix For: 1.0
>
>
> It seems that multiplexed protocol only implements 
> thrift_multiplexed_protocol_write_message_begin that's ok for sending 
> messages to a multiplexed server but not for the C server. We also need a 
> multiplexed processor for the server.



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

[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1361
  
Now that the build issues seem to be out of the way, I've merged the 
previous 3 PRs from you and I'd ask that you squash and rebase this on the 
current master and submit it again.  I'd like to see a clean CI build - this 
one failed in more places than can be explained by the previous errors.


---

[jira] [Updated] (THRIFT-4212) c_glib flush tries to close SSL even if socket is invalid

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4212:
---
Affects Version/s: (was: 1.0)
   0.10.0

> c_glib flush tries to close SSL even if socket is invalid
> -
>
> Key: THRIFT-4212
> URL: https://issues.apache.org/jira/browse/THRIFT-4212
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
> Fix For: 0.11.0
>
>
> It seems that SSL is trying to get info from socket even when socket is 
> already invalid, making the app to crash.



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

[jira] [Commented] (THRIFT-4212) c_glib flush tries to close SSL even if socket is invalid

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4212:


Github user asfgit closed the pull request at:

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


> c_glib flush tries to close SSL even if socket is invalid
> -
>
> Key: THRIFT-4212
> URL: https://issues.apache.org/jira/browse/THRIFT-4212
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
> Fix For: 0.11.0
>
>
> It seems that SSL is trying to get info from socket even when socket is 
> already invalid, making the app to crash.



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

[jira] [Resolved] (THRIFT-4212) c_glib flush tries to close SSL even if socket is invalid

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4212.

Resolution: Fixed

Merged - thanks.

> c_glib flush tries to close SSL even if socket is invalid
> -
>
> Key: THRIFT-4212
> URL: https://issues.apache.org/jira/browse/THRIFT-4212
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
> Fix For: 0.11.0
>
>
> It seems that SSL is trying to get info from socket even when socket is 
> already invalid, making the app to crash.



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

[jira] [Updated] (THRIFT-4212) c_glib flush tries to close SSL even if socket is invalid

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4212:
---
Fix Version/s: (was: 1.0)
   0.11.0

> c_glib flush tries to close SSL even if socket is invalid
> -
>
> Key: THRIFT-4212
> URL: https://issues.apache.org/jira/browse/THRIFT-4212
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
> Fix For: 0.11.0
>
>
> It seems that SSL is trying to get info from socket even when socket is 
> already invalid, making the app to crash.



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

[GitHub] thrift pull request #1279: THRIFT-4212: Fix flush on ssl socket thrift

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[Dmitry Volodin (JIRA)]

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

Dmitry Volodin updated THRIFT-4337:
---
Fix Version/s: (was: 1.0)

> 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
>
> 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
(v6.4.14#64029)

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

[Dmitry Volodin (JIRA)]

Dmitry Volodin created THRIFT-4337:
--

 Summary: 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
 Fix For: 1.0


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
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4211) Fix GError glib management under Thrift

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4211:


Github user asfgit closed the pull request at:

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


> Fix GError glib management under Thrift
> ---
>
> Key: THRIFT-4211
> URL: https://issues.apache.org/jira/browse/THRIFT-4211
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
> Fix For: 0.11.0
>
>
> It seems that current Gerror management done in thrift is not quite ok and 
> causes the library to fail. 
> This issue tracks and fixes all problems found during testing.



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

[GitHub] thrift pull request #1278: THRIFT-4211: Fix logging in thrift library

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Resolved] (THRIFT-4211) Fix GError glib management under Thrift

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4211.

   Resolution: Fixed
Fix Version/s: 0.11.0

Merged.

> Fix GError glib management under Thrift
> ---
>
> Key: THRIFT-4211
> URL: https://issues.apache.org/jira/browse/THRIFT-4211
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
> Fix For: 0.11.0
>
>
> It seems that current Gerror management done in thrift is not quite ok and 
> causes the library to fail. 
> This issue tracks and fixes all problems found during testing.



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

[jira] [Updated] (THRIFT-4211) Fix GError glib management under Thrift

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4211:
---
Fix Version/s: (was: 1.0)

> Fix GError glib management under Thrift
> ---
>
> Key: THRIFT-4211
> URL: https://issues.apache.org/jira/browse/THRIFT-4211
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
>
> It seems that current Gerror management done in thrift is not quite ok and 
> causes the library to fail. 
> This issue tracks and fixes all problems found during testing.



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

[jira] [Commented] (THRIFT-4205) c_glib is not linking against glib + gobject

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4205:


Github user asfgit closed the pull request at:

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


> c_glib is not linking against glib + gobject
> 
>
> Key: THRIFT-4205
> URL: https://issues.apache.org/jira/browse/THRIFT-4205
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
>Priority: Critical
>  Labels: build
> Fix For: 0.11.0
>
>
> The library is not linking against glib and gobject depedencies. It means 
> that it will work if the library is linked against a program that uses that 
> libraries but it will fail in environments like Android. 
> Since the reference to gobject (for example) will not be there and in 
> System.Loadlibrary('libthrift_c_glib') it will fail to load because missing 
> symbols.



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

[jira] [Resolved] (THRIFT-4205) c_glib is not linking against glib + gobject

[James E. King, III (JIRA)]

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

James E. King, III resolved THRIFT-4205.

Resolution: Fixed

Merged.

> c_glib is not linking against glib + gobject
> 
>
> Key: THRIFT-4205
> URL: https://issues.apache.org/jira/browse/THRIFT-4205
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
>Priority: Critical
>  Labels: build
> Fix For: 0.11.0
>
>
> The library is not linking against glib and gobject depedencies. It means 
> that it will work if the library is linked against a program that uses that 
> libraries but it will fail in environments like Android. 
> Since the reference to gobject (for example) will not be there and in 
> System.Loadlibrary('libthrift_c_glib') it will fail to load because missing 
> symbols.



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

[GitHub] thrift pull request #1272: THRIFT-4205: Set flags for glib+gobject on compil...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Updated] (THRIFT-4205) c_glib is not linking against glib + gobject

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4205:
---
Affects Version/s: (was: 1.0)
   0.10.0

> c_glib is not linking against glib + gobject
> 
>
> Key: THRIFT-4205
> URL: https://issues.apache.org/jira/browse/THRIFT-4205
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
>Priority: Critical
>  Labels: build
> Fix For: 0.11.0
>
>
> The library is not linking against glib and gobject depedencies. It means 
> that it will work if the library is linked against a program that uses that 
> libraries but it will fail in environments like Android. 
> Since the reference to gobject (for example) will not be there and in 
> System.Loadlibrary('libthrift_c_glib') it will fail to load because missing 
> symbols.



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

[jira] [Updated] (THRIFT-4205) c_glib is not linking against glib + gobject

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4205:
---
Fix Version/s: (was: 1.0)
   0.11.0

> c_glib is not linking against glib + gobject
> 
>
> Key: THRIFT-4205
> URL: https://issues.apache.org/jira/browse/THRIFT-4205
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.10.0
>Reporter: Gonzalo Aguilar
>Assignee: Gonzalo Aguilar
>Priority: Critical
>  Labels: build
> Fix For: 0.11.0
>
>
> The library is not linking against glib and gobject depedencies. It means 
> that it will work if the library is linked against a program that uses that 
> libraries but it will fail in environments like Android. 
> Since the reference to gobject (for example) will not be there and in 
> System.Loadlibrary('libthrift_c_glib') it will fail to load because missing 
> symbols.



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

[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised

[Can Celasun (JIRA)]

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

Can Celasun commented on THRIFT-4285:
-

Just had a chance to review. The patch doesn't apply cleanly to {{master}} 
because {{mock_handler.go}} is now in {{.gitignore}}. I've manually fixed the 
patch and ran the tests, [all seems 
fine|https://travis-ci.org/dcelasun/thrift/builds/278182132] (failure is 
unrelated).

[~Zariel] If you can update the patch, I think this is ready to merge.

cc [~jensg]

> Pull generated send/recv into library to allow behaviour to be customised
> -
>
> Key: THRIFT-4285
> URL: https://issues.apache.org/jira/browse/THRIFT-4285
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler, Go - Library
>Reporter: Chris Bannister
>Assignee: Chris Bannister
> Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch, 
> 0001-go-pull-generated-send-recv-into-lib-v7.patch
>
>
> Currently it is difficult to change how thrift writes messages onto the 
> transport because they are in the generated code. Instead the generated 
> send/recv methods should be in the library. This will greatly simplify the 
> client code and remove many duplicate methods whilst allowing users more 
> flexibility to implement connection pools and other features such as THeader.



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

[jira] [Assigned] (THRIFT-4104) Add a CI build job that runs without libevent or zlib

[James E. King, III (JIRA)]

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

James E. King, III reassigned THRIFT-4104:
--

Assignee: (was: James E. King, III)

> Add a CI build job that runs without libevent or zlib
> -
>
> Key: THRIFT-4104
> URL: https://issues.apache.org/jira/browse/THRIFT-4104
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process, C++ - Library
>Affects Versions: 0.10.0
>Reporter: James E. King, III
>
> Support for libevent and for zlib are optional.  We should have CI build jobs 
> for unix and windows that omit these libraries and ensure we can still build 
> and run tests.



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

[jira] [Assigned] (THRIFT-4142) Add a functional test to check proper handling of required fields in structures

[James E. King, III (JIRA)]

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

James E. King, III reassigned THRIFT-4142:
--

Assignee: (was: James E. King, III)

> Add a functional test to check proper handling of required fields in 
> structures
> ---
>
> Key: THRIFT-4142
> URL: https://issues.apache.org/jira/browse/THRIFT-4142
> Project: Thrift
>  Issue Type: Improvement
>  Components: Test Suite
>Affects Versions: 0.10.0
> Environment: Docker builds (ubuntu is okay)
>Reporter: James E. King, III
>Priority: Minor
>
> During code review of THRIFT-4126 an additional functional test was discussed 
> that would be useful to ensure all runtimes behave the same way with respect 
> to required fields.  THRIFT-4126 changes the php runtime to throw an protocol 
> exception when a required field is not set in serialization or 
> deserialization.



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

[jira] [Commented] (THRIFT-4331) C++: TSSLSockets bug in handling huge messages, bug in handling polling

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4331:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1363
  
If you could do me a favor and rebase on the current master, I finally got 
all the CI build issues resolved so I'd like to see a clean build before I 
merge.  There are some minor formatting (indentation) issues as well.


> C++: TSSLSockets bug in handling huge messages, bug in handling polling
> ---
>
> Key: THRIFT-4331
> URL: https://issues.apache.org/jira/browse/THRIFT-4331
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.10.0
>Reporter: Martin Haimberger
> Attachments: 0.10.0-THRIFT-4331.patch, master-THRIFT-4331.patch
>
>
> The TSSLSocket class did not handle large messages, because a underlying TCP 
> socket may signal bytes received, while SSL_read() may not have bytes 
> available. After maxretries (5) the function returned -1, which got 
> interpreted as unsigned integer for read bytes.
> Futher the waitForEvent methode, did only set THRIFT_POLLIN or 
> THRIFT_POLLOUT, but it gets used where SSL needs to send AND receive bytes 
> for some operations (like close). So in the case of write wanted, 
> THRIFT_POLLIN is also set to cover these read/write operations.
> Pullrequest for master and 0.10.0 branch will follow.



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

[GitHub] thrift issue #1363: THRIFT-4331 - C++: TSSLSocket fixes

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1363
  
If you could do me a favor and rebase on the current master, I finally got 
all the CI build issues resolved so I'd like to see a clean build before I 
merge.  There are some minor formatting (indentation) issues as well.


---

[jira] [Updated] (THRIFT-4331) C++: TSSLSockets bug in handling huge messages, bug in handling polling

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4331:
---
Fix Version/s: (was: 0.10.0)
   (was: 1.0)

> C++: TSSLSockets bug in handling huge messages, bug in handling polling
> ---
>
> Key: THRIFT-4331
> URL: https://issues.apache.org/jira/browse/THRIFT-4331
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.10.0
>Reporter: Martin Haimberger
> Attachments: 0.10.0-THRIFT-4331.patch, master-THRIFT-4331.patch
>
>
> The TSSLSocket class did not handle large messages, because a underlying TCP 
> socket my signal bytes received, while SSL_read() may not have bytes 
> available. After maxretries (5) the function returned -1, which got 
> interpreted as unsigned integer for read bytes.
> Futher the waitForEvent methode, did only set THRIFT_POLLIN or 
> THRIFT_POLLOUT, but it gets used where SSL needs to send AND receive bytes 
> for some operations (like close). So in the case of write wanted, 
> THRIFT_POLLIN is also set to cover these read/write operations.
> Pullrequest for master and 0.10.0 branch will follow.



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