Re: Apache Thrift Slack

[BCG]

On 10/13/2016 12:59 AM, Jake Farrell wrote:

Wanted to float the idea about using slack as a communication channel for
Apache Thrift and see what others thought. A couple other projects at the
ASF have been using it and so far it has been really a nice complement to
irc when everything gets setup and is working.

After talking with Slack I was able to secure the thrift.slack.com team and
have started setting it up for us to trial. I've enabled sameroom to mirror
all conversations between Slack and irc so nothing will be missed and I
have enabled archiving at http://thrift.slackarchive.io, just waiting for
final confirmation for that integration now.

If this is something that people are interested in keeping and using over
irc then we can open the invitations and signups to everyone. Thoughts,
objections?

-Jake

I'd be willing to give it a shot... to be honest personally I only 
occasionally open up an IRC client so having a slack channel available 
might be a nice alternative

[jira] [Commented] (THRIFT-3942) TSSLSocket does not honor send and receive timeouts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3942:


Github user asfgit closed the pull request at:

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


> TSSLSocket does not honor send and receive timeouts
> ---
>
> Key: THRIFT-3942
> URL: https://issues.apache.org/jira/browse/THRIFT-3942
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Ted Wang
>Assignee: Ted Wang
> Fix For: 0.10.0
>
>
> TSocket respects send and receive timeout, but TSSLSocket does not. This is 
> because it always pass -1 to THRIFT_POLL in waitForEvent:
> https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/transport/TSSLSocket.cpp#L645



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request #1108: THRIFT-3942 Make TSSLSocket honor send and receiv...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (THRIFT-3942) TSSLSocket does not honor send and receive timeouts

[Jens Geyer (JIRA)]

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

Jens Geyer resolved THRIFT-3942.

   Resolution: Fixed
Fix Version/s: 0.10.0

Committed.

> TSSLSocket does not honor send and receive timeouts
> ---
>
> Key: THRIFT-3942
> URL: https://issues.apache.org/jira/browse/THRIFT-3942
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Ted Wang
>Assignee: Ted Wang
> Fix For: 0.10.0
>
>
> TSocket respects send and receive timeout, but TSSLSocket does not. This is 
> because it always pass -1 to THRIFT_POLL in waitForEvent:
> https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/transport/TSSLSocket.cpp#L645



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3943) Coverity Scan identified some high severity defects

[Jens Geyer (JIRA)]

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

Jens Geyer resolved THRIFT-3943.

   Resolution: Fixed
Fix Version/s: 0.10.0

Committed.

> Coverity Scan identified some high severity defects
> ---
>
> Key: THRIFT-3943
> URL: https://issues.apache.org/jira/browse/THRIFT-3943
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Lua - Library
>Affects Versions: 0.9.3
> Environment: https://scan.coverity.com/projects/thrift
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
> Fix For: 0.10.0
>
>
> Coverity Scan identified 9 issues of high severity.
> I dismissed 4 of them as false positives; coverity lost track of the handling 
> of socket file descriptors across multiple layers of calls; this left 5 
> issues, and I took care of a number of insignificant issues as well:
> 1295822 - memory leak in ThreadFactoryTests
> 1216842 - uninitialized rfds fd_set is passed to select if mode is not 
> WAIT_MODE_C (R+W)
> 1216841 - uninitialized wfds fd_set is passed to select if mode is not 
> WAIT_MODE_C (R+W)
> 1216840 - getsockname is always passed uninitialized addrlen
> 1295810 - uninitialized variables in test
> 1295808 - uninitialized variable in test
> 1295804 - structurally dead code in processor test event log - changed to use 
> environment variable
> excuded:
> 1174563 - memory leak in compiler class handling functions
> 1174671 - uninitialized variable in FunctionRunner (intervalMs_)
> 1174669, 1174763, 1295806, 1295807, 1295809 - uninitialized variable in 
> TSocket (peerPort_)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3943) Coverity Scan identified some high severity defects

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3943:


Github user asfgit closed the pull request at:

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


