[GitHub] thrift pull request #1094: Fixes THRIFT-3855

[Jens-G]

Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1094#discussion_r80390983
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

I can't see the connection. Please explain.


---
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 pull request #1094: Fixes THRIFT-3855

[Jens-G]

Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1094#discussion_r80390991
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

How is that related? Please explain. 


---
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-3855) In the go simple server, if Stop() is called multiple times it hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3855:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1094#discussion_r80390983
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

I can't see the connection. Please explain.


> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[jira] [Commented] (THRIFT-3902) TFramedTransport.open throws NullPointerException

[Henrique Andrade (JIRA)]

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

Henrique Andrade commented on THRIFT-3902:
--

@aki: since this is now marked resolved, can you please link the pull request 
so we can verify the fix?

> TFramedTransport.open throws NullPointerException
> -
>
> Key: THRIFT-3902
> URL: https://issues.apache.org/jira/browse/THRIFT-3902
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Commented] (THRIFT-3507) THttpClient does not use proxy from http_proxy, https_proxy environment variables

[Jens Geyer (JIRA)]

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

Jens Geyer commented on THRIFT-3507:


Let's just assume, I want to apply the patches that are intended for the master 
branch, a.k.a developer trunk. 

Which files do I pick, and in what order?

> THttpClient does not use proxy from http_proxy, https_proxy environment 
> variables
> -
>
> Key: THRIFT-3507
> URL: https://issues.apache.org/jira/browse/THRIFT-3507
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.3
> Environment: Windows 7 + Cygwin x64 + Python 2.7.10
>Reporter: Fabricio Oliveira
>Priority: Critical
> Attachments: 
> 0001-python-THttpClient-Add-support-for-system-proxy-sett.patch, 
> THRIFT-3507-1.patch
>
>




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

[jira] [Commented] (THRIFT-3855) In the go simple server, if Stop() is called multiple times it hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3855:


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

https://github.com/apache/thrift/pull/1094#discussion_r80392646
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

@Jens-G  Reverted back that change. Thank you for review!


> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[jira] [Commented] (THRIFT-3933) Port official C# .NET library for Thrift to C# .NET Core libary

[Jens Geyer (JIRA)]

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

Jens Geyer commented on THRIFT-3933:


GitHub user vgotra opened a pull request:

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

Microsoft .Net Core library port and generator for this library 

Here is port of csharp library to .Net core and also generator for it 
(t_netcore_generator.cc)

All information in README.md files in subfolders with source code and 
samples.

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

$ git pull https://github.com/vgotra/thrift master

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

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


commit 0cf8fc3c5793a3553172745579082e9cd36e
Author: Volodymyr Gotra 
Date:   2016-09-15T00:18:48Z

Initial commit of changes

commit e184a9a2f3c3b93e6221f4ee097598e5b5875460
Author: Volodymyr Gotra 
Date:   2016-09-15T00:29:43Z

Added changes to thriftl.ll for netcore lib






> Port official C# .NET library for Thrift to C# .NET Core libary
> ---
>
> Key: THRIFT-3933
> URL: https://issues.apache.org/jira/browse/THRIFT-3933
> Project: Thrift
>  Issue Type: New Feature
>  Components: C# - Library
>Reporter: Volodymyr Gotra
>
> Port current C# .NET library to C# .NET Core library with support for few 
> platforms (Windows, MacOs, Linux)
> Create separate generator for C# .NET Core library 
> Integrate pull request into official Thrift repository



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

[jira] [Updated] (THRIFT-3933) Port official C# .NET library for Thrift to C# .NET Core libary

[Jens Geyer (JIRA)]

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

Jens Geyer updated THRIFT-3933:
---
Flags:   (was: Important)

> Port official C# .NET library for Thrift to C# .NET Core libary
> ---
>
> Key: THRIFT-3933
> URL: https://issues.apache.org/jira/browse/THRIFT-3933
> Project: Thrift
>  Issue Type: New Feature
>  Components: C# - Library
>Reporter: Volodymyr Gotra
>
> Port current C# .NET library to C# .NET Core library with support for few 
> platforms (Windows, MacOs, Linux)
> Create separate generator for C# .NET Core library 
> Integrate pull request into official Thrift repository



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

Re: [apache/thrift] Microsoft .Net Core library port and generator for this library (#1088)

[Jens Geyer]

Hi,

> > >  lib/netcore/src/Samples
> > >
> > If that is the Thrift Test Suite client/server pair, that part should be 
> > move to /test/netcore. All other tests should remain under /lib/netcore. 
> > [...]
> >
> Moved it to tutorial/netcore folder
>

Yes, cool, thanks, but ... we do have something (i.e. an incarnation of the 
Thrift Test suite client/server pair) to put under /test/netcore, do we?

The general idea is such:
- the /test folders house the Thrift Test suite client/server pairs
- the /tutorial folders is what later appears on the web site under 
Tutorials. This is the Calculator example.



> > generated code should generally not be put into the source tree. Part of 
> > the tutorial is to create these files from the IDL file.
> >
> It can be complex part - because this IDL should be created with new 
> Thrift generator (which should include functionality for .NET Core 
> generation)
>

The Thrift compiler must always match the the library code nevertheless. 
This is a given, doing otherwise will lead to problems, because things 
change between versions. Hence the generated code comes with the implicit 
assumption of being linked against the library version that matches the 
Thrift compiler used. Always.

Second, creating the code from the IDL is (or should be) as simple as

$ thrift  -r  -gen netcore   Tutorial.thrift

There is nothing complicated or complex about it, and it should not be more 
complex than that.


Have fun,
JensG 

[GitHub] thrift pull request #1094: Fixes THRIFT-3855

[asm0dey]

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

https://github.com/apache/thrift/pull/1094#discussion_r80391820
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

@Jens-G --^


---
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-3507) THttpClient does not use proxy from http_proxy, https_proxy environment variables

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3507:
--

Reading http_proxy without reading no_proxy would result in another surprises 
and inconveniences,
although better in that it can be worked around in users' code.

The real problem is that users have no way to use proxies in the current Thrift 
API.
As these environment variables are only conventions, start reading them now may 
not be a best solution.

> THttpClient does not use proxy from http_proxy, https_proxy environment 
> variables
> -
>
> Key: THRIFT-3507
> URL: https://issues.apache.org/jira/browse/THRIFT-3507
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.3
> Environment: Windows 7 + Cygwin x64 + Python 2.7.10
>Reporter: Fabricio Oliveira
>Priority: Critical
> Attachments: 
> 0001-python-THttpClient-Add-support-for-system-proxy-sett.patch, 
> THRIFT-3507-1.patch
>
>




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

[GitHub] thrift pull request #1094: Fixes THRIFT-3855

[asm0dey]

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

https://github.com/apache/thrift/pull/1094#discussion_r80391813
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

It's removed by gofmt. I thought that gofmt knows better tan me, so I 
didn't revert that change. should I?


---
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-3855) In the go simple server, if Stop() is called multiple times it hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3855:


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

https://github.com/apache/thrift/pull/1094#discussion_r80391813
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

It's removed by gofmt. I thought that gofmt knows better tan me, so I 
didn't revert that change. should I?


> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[jira] [Commented] (THRIFT-3855) In the go simple server, if Stop() is called multiple times it hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3855:


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

https://github.com/apache/thrift/pull/1094#discussion_r80391820
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

@Jens-G --^


> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[jira] [Commented] (THRIFT-3855) In the go simple server, if Stop() is called multiple times it hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3855:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1094#discussion_r80392522
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

I would doubt that. If that is true that would probably qualify for a bug 
report. I would not expect a formatting tool to arbitrarily delete valid code 
lines.


> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[GitHub] thrift pull request #1094: Fixes THRIFT-3855

[Jens-G]

Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1094#discussion_r80392522
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

I would doubt that. If that is true that would probably qualify for a bug 
report. I would not expect a formatting tool to arbitrarily delete valid code 
lines.


---
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-3902) TFramedTransport.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3902:
--

[~hcma] it's not marked as resolved.
There were 2 identical issues.
I've marked the other one as a duplicate as this one had votes and watchers.


> TFramedTransport.open throws NullPointerException
> -
>
> Key: THRIFT-3902
> URL: https://issues.apache.org/jira/browse/THRIFT-3902
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Commented] (THRIFT-3855) In the go simple server, if Stop() is called multiple times it hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3855:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1094#discussion_r80390991
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

How is that related? Please explain. 


> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[jira] [Comment Edited] (THRIFT-3507) THttpClient does not use proxy from http_proxy, https_proxy environment variables

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa edited comment on THRIFT-3507 at 9/26/16 2:02 AM:
---

edit: never mind.

The patch actually just delegates everything to urllib, so I expect my concern 
to be already addressed.


-Reading http_proxy without reading no_proxy would result in another surprises 
and inconveniences,-




was (Author: nsuke):
Reading http_proxy without reading no_proxy would result in another surprises 
and inconveniences,
although better in that it can be worked around in users' code.

The real problem is that users have no way to use proxies in the current Thrift 
API.
As these environment variables are only conventions, start reading them now may 
not be a best solution.

> THttpClient does not use proxy from http_proxy, https_proxy environment 
> variables
> -
>
> Key: THRIFT-3507
> URL: https://issues.apache.org/jira/browse/THRIFT-3507
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.3
> Environment: Windows 7 + Cygwin x64 + Python 2.7.10
>Reporter: Fabricio Oliveira
>Priority: Critical
> Attachments: 
> 0001-python-THttpClient-Add-support-for-system-proxy-sett.patch, 
> THRIFT-3507-1.patch
>
>




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

[GitHub] thrift pull request #1094: Fixes THRIFT-3855

[asm0dey]

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

https://github.com/apache/thrift/pull/1094#discussion_r80392646
  
--- Diff: lib/go/thrift/simple_server.go ---
@@ -183,9 +186,6 @@ func (p *TSimpleServer) processRequests(client 
TTransport) error {
log.Printf("error processing request: %s", err)
return err
}
-   if err, ok := err.(TApplicationException); ok && err.TypeId() 
== UNKNOWN_METHOD {
-   continue
-   }
--- End diff --

@Jens-G  Reverted back that change. Thank you for review!


---
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-3855) In the go simple server, if Stop() is called multiple times it hangs

[Paul Finkelshteyn (JIRA)]

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

Paul Finkelshteyn commented on THRIFT-3855:
---

To a pity one test is failed due to some technical reason, I wish it was 
possible to run it again, but I can't.
[~jensg] [~jking] Could you please check my pull request?

> In the go simple server, if Stop() is called multiple times it hangs
> 
>
> Key: THRIFT-3855
> URL: https://issues.apache.org/jira/browse/THRIFT-3855
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.10.0
>
>
> From the submitter huaiwan:
> {quote}
> huaiyun commented 18 hours ago
> When Stop() is called twice or more, and no new connection accepted from 
> AcceptLoop(), the Stop() will be blocked because the quit channel is full.
> {quote}



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

[GitHub] thrift pull request #1095: THRIFT-3826 Appveyor builds cannot download winfl...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3826 Appveyor builds cannot download winflexbison properly



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

$ git pull https://github.com/nsuke/thrift THRIFT-3826

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

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


commit be3acfda2ffc39d355b6197d567cd8d6ad93f0c6
Author: Nobuaki Sukegawa 
Date:   2016-09-25T15:09:00Z

THRIFT-3813 Appveyor builds reference an openssl version that is no longer 
there

Update OpenSSL binary version on Windows CI to 1.0.2i.
(Reusing a JIRA issue for 1.0.2h)

commit 7bd918deb89d3fb25aa3d9edc31f39706c8c47e9
Author: Nobuaki Sukegawa 
Date:   2016-09-25T15:22:29Z

THRIFT-3826 Appveyor builds cannot download winflexbison properly

Use appveyor-retry for winflexbison to alleviate the problem.




---
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-3826) Appveyor builds cannot download winflexbison properly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3826:


GitHub user nsuke opened a pull request:

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

THRIFT-3826 Appveyor builds cannot download winflexbison properly



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

$ git pull https://github.com/nsuke/thrift THRIFT-3826

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

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


commit be3acfda2ffc39d355b6197d567cd8d6ad93f0c6
Author: Nobuaki Sukegawa 
Date:   2016-09-25T15:09:00Z

THRIFT-3813 Appveyor builds reference an openssl version that is no longer 
there

Update OpenSSL binary version on Windows CI to 1.0.2i.
(Reusing a JIRA issue for 1.0.2h)

commit 7bd918deb89d3fb25aa3d9edc31f39706c8c47e9
Author: Nobuaki Sukegawa 
Date:   2016-09-25T15:22:29Z

THRIFT-3826 Appveyor builds cannot download winflexbison properly

Use appveyor-retry for winflexbison to alleviate the problem.




> Appveyor builds cannot download winflexbison properly
> -
>
> Key: THRIFT-3826
> URL: https://issues.apache.org/jira/browse/THRIFT-3826
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appveyor
>Reporter: James E. King, III
>Assignee: Aki Sukegawa
>
> {noformat}
> cinst winflexbison
> Installing the following packages:
> winflexbison
> By installing you accept licenses for the packages.
>  
> winflexbison v2.4.3.20140715
>  Downloading winflexbison 32 bit
>from 
> 'http://sourceforge.net/projects/winflexbison/files/old_versions/win_flex_bison-2.4.3.zip'
>  Chocolatey expected a file at 
> 'C:\Users\appveyor\AppData\Local\Temp\1\chocolate
>  y\winflexbison\2.4.3.20140715\winflexbisonInstall.zip' to be of length 
>  '667674' but the length was '69240'.
>  At C:\ProgramData\chocolatey\helpers\functions\Get-ChocolateyWebFile.ps1:162 
>  char:101
>  + if ($headers.ContainsKey("Content-Length") -and ($fi.Length -ne 
>  $headers["Co ...
>  + 
> ~
>  ~~~{noformat}



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

[GitHub] thrift pull request #368: THRIFT-2835 Add possibility to distribute generato...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #1021: Fix THRIFT-3844

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #971: Update php_thrift_protocol7.cpp

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #1048: Ensuring that HTTP failures will clear the http t...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3748) Node.js Deserialization of lists of lists is broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3748:


Github user asfgit closed the pull request at:

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


> Node.js Deserialization of lists of lists is broken
> ---
>
> Key: THRIFT-3748
> URL: https://issues.apache.org/jira/browse/THRIFT-3748
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
>




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

[jira] [Commented] (THRIFT-2835) Add possibility to distribute generators separately from thrift core, and load them dynamically

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-2835:


Github user asfgit closed the pull request at:

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


> Add possibility to distribute generators separately from thrift core, and 
> load them dynamically
> ---
>
> Key: THRIFT-2835
> URL: https://issues.apache.org/jira/browse/THRIFT-2835
> Project: Thrift
>  Issue Type: New Feature
>  Components: Compiler (General)
>Reporter: Anatol Pomozov
>  Labels: fbthrift
>
> It is a follow-up for discussion with Facebook's fbthrift 
> https://github.com/facebook/fbthrift/issues/48
> fbthrift adds its own generator that creates C++ classes based on their 
> libraries. I do not know how upstreamable this generator but I think other 
> companies would want to do the same - create their own custom generators.
> Currently there is no way to distribute generators separately from the thrift 
> core. Thus the company have to fork whole project and add their own 
> generator. It is what Facebook did.
> The idea is that thrift should be able to load language generators 
> dynamically. i.e. a company foo creates its own generator and puts it to 
> system /usr/lib/thrift/generators/cpp_foo.so When thrift compiler starts - it 
> checks /usr/lib/thrift/generators/ and uses dlopen() to load the shared 
> libraries. The shared library contains information about the generator (name, 
> options, ...) thus it allows thrift core to use this custom third-party 
> generator.
> This allows companies to create and distribute generator will less pain and 
> no need to fork the project.



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

[GitHub] thrift pull request #1089: THRIFT-3929 php namespace remove tail "\\"

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3844) thrift_protocol cannot compile in 7.0.7

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3844:


Github user asfgit closed the pull request at:

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


> thrift_protocol cannot compile in 7.0.7
> ---
>
> Key: THRIFT-3844
> URL: https://issues.apache.org/jira/browse/THRIFT-3844
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 1.0
> Environment: PHP 7.0.7, x86-64, OS-X 10.11
>Reporter: Robert Lu
>
> When compile thrift_protocol extension with php7.0.7 in OS X 10.11,
> Report error:
> php_thrift_protocol7.cpp:290:27: error: no member named 'min' in namespace 
> 'std'; did you mean 'fmin'?
> and
> zend_hash.h:168:30: note: candidate function not viable: no known conversion 
> from 'unsigned long *' to 'zend_ulong *' (aka 'unsigned long long *') for 3rd 
> argument
> ZEND_API int   ZEND_FASTCALL zend_hash_get_current_key_ex(const HashTable 
> *ht, zend_string **str_index, zend_ulong *num_index, HashPosition *pos);
> *And I find someone in github solved this problom, but no one notice it, so I 
> create this issue*



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

[jira] [Commented] (THRIFT-3929) PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing Backslash)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3929:


Github user asfgit closed the pull request at:

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


> PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing 
> Backslash)
> 
>
> Key: THRIFT-3929
> URL: https://issues.apache.org/jira/browse/THRIFT-3929
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 1.0
> Environment: Distributor ID: Ubuntu
> Description:Ubuntu 14.04.4 LTS
> Release:14.04
> Codename:   trusty
>Reporter: Ben Meynell
>  Labels: easyfix
> Fix For: 1.0
>
>
> thrift --gen php:server,psr4,oop,validate,json,nsglobal="My\Special\Place" 
> -out ./src my.thrift
> Results in PHP files with namespaces defined as:
> namespace My\Special\Place\;
> Note the trailing backslash ("\"). This results in unparseable PHP:
> $ php -l src/My/Special/Place/Data.php
> Errors parsing src/My/Special/Place/Data.php
> The fix is to simply omit the trailing backslash from the generated code.



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

[GitHub] thrift pull request #1095: THRIFT-3826 Appveyor builds cannot download winfl...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #1022: THRIFT-3845

[nsuke]

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

https://github.com/apache/thrift/pull/1022#discussion_r80386819
  
--- Diff: compiler/cpp/src/generate/t_php_generator.cc ---
@@ -1341,9 +1341,13 @@ void 
t_php_generator::generate_process_function(t_service* tservice, t_function*
 return;
   }
 
-  f_service_ << indent() << "$bin_accel = ($output instanceof "
- << "TBinaryProtocolAccelerated) && 
function_exists('thrift_protocol_write_binary');"
+  // for compatibility, add method_exists
+  f_service_ << indent() << "$bin_accel = method_exists($output, 
'isBinaryAccelerated')" << endl;
+  indent_up();
+  f_service_ << indent() << " && $output->isBinaryAccelerated()" << endl
+ << indent() << " && 
function_exists('thrift_protocol_write_binary');"
--- End diff --

The real problem may be that existing code generation here is too specific 
to one concrete type.
What if we move these thrift_protocol_..._binary calls to 
TBinaryProtocolAccelerated.php ?
That way we can move isStrict... checks there too so that we don't need 
them in TProtocolDecorator either.



---
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-3845) TBinaryProtocolAccelerated cannot use thrift_protocol ext

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3845:


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

https://github.com/apache/thrift/pull/1022#discussion_r80386819
  
--- Diff: compiler/cpp/src/generate/t_php_generator.cc ---
@@ -1341,9 +1341,13 @@ void 
t_php_generator::generate_process_function(t_service* tservice, t_function*
 return;
   }
 
-  f_service_ << indent() << "$bin_accel = ($output instanceof "
- << "TBinaryProtocolAccelerated) && 
function_exists('thrift_protocol_write_binary');"
+  // for compatibility, add method_exists
+  f_service_ << indent() << "$bin_accel = method_exists($output, 
'isBinaryAccelerated')" << endl;
+  indent_up();
+  f_service_ << indent() << " && $output->isBinaryAccelerated()" << endl
+ << indent() << " && 
function_exists('thrift_protocol_write_binary');"
--- End diff --

The real problem may be that existing code generation here is too specific 
to one concrete type.
What if we move these thrift_protocol_..._binary calls to 
TBinaryProtocolAccelerated.php ?
That way we can move isStrict... checks there too so that we don't need 
them in TProtocolDecorator either.



> TBinaryProtocolAccelerated cannot use thrift_protocol ext
> -
>
> Key: THRIFT-3845
> URL: https://issues.apache.org/jira/browse/THRIFT-3845
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler, PHP - Library
>Affects Versions: 0.9.3
> Environment: PHP7 with thrift 0.9.3, with thrift_protocol, at OS X 
> 10.11
>Reporter: Robert Lu
>Priority: Minor
>
> compiler generate phpcode:
>  instanceof TBinaryProtocolAccelerated
> to indicate use thrift_protocol, but when TBinaryProtocolAccelerated warped 
> in TMultiplexedProtocol, thrift_protocol doesn't used, because 
> TMultiplexedProtocol isn't TBinaryProtocolAccelerated's instence.



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

[GitHub] thrift pull request #1022: THRIFT-3845

[nsuke]

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

https://github.com/apache/thrift/pull/1022#discussion_r80386881
  
--- Diff: lib/php/lib/Thrift/Protocol/TBinaryProtocolAccelerated.php ---
@@ -62,4 +62,9 @@ public function isStrictWrite()
   {
 return $this->strictWrite_;
   }
+
+  public function isBinaryAccelerated()
+  {
+return true;
+  }
--- End diff --

I agree we need something like this but the name can be more general.
For example, `isAccelerated` or even `isDynamic`.
(Thinks about the day when we add TCompactProtocolAccelerated or anything 
without generated read/write calls...)


---
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 #1039: THRIFT-2835 Add possibility to distribute generators sep...

[nsuke]

Github user nsuke commented on the issue:

https://github.com/apache/thrift/pull/1039
  
@dtmuller just committed, thanks for all the help and improvements !
It might have not happened at all if you didn't pick it up and revive it ...


---
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-2835) Add possibility to distribute generators separately from thrift core, and load them dynamically

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-2835:


Github user nsuke commented on the issue:

https://github.com/apache/thrift/pull/1039
  
@dtmuller just committed, thanks for all the help and improvements !
It might have not happened at all if you didn't pick it up and revive it ...


> Add possibility to distribute generators separately from thrift core, and 
> load them dynamically
> ---
>
> Key: THRIFT-2835
> URL: https://issues.apache.org/jira/browse/THRIFT-2835
> Project: Thrift
>  Issue Type: New Feature
>  Components: Compiler (General)
>Reporter: Anatol Pomozov
>  Labels: fbthrift
>
> It is a follow-up for discussion with Facebook's fbthrift 
> https://github.com/facebook/fbthrift/issues/48
> fbthrift adds its own generator that creates C++ classes based on their 
> libraries. I do not know how upstreamable this generator but I think other 
> companies would want to do the same - create their own custom generators.
> Currently there is no way to distribute generators separately from the thrift 
> core. Thus the company have to fork whole project and add their own 
> generator. It is what Facebook did.
> The idea is that thrift should be able to load language generators 
> dynamically. i.e. a company foo creates its own generator and puts it to 
> system /usr/lib/thrift/generators/cpp_foo.so When thrift compiler starts - it 
> checks /usr/lib/thrift/generators/ and uses dlopen() to load the shared 
> libraries. The shared library contains information about the generator (name, 
> options, ...) thus it allows thrift core to use this custom third-party 
> generator.
> This allows companies to create and distribute generator will less pain and 
> no need to fork the project.



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

[jira] [Updated] (THRIFT-3929) PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing Backslash)

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3929:
-
Affects Version/s: (was: 1.0)
   0.9.3

> PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing 
> Backslash)
> 
>
> Key: THRIFT-3929
> URL: https://issues.apache.org/jira/browse/THRIFT-3929
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.9.3
> Environment: Distributor ID: Ubuntu
> Description:Ubuntu 14.04.4 LTS
> Release:14.04
> Codename:   trusty
>Reporter: Ben Meynell
>  Labels: easyfix
> Fix For: 1.0
>
>
> thrift --gen php:server,psr4,oop,validate,json,nsglobal="My\Special\Place" 
> -out ./src my.thrift
> Results in PHP files with namespaces defined as:
> namespace My\Special\Place\;
> Note the trailing backslash ("\"). This results in unparseable PHP:
> $ php -l src/My/Special/Place/Data.php
> Errors parsing src/My/Special/Place/Data.php
> The fix is to simply omit the trailing backslash from the generated code.



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

[jira] [Resolved] (THRIFT-3929) PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing Backslash)

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3929.
--
   Resolution: Fixed
 Assignee: Ben Meynell
Fix Version/s: (was: 1.0)
   0.10.0

committed, thanks

> PHP "nsglobal" Option Results in Syntax Error in Generated Code (Trailing 
> Backslash)
> 
>
> Key: THRIFT-3929
> URL: https://issues.apache.org/jira/browse/THRIFT-3929
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.9.3
> Environment: Distributor ID: Ubuntu
> Description:Ubuntu 14.04.4 LTS
> Release:14.04
> Codename:   trusty
>Reporter: Ben Meynell
>Assignee: Ben Meynell
>  Labels: easyfix
> Fix For: 0.10.0
>
>
> thrift --gen php:server,psr4,oop,validate,json,nsglobal="My\Special\Place" 
> -out ./src my.thrift
> Results in PHP files with namespaces defined as:
> namespace My\Special\Place\;
> Note the trailing backslash ("\"). This results in unparseable PHP:
> $ php -l src/My/Special/Place/Data.php
> Errors parsing src/My/Special/Place/Data.php
> The fix is to simply omit the trailing backslash from the generated code.



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

[jira] [Updated] (THRIFT-3844) thrift_protocol cannot compile in 7.0.7

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3844:
-
Affects Version/s: (was: 1.0)
   0.10.0

> thrift_protocol cannot compile in 7.0.7
> ---
>
> Key: THRIFT-3844
> URL: https://issues.apache.org/jira/browse/THRIFT-3844
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0
> Environment: PHP 7.0.7, x86-64, OS-X 10.11
>Reporter: Robert Lu
>
> When compile thrift_protocol extension with php7.0.7 in OS X 10.11,
> Report error:
> php_thrift_protocol7.cpp:290:27: error: no member named 'min' in namespace 
> 'std'; did you mean 'fmin'?
> and
> zend_hash.h:168:30: note: candidate function not viable: no known conversion 
> from 'unsigned long *' to 'zend_ulong *' (aka 'unsigned long long *') for 3rd 
> argument
> ZEND_API int   ZEND_FASTCALL zend_hash_get_current_key_ex(const HashTable 
> *ht, zend_string **str_index, zend_ulong *num_index, HashPosition *pos);
> *And I find someone in github solved this problom, but no one notice it, so I 
> create this issue*



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

[jira] [Resolved] (THRIFT-3844) thrift_protocol cannot compile in 7.0.7

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3844.
--
   Resolution: Fixed
 Assignee: Robert Lu
Fix Version/s: 0.10.0

> thrift_protocol cannot compile in 7.0.7
> ---
>
> Key: THRIFT-3844
> URL: https://issues.apache.org/jira/browse/THRIFT-3844
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0
> Environment: PHP 7.0.7, x86-64, OS-X 10.11
>Reporter: Robert Lu
>Assignee: Robert Lu
> Fix For: 0.10.0
>
>
> When compile thrift_protocol extension with php7.0.7 in OS X 10.11,
> Report error:
> php_thrift_protocol7.cpp:290:27: error: no member named 'min' in namespace 
> 'std'; did you mean 'fmin'?
> and
> zend_hash.h:168:30: note: candidate function not viable: no known conversion 
> from 'unsigned long *' to 'zend_ulong *' (aka 'unsigned long long *') for 3rd 
> argument
> ZEND_API int   ZEND_FASTCALL zend_hash_get_current_key_ex(const HashTable 
> *ht, zend_string **str_index, zend_ulong *num_index, HashPosition *pos);
> *And I find someone in github solved this problom, but no one notice it, so I 
> create this issue*



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

[jira] [Updated] (THRIFT-3845) TBinaryProtocolAccelerated cannot use thrift_protocol ext

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3845:
-
Assignee: Robert Lu

> TBinaryProtocolAccelerated cannot use thrift_protocol ext
> -
>
> Key: THRIFT-3845
> URL: https://issues.apache.org/jira/browse/THRIFT-3845
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler, PHP - Library
>Affects Versions: 0.9.3
> Environment: PHP7 with thrift 0.9.3, with thrift_protocol, at OS X 
> 10.11
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Minor
>
> compiler generate phpcode:
>  instanceof TBinaryProtocolAccelerated
> to indicate use thrift_protocol, but when TBinaryProtocolAccelerated warped 
> in TMultiplexedProtocol, thrift_protocol doesn't used, because 
> TMultiplexedProtocol isn't TBinaryProtocolAccelerated's instence.



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

[jira] [Resolved] (THRIFT-3920) Ruby: Ensuring that HTTP failures will clear the http transport outbuf var

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3920.
--
   Resolution: Fixed
 Assignee: John 
Fix Version/s: 0.10.0

committed, thanks.

> Ruby: Ensuring that HTTP failures will clear the http transport outbuf var
> --
>
> Key: THRIFT-3920
> URL: https://issues.apache.org/jira/browse/THRIFT-3920
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.9.3
>Reporter: John 
>Assignee: John 
>Priority: Minor
> Fix For: 0.10.0
>
>
> PR: https://github.com/apache/thrift/pull/1048
> With the current implementation, any Net HTTP failure will raise from the 
> #flush() method without resetting the @outbuf variable.
> I think that resetting the @outbuf on these failures is more "expected" 
> behaviour. Especially if there is a malformed request that the downstream 
> server does not want to/can't handle. As far as I can tell, there is not way 
> to clear the @outbuf var apart from the #flush() method, so if that fails, 
> then you will just keep appending requests to the out buffer.



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

[jira] [Updated] (THRIFT-3839) Performance issue with big message deserialization using php extension

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa updated THRIFT-3839:
-
Affects Version/s: (was: 1.0)

> Performance issue with big message deserialization using php extension
> --
>
> Key: THRIFT-3839
> URL: https://issues.apache.org/jira/browse/THRIFT-3839
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.9.3
>Reporter: Myroslav Kosinskyi
> Fix For: 1.0
>
>
> I have found performance issue when tried to deserialize big thrift binary 
> message with enabled thrift_protocol php extension.
> Messsage size was 10 mb and it took about 30 seconds to deserialize it.
> When i have done debug of php extension and php library i have found that 
> issue is because small read buffer is used in TBufferedTransport and i cannot 
> change it from TBinarySerializer::deserialize method.
> So i have added parameter $buffer_size to function 
> thrift_protocol_read_binary from php extension.
> And also this parameter i have added to method TBinarySerializer::deserialize 
> from php library.
> And i extended class Thrift\Transport\TMemoryBuffer by method putBack, so 
> this class will be used for desearilization without TBufferedTransport 
> warapper.
> After these changes it takes less than a second to deserizlize message with 
> 10 mb size id read buffer 512 kb.
> Here is the pull request https://github.com/apache/thrift/pull/1014



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

[jira] [Resolved] (THRIFT-3839) Performance issue with big message deserialization using php extension

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3839.
--
   Resolution: Fixed
 Assignee: Myroslav Kosinskyi
Fix Version/s: (was: 1.0)
   0.10.0

committed, thanks.
FWIW, serialization might be also affected.

> Performance issue with big message deserialization using php extension
> --
>
> Key: THRIFT-3839
> URL: https://issues.apache.org/jira/browse/THRIFT-3839
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.9.3
>Reporter: Myroslav Kosinskyi
>Assignee: Myroslav Kosinskyi
> Fix For: 0.10.0
>
>
> I have found performance issue when tried to deserialize big thrift binary 
> message with enabled thrift_protocol php extension.
> Messsage size was 10 mb and it took about 30 seconds to deserialize it.
> When i have done debug of php extension and php library i have found that 
> issue is because small read buffer is used in TBufferedTransport and i cannot 
> change it from TBinarySerializer::deserialize method.
> So i have added parameter $buffer_size to function 
> thrift_protocol_read_binary from php extension.
> And also this parameter i have added to method TBinarySerializer::deserialize 
> from php library.
> And i extended class Thrift\Transport\TMemoryBuffer by method putBack, so 
> this class will be used for desearilization without TBufferedTransport 
> warapper.
> After these changes it takes less than a second to deserizlize message with 
> 10 mb size id read buffer 512 kb.
> Here is the pull request https://github.com/apache/thrift/pull/1014



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

[GitHub] thrift pull request #1078: THRIFT-3919 C# TTLSServerSocket does not use clie...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3919) C# TTLSServerSocket does not use clientTimeout

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3919:


Github user asfgit closed the pull request at:

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


> C# TTLSServerSocket does not use clientTimeout
> --
>
> Key: THRIFT-3919
> URL: https://issues.apache.org/jira/browse/THRIFT-3919
> Project: Thrift
>  Issue Type: Bug
>Reporter: Aki Sukegawa
>Assignee: Aki Sukegawa
>
> The clientTimeout arg is never used in constructors.



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

[jira] [Commented] (THRIFT-3925) Client service recieves string instead of buffer when using TCompactProtocol with node.js library.

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3925:
--

I think it's resolved as part of THRIFT-3409 in master branch.
Unfortunately it's not released yet.

> Client service recieves string instead of buffer when using TCompactProtocol 
> with node.js library.
> --
>
> Key: THRIFT-3925
> URL: https://issues.apache.org/jira/browse/THRIFT-3925
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
>Reporter: Roman Poliakov
>Priority: Critical
> Attachments: 
> Fixed_issue_with_TCompactProtocol_returning_string_instead_of_Buffer_for_service_function_.patch
>
>
> Node.js implementation of TCompactProtocol instead of returning raw Buffer, 
> converts it to string, which leads to data corruption. 
> At the line: 
> https://github.com/apache/thrift/blob/0.9.3/lib/nodejs/lib/thrift/compact_protocol.js#L764
> you can see that it uses "readString" method of the transport instead of 
> using "read".



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

[jira] [Resolved] (THRIFT-3901) TFramedTransport.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa resolved THRIFT-3901.
--
Resolution: Duplicate
  Assignee: Aki Sukegawa

> TFramedTransport.open throws NullPointerException
> -
>
> Key: THRIFT-3901
> URL: https://issues.apache.org/jira/browse/THRIFT-3901
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Assignee: Aki Sukegawa
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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

[jira] [Commented] (THRIFT-3902) TFramedTransport.open throws NullPointerException

[Aki Sukegawa (JIRA)]

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

Aki Sukegawa commented on THRIFT-3902:
--

{code}
if (host_.length() == 0) {
{code}
This means that host_ is null.
Maybe you're passing null sometimes ?

But the code is admittedly strange in that it checks the length field without 
null check.
Also as the next thing it does is to throw exception right away, it could have 
checked the host argument in constructor since it's completely unusable with 
null or empty host.

> TFramedTransport.open throws NullPointerException
> -
>
> Key: THRIFT-3902
> URL: https://issues.apache.org/jira/browse/THRIFT-3902
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
> Environment: CentOS Linux release 7.1.1503 (Core), JVM 1.7.0_67
>Reporter: Zeynep Arikoglu
>Priority: Critical
>
> The following java code sometimes throws NPE:
> final TFramedTransport transport = new TFramedTransport(new TSocket(host, 
> port));
> transport.open();
> Stacktrace is as follows:
> [junit] Exception in thread "Thread-620" java.lang.NullPointerException
> [junit]   at org.apache.thrift.transport.TSocket.open(TSocket.java:209)
> [junit]   at 
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
> There is no other information related to the problem.



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