[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1313 There are conflicting reports to what the root cause of this issue really is. I found: http://bugs.java.com/view_bug.do?bug_id=6693490 fixed in Java 7b55 http://bugs.java.com/view_bug.do?bug_id=6897993 possibly caused by above, fixed in Java 7b77 http://bugs.java.com/view_bug.do?bug_id=6670302 bug in linux 2.4 kernel fixed in 2.6 Given you reproduced it under Java 8b131 then it sounds like it would be a different issue to what's already been reported, or a regression in one of them. Folks seem to think this issue was resolved. I actually found a number of projects that implemented their own solution, but they were all slightly different. Have you looked into reopening 6670302 with a sample program that recreates it under Java 8b131? Or, does the sample app used in that defect reproduce on your system possibly? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4251) Epoll Selector Bug
[ https://issues.apache.org/jira/browse/THRIFT-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124912#comment-16124912 ] ASF GitHub Bot commented on THRIFT-4251: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1313 There are conflicting reports to what the root cause of this issue really is. I found: http://bugs.java.com/view_bug.do?bug_id=6693490 fixed in Java 7b55 http://bugs.java.com/view_bug.do?bug_id=6897993 possibly caused by above, fixed in Java 7b77 http://bugs.java.com/view_bug.do?bug_id=6670302 bug in linux 2.4 kernel fixed in 2.6 Given you reproduced it under Java 8b131 then it sounds like it would be a different issue to what's already been reported, or a regression in one of them. Folks seem to think this issue was resolved. I actually found a number of projects that implemented their own solution, but they were all slightly different. Have you looked into reopening 6670302 with a sample program that recreates it under Java 8b131? Or, does the sample app used in that defect reproduce on your system possibly? > 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)
[jira] [Commented] (THRIFT-4252) Cannot shutdown Java server when clients are still connected
[
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124948#comment-16124948
]
Mario Emmenlauer commented on THRIFT-4252:
--
I have the same problem also with the Java thread pool server, so it seems this
is an expected behavior of the Java servers. However, since this has been fixed
for the C++ servers, I think it would be sensible to also fix the issue for the
Java servers.
With the current behavior, a malicious client can basically prohibit clean
server shutdown (and all it needs to do is keep the connection open). More
realisticly, the client does not need to be malicious, it could just hang or
forget to disconnect and thereby "locking" the server in an open API connection.
> Cannot shutdown Java server when clients are still connected
>
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe
> that the same problem still exists in the Java servers, and I'm affected by
> it. Short summary: I can not shut down the Java server (neither TSimpleServer
> nor TThreadedServer) while clients are still connected. That is pretty bad,
> because essentially the clients are not under by control, but they can
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running.
> The main thread eventually asks the server to stop(). But they seem to ignore
> the request. I checked the code of TSimpleServer.java and I'm under the
> impression that the innermost loop the server does not poll the variable
> stopped_ or does it? Looking at
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
> from line 76:
> {code}
> while (true) {
> if (eventHandler_ != null) {
> eventHandler_.processContext(connectionContext, inputTransport,
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
> break;
> }
> }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I
> guess that one of the methods in the loop must be blocking.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
Chris Bannister created THRIFT-4285: --- Summary: 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 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] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib.patch > 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.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] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124955#comment-16124955 ] Chris Bannister commented on THRIFT-4285: - This is a breaking change for the generated code as the methods NewXXXClientFactory no long exist, instead the NewXXXClient takes a TClient which can be customised with different protocol/transport options. > 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.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)
[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...
Github user Johnny-Liao commented on the issue: https://github.com/apache/thrift/pull/1313 I found a report maybe more relevant with this issue. See : [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933) It gives a solution what is creates a new Selector to replace the old one. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4251) Epoll Selector Bug
[ https://issues.apache.org/jira/browse/THRIFT-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124969#comment-16124969 ] ASF GitHub Bot commented on THRIFT-4251: Github user Johnny-Liao commented on the issue: https://github.com/apache/thrift/pull/1313 I found a report maybe more relevant with this issue. See : [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933) It gives a solution what is creates a new Selector to replace the old one. > 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)
[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124973#comment-16124973 ] Can Celasun commented on THRIFT-4285: - I didn't have a chance to review the patch yet, but I really like the idea. Generated clients contain a lot of cruft that don't need to be there and getting rid of that and adding flexibilty in the process might be worth a BC break (though it might be too late for 0.11). I'll have more feedback after reviewing the patch and making sure all tests are passing. > 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.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] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124980#comment-16124980 ] Chris Bannister commented on THRIFT-4285: - Something I just noticed, no need to define ArgWriter/ResultReader as they should just be TStructs > 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.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] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib-2.patch removed unnecessary interfaces > 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-2.patch, > 0001-go-pull-generated-send-recv-into-lib.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)
[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1313 However, as with all the other issues, they were already resolved, so the fact you are still seeing this with a recent kernel and java version means there's still a bug that needs to be fixed somewhere. There shouldn't be a workaround in every Java program that uses a Selector(). I would still encourage you to come up with a simple example that demonstrates it without Thrift involved and report it upstream. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4251) Epoll Selector Bug
[ https://issues.apache.org/jira/browse/THRIFT-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125040#comment-16125040 ] ASF GitHub Bot commented on THRIFT-4251: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1313 However, as with all the other issues, they were already resolved, so the fact you are still seeing this with a recent kernel and java version means there's still a bug that needs to be fixed somewhere. There shouldn't be a workaround in every Java program that uses a Selector(). I would still encourage you to come up with a simple example that demonstrates it without Thrift involved and report it upstream. > 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...
Github user Johnny-Liao commented on the issue: https://github.com/apache/thrift/pull/1313 It's not elegant way to rebuild Selector in every Java program, but it's a effective way to fix this bug. And so many year passed it not really fixed in JDK or kernel. This is one reason for some Frameworks implemented this solution. After all, the consequences of this bug are too serious. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4251) Epoll Selector Bug
[ https://issues.apache.org/jira/browse/THRIFT-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125165#comment-16125165 ] ASF GitHub Bot commented on THRIFT-4251: Github user Johnny-Liao commented on the issue: https://github.com/apache/thrift/pull/1313 It's not elegant way to rebuild Selector in every Java program, but it's a effective way to fix this bug. And so many year passed it not really fixed in JDK or kernel. This is one reason for some Frameworks implemented this solution. After all, the consequences of this bug are too serious. > 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)