> Coverity Scan identified some high severity defects
> ---
>
> Key: THRIFT-3943
> URL: https://issues.apache.org/jira/browse/THRIFT-3943
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Lua - Library
>Affects Versions: 0.9.3
> Environment: https://scan.coverity.com/projects/thrift
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
> Fix For: 0.10.0
>
>
> Coverity Scan identified 9 issues of high severity.
> I dismissed 4 of them as false positives; coverity lost track of the handling 
> of socket file descriptors across multiple layers of calls; this left 5 
> issues, and I took care of a number of insignificant issues as well:
> 1295822 - memory leak in ThreadFactoryTests
> 1216842 - uninitialized rfds fd_set is passed to select if mode is not 
> WAIT_MODE_C (R+W)
> 1216841 - uninitialized wfds fd_set is passed to select if mode is not 
> WAIT_MODE_C (R+W)
> 1216840 - getsockname is always passed uninitialized addrlen
> 1295810 - uninitialized variables in test
> 1295808 - uninitialized variable in test
> 1295804 - structurally dead code in processor test event log - changed to use 
> environment variable
> excuded:
> 1174563 - memory leak in compiler class handling functions
> 1174671 - uninitialized variable in FunctionRunner (intervalMs_)
> 1174669, 1174763, 1295806, 1295807, 1295809 - uninitialized variable in 
> TSocket (peerPort_)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request #1109: THRIFT-3943: resolve some high severity outstandi...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] thrift issue #1088: Microsoft .Net Core library port and generator for this ...

[Jens-G]

Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/1088
  
@vgotra: Thanks, not forgotten. I'll look into it after the 0.10.0 release 
happened, so please stay tuned. 


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

Re: Apache Thrift Slack

[Randy Abernethy]

Nothing but upside from my perspective.

On Wed, Oct 12, 2016 at 9:59 PM, Jake Farrell  wrote:

> Wanted to float the idea about using slack as a communication channel for
> Apache Thrift and see what others thought. A couple other projects at the
> ASF have been using it and so far it has been really a nice complement to
> irc when everything gets setup and is working.
>
> After talking with Slack I was able to secure the thrift.slack.com team
> and
> have started setting it up for us to trial. I've enabled sameroom to mirror
> all conversations between Slack and irc so nothing will be missed and I
> have enabled archiving at http://thrift.slackarchive.io, just waiting for
> final confirmation for that integration now.
>
> If this is something that people are interested in keeping and using over
> irc then we can open the invitations and signups to everyone. Thoughts,
> objections?
>
> -Jake
>

[jira] [Commented] (THRIFT-3932) C++ ThreadManager has a rare termination race

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3932:


Github user ben-craig commented on the issue:

https://github.com/apache/thrift/pull/1103
  
Removing setDetached and the old thread factory ctors breaks client code 
loudly.  It doesn't fix the underlying problem, and it exchanges one problem 
(don't forget to set the detached mode!) for another (what does the 'false' in 
that parameter list mean?).

I'm great with adding ctors that would make the code less buggy.  I'm also 
okay with the minor breakage of making isDetached and setDetached non-virtual.  
But removing setDetached just breaks too much code without a strong benefit.

If your change ripples out to completely unrelated tests, you need a strong 
motivation for it.  Please separate out the refactors from the fixes.


> C++ ThreadManager has a rare termination race
> -
>
> Key: THRIFT-3932
> URL: https://issues.apache.org/jira/browse/THRIFT-3932
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Reporter: Buğra Gedik
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: thrift-patch
>
>  Time Spent: 17h
>  Remaining Estimate: 0h
>
> {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls 
> {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_ 
> != workerMaxCount_)}}. Within the {{run}} method of the workers, the last 
> thread that detects {{workerCount_ == workerMaxCount_}} notifies 
> {{removeWorker}}. The {{run}} method has the following additional code that 
> is executed at the very end:
> {code}
> {
>   Synchronized s(manager_->workerMonitor_);
>   manager_->deadWorkers_.insert(this->thread());
>   if (notifyManager) {
> manager_->workerMonitor_.notify();
>   }
> }
> {code}
> This is an independent synchronized block. Now assume 2 threads. One of them 
> has {{notifyManager=true}} as it detected the {{workerCount_ == 
> workerMaxCount_}} condition earlier. It is possible that this thread gets to 
> execute  the above code block first, {{ThreadManager}}'s {{removeWorker}} 
> method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the 
> object is destructed. When the other thread reaches the synchronized block 
> above, it will crash, as the manager is not around anymore.
> Besides, {{ThreadManager}} never joins its threads.
> Attached is a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift issue #1103: THRIFT-3932: fixed ThreadManager concurrency issues, add...

[ben-craig]

Github user ben-craig commented on the issue:

https://github.com/apache/thrift/pull/1103
  
Removing setDetached and the old thread factory ctors breaks client code 
loudly.  It doesn't fix the underlying problem, and it exchanges one problem 
(don't forget to set the detached mode!) for another (what does the 'false' in 
that parameter list mean?).

I'm great with adding ctors that would make the code less buggy.  I'm also 
okay with the minor breakage of making isDetached and setDetached non-virtual.  
But removing setDetached just breaks too much code without a strong benefit.

If your change ripples out to completely unrelated tests, you need a strong 
motivation for it.  Please separate out the refactors from the fixes.


---
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-3932) C++ ThreadManager has a rare termination race

[Jake Farrell (JIRA)]

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

Jake Farrell commented on THRIFT-3932:
--

Ran through the patch and with the size and number of files that this is 
touching in the C++ lib I would error on the side of caution and look at 
committing this right after 0.10.0 is released so it does not block the release 
and it can get proper testing and soak time in before 0.11.0 gets cut. 

[~ben.craig] do you have a second to review this patch?

> C++ ThreadManager has a rare termination race
> -
>
> Key: THRIFT-3932
> URL: https://issues.apache.org/jira/browse/THRIFT-3932
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Reporter: Buğra Gedik
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: thrift-patch
>
>  Time Spent: 17h
>  Remaining Estimate: 0h
>
> {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls 
> {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_ 
> != workerMaxCount_)}}. Within the {{run}} method of the workers, the last 
> thread that detects {{workerCount_ == workerMaxCount_}} notifies 
> {{removeWorker}}. The {{run}} method has the following additional code that 
> is executed at the very end:
> {code}
> {
>   Synchronized s(manager_->workerMonitor_);
>   manager_->deadWorkers_.insert(this->thread());
>   if (notifyManager) {
> manager_->workerMonitor_.notify();
>   }
> }
> {code}
> This is an independent synchronized block. Now assume 2 threads. One of them 
> has {{notifyManager=true}} as it detected the {{workerCount_ == 
> workerMaxCount_}} condition earlier. It is possible that this thread gets to 
> execute  the above code block first, {{ThreadManager}}'s {{removeWorker}} 
> method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the 
> object is destructed. When the other thread reaches the synchronized block 
> above, it will crash, as the manager is not around anymore.
> Besides, {{ThreadManager}} never joins its threads.
> Attached is a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3932) C++ ThreadManager has a rare termination race

[Jake Farrell (JIRA)]

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

Jake Farrell updated THRIFT-3932:
-
Fix Version/s: 0.11.0

> C++ ThreadManager has a rare termination race
> -
>
> Key: THRIFT-3932
> URL: https://issues.apache.org/jira/browse/THRIFT-3932
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Reporter: Buğra Gedik
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: thrift-patch
>
>  Time Spent: 17h
>  Remaining Estimate: 0h
>
> {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls 
> {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_ 
> != workerMaxCount_)}}. Within the {{run}} method of the workers, the last 
> thread that detects {{workerCount_ == workerMaxCount_}} notifies 
> {{removeWorker}}. The {{run}} method has the following additional code that 
> is executed at the very end:
> {code}
> {
>   Synchronized s(manager_->workerMonitor_);
>   manager_->deadWorkers_.insert(this->thread());
>   if (notifyManager) {
> manager_->workerMonitor_.notify();
>   }
> }
> {code}
> This is an independent synchronized block. Now assume 2 threads. One of them 
> has {{notifyManager=true}} as it detected the {{workerCount_ == 
> workerMaxCount_}} condition earlier. It is possible that this thread gets to 
> execute  the above code block first, {{ThreadManager}}'s {{removeWorker}} 
> method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the 
> object is destructed. When the other thread reaches the synchronized block 
> above, it will crash, as the manager is not around anymore.
> Besides, {{ThreadManager}} never joins its threads.
> Attached is a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)