date:20171025

[jira] [Commented] (THRIFT-577) Factor BinaryProtocolAccelerated into separate components

2017-10-25 Thread Robert Lu (JIRA)


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

Robert Lu commented on THRIFT-577:
--

The fastbinary.c is already move to lib/py/src/ext/ by THRIFT-3612.

So, I think this issue is resolved.

> Factor BinaryProtocolAccelerated into separate components
> -
>
> Key: THRIFT-577
> URL: https://issues.apache.org/jira/browse/THRIFT-577
> Project: Thrift
>  Issue Type: Improvement
>  Components: Python - Compiler, Python - Library
>Reporter: Esteve Fernandez
>
> Ben Maurer's excellent native Python library has proven to be very fast and 
> efficient, however introducing new features and bug fixes have become a 
> non-trivial task. This is because it implements the serialization process as 
> a whole. The previous version of the Ruby library followed this approach, as 
> it was actually based on Ben's library.
> Bryan split the Ruby native library in THRIFT-248, this has reduced the time 
> for incorporating new features and bug fixes, and also has enabled other 
> protocols to take advantage of the benefits of accelerated code (e.g. any 
> protocol that inherits from TProtocol)
> The aim of this task is to split TBinaryProtocolAccelerated into separate 
> pieces (e.g. TProtocolAccelerated, TBinaryProtocolAccelerated, etc.) and 
> remove fastbinary.encode/decode from the Python generator.



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

[jira] [Commented] (THRIFT-515) Having the same namespace in separate thrift files generates non-working code

2017-10-25 Thread Robert Lu (JIRA)


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

Robert Lu commented on THRIFT-515:
--

As discussed above,

This is not a bug.

Please close this.

> Having the same namespace in separate thrift files generates non-working code
> -
>
> Key: THRIFT-515
> URL: https://issues.apache.org/jira/browse/THRIFT-515
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Reporter: Jonathan Kupferman
>Priority: Minor
>
> If there are two thrift files which use the same namespace the generated 
> python code does not work. A sample case is the two thrift files provided 
> below:
> test.thrift--
> namespace py Sample
> struct Name {
> 1: string n
> }
> struct User {
> 1: i32 id,
> 2: Name user_name
> }
>  end test.thrift--
> test_service.thrift---
> include "test.thrift"
> namespace py Sample
> service TestService {
>   test.User get_user(1: i64 id),
>   test.Name get_user_name(1: i64 id),
> }
> end test_service.thrift---
> This happens because the ttypes for test.thrift are clobbered by the ttypes 
> for TestService. As a result TestService is not imported correctly.
> >>> import Sample
> >>> import Sample.ttypes
> >>> from Sample import *
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "Sample/TestService.py", line 205, in 
> class get_user_result:
>   File "Sample/TestService.py", line 212, in get_user_result
> (0, TType.STRUCT, 'success', (Sample.ttypes.User, 
> Sample.ttypes.User.thrift_spec), None, ), # 0
> AttributeError: 'module' object has no attribute 'User'



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

[GitHub] thrift pull request #1399: THRIFT-4370: build generated code before running ...

2017-10-25 Thread RobberPhex

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

https://github.com/apache/thrift/pull/1399#discussion_r147048687
  
--- Diff: lib/py/setup.py ---
@@ -22,7 +22,7 @@
 import sys
 try:
 from setuptools import setup, Extension
-except:
+except Exception:
--- End diff --

I think we should use distutils.core, and setuptools is feedback,
And we should only process ImportError.
```py
try:
 from distutils.core import setup, Extension
except ImportError:
from setuptools import setup, Extension
```


---

[jira] [Commented] (THRIFT-4370) Ubuntu Artful cppcheck and flake8 are more stringent and causing SCA build job failures

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4370:


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

https://github.com/apache/thrift/pull/1399#discussion_r147048687
  
--- Diff: lib/py/setup.py ---
@@ -22,7 +22,7 @@
 import sys
 try:
 from setuptools import setup, Extension
-except:
+except Exception:
--- End diff --

I think we should use distutils.core, and setuptools is feedback,
And we should only process ImportError.
```py
try:
 from distutils.core import setup, Extension
except ImportError:
from setuptools import setup, Extension
```


> Ubuntu Artful cppcheck and flake8 are more stringent and causing SCA build 
> job failures
> ---
>
> Key: THRIFT-4370
> URL: https://issues.apache.org/jira/browse/THRIFT-4370
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.11.0
> Environment: docker ubuntu-artful
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Blocker
>




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

[jira] [Commented] (THRIFT-2998) Node.js: Missing header from http request

2017-10-25 Thread James E. King, III (JIRA)


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

James E. King, III commented on THRIFT-2998:


I'm going to submit a 2nd pull request with this fix plus the cross test 
enablement and some licensing header fixups for nodejs.

> Node.js: Missing header from http request
> -
>
> Key: THRIFT-2998
> URL: https://issues.apache.org/jira/browse/THRIFT-2998
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Traian Stanev
>Assignee: James E. King, III
>Priority: Minor
>
> The "Content-Type" header is not being set to "application/x-thrift" when 
> making http requests in the node.js implementation. This results in error 
> response (status 400) for any such connections (depending on whether the 
> server checks the header). The Python implementation for example adds the 
> header explicitly:
> https://github.com/tstanev/thrift/blob/master/lib/py/src/transport/THttpClient.py#L127



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

[jira] [Assigned] (THRIFT-2998) Node.js: Missing header from http request

2017-10-25 Thread James E. King, III (JIRA)


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

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

Assignee: James E. King, III

> Node.js: Missing header from http request
> -
>
> Key: THRIFT-2998
> URL: https://issues.apache.org/jira/browse/THRIFT-2998
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Traian Stanev
>Assignee: James E. King, III
>
> The "Content-Type" header is not being set to "application/x-thrift" when 
> making http requests in the node.js implementation. This results in error 
> response (status 400) for any such connections (depending on whether the 
> server checks the header). The Python implementation for example adds the 
> header explicitly:
> https://github.com/tstanev/thrift/blob/master/lib/py/src/transport/THttpClient.py#L127



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

[jira] [Updated] (THRIFT-2998) Node.js: Missing header from http request

2017-10-25 Thread James E. King, III (JIRA)


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

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

> Node.js: Missing header from http request
> -
>
> Key: THRIFT-2998
> URL: https://issues.apache.org/jira/browse/THRIFT-2998
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Traian Stanev
>Assignee: James E. King, III
>Priority: Minor
>
> The "Content-Type" header is not being set to "application/x-thrift" when 
> making http requests in the node.js implementation. This results in error 
> response (status 400) for any such connections (depending on whether the 
> server checks the header). The Python implementation for example adds the 
> header explicitly:
> https://github.com/tstanev/thrift/blob/master/lib/py/src/transport/THttpClient.py#L127



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

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

2017-10-25 Thread djzort

Github user djzort commented on the issue:

https://github.com/apache/thrift/pull/1261
  
I finally made a jira account, but i need a month to recover from the 
horrors


---

[jira] [Updated] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)


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

Jens Geyer updated THRIFT-4372:
---
Description: 
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

Symptom is that
 * the writing end  acts as if it had written all the bytes (in fact, it did)
 * but the remainder of ~ 65535 bytes is just lost somewhere and never reaches 
the reading end

Consequently, the process at the reading end of the pipe gets stuck while 
waiting for the remaining bytes.

  was:
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

Symptom is that
 * the writing end  acts as if he had written all the bytes (in fact, it did)
 * but the remainder of ~ 65535 bytes is just lost somewhere and never reaches 
the reading end

Consequently, the process at the reading end of the pipe gets stuck while 
waiting for the remaining bytes.


> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library, Delphi - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Critical
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.
> Symptom is that
>  * the writing end  acts as if it had written all the bytes (in fact, it did)
>  * but the remainder of ~ 65535 bytes is just lost somewhere and never 
> reaches the reading end
> Consequently, the process at the reading end of the pipe gets stuck while 
> waiting for the remaining bytes.



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

[jira] [Updated] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)


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

Jens Geyer updated THRIFT-4372:
---
Description: 
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

Symptom is that
 * the writing end  acts as if he had written all the bytes (in fact, it did)
 * but the remainder of ~ 65535 bytes is just lost somewhere and never reaches 
the reading end

Consequently, the client get stuck while waiting for the remaining bytes.

  was:
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

Symptom is that
 * the server acts as if he had written all the bytes (in fact, he did)
 * but the remainder of ~ 65535 bytes is just lost somewhere and never reaches 
the client

Consequently, the client get stuck while waiting for the remaining bytes.


> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library, Delphi - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Critical
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.
> Symptom is that
>  * the writing end  acts as if he had written all the bytes (in fact, it did)
>  * but the remainder of ~ 65535 bytes is just lost somewhere and never 
> reaches the reading end
> Consequently, the client get stuck while waiting for the remaining bytes.



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

[jira] [Updated] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)


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

Jens Geyer updated THRIFT-4372:
---
Description: 
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

Symptom is that
 * the writing end  acts as if he had written all the bytes (in fact, it did)
 * but the remainder of ~ 65535 bytes is just lost somewhere and never reaches 
the reading end

Consequently, the process at the reading end of the pipe gets stuck while 
waiting for the remaining bytes.

  was:
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

Symptom is that
 * the writing end  acts as if he had written all the bytes (in fact, it did)
 * but the remainder of ~ 65535 bytes is just lost somewhere and never reaches 
the reading end

Consequently, the client get stuck while waiting for the remaining bytes.


> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library, Delphi - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Critical
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.
> Symptom is that
>  * the writing end  acts as if he had written all the bytes (in fact, it did)
>  * but the remainder of ~ 65535 bytes is just lost somewhere and never 
> reaches the reading end
> Consequently, the process at the reading end of the pipe gets stuck while 
> waiting for the remaining bytes.



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

[jira] [Updated] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)


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

Jens Geyer updated THRIFT-4372:
---
Component/s: Delphi - Library

> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library, Delphi - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Critical
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.
> Symptom is that
>  * the server acts as if he had written all the bytes (in fact, he did)
>  * but the remainder of ~ 65535 bytes is just lost somewhere and never 
> reaches the client
> Consequently, the client get stuck while waiting for the remaining bytes.



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

[jira] [Commented] (THRIFT-2998) Node.js: Missing header from http request

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-2998:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/378
  
To properly test this fix I need to add http transport support to the 
nodejs cross programs, so I'll do that as part of the effort.


> Node.js: Missing header from http request
> -
>
> Key: THRIFT-2998
> URL: https://issues.apache.org/jira/browse/THRIFT-2998
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Traian Stanev
>
> The "Content-Type" header is not being set to "application/x-thrift" when 
> making http requests in the node.js implementation. This results in error 
> response (status 400) for any such connections (depending on whether the 
> server checks the header). The Python implementation for example adds the 
> header explicitly:
> https://github.com/tstanev/thrift/blob/master/lib/py/src/transport/THttpClient.py#L127



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

[GitHub] thrift issue #378: THRIFT-2998: Set Content-Type for HTTP request in Node.js...

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/378
  
To properly test this fix I need to add http transport support to the 
nodejs cross programs, so I'll do that as part of the effort.


---

[jira] [Commented] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4372:


GitHub user Jens-G opened a pull request:

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

THRIFT-4372 Pipe write operations across a network are limited to 65,…

…535 bytes per write

Client: C#
Patch: Jens Geyer

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

$ git pull https://github.com/Jens-G/thrift THRIFT-4372

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

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


commit ccfc002a480c9ed23b50674c3fd76a280750bbb0
Author: Jens Geyer 
Date:   2017-10-25T20:30:23Z

THRIFT-4372 Pipe write operations across a network are limited to 65,535 
bytes per write
Client: C#
Patch: Jens Geyer




> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Critical
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.
> Symptom is that
>  * the server acts as if he had written all the bytes (in fact, he did)
>  * but the remainder of ~ 65535 bytes is just lost somewhere and never 
> reaches the client
> Consequently, the client get stuck while waiting for the remaining bytes.



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

[GitHub] thrift pull request #1402: THRIFT-4372 Pipe write operations across a networ...

2017-10-25 Thread Jens-G

GitHub user Jens-G opened a pull request:

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

THRIFT-4372 Pipe write operations across a network are limited to 65,â¦

â¦535 bytes per write

Client: C#
Patch: Jens Geyer

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

$ git pull https://github.com/Jens-G/thrift THRIFT-4372

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

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


commit ccfc002a480c9ed23b50674c3fd76a280750bbb0
Author: Jens Geyer 
Date:   2017-10-25T20:30:23Z

THRIFT-4372 Pipe write operations across a network are limited to 65,535 
bytes per write
Client: C#
Patch: Jens Geyer




---

[jira] [Updated] (THRIFT-4373) Extending Thrift class results in "Attempt serialize from non-Thrift object"

2017-10-25 Thread Josip Sokcevic (JIRA)


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

Josip Sokcevic updated THRIFT-4373:
---
Attachment: 0001-THRIFT-4373-Derefer-PHP-zval-_TSPEC.patch

> Extending Thrift class results in "Attempt serialize from non-Thrift object"
> 
>
> Key: THRIFT-4373
> URL: https://issues.apache.org/jira/browse/THRIFT-4373
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0
> Environment: Linux 4.13.3-1-ARCH
> PHP 7.1.10
>Reporter: Josip Sokcevic
> Attachments: 0001-THRIFT-4373-Derefer-PHP-zval-_TSPEC.patch
>
>
> This happens when using php extension. thrift_protocol_write_binary will 
> check Z_TYPE_P of spec and expects to be array (IS_ARRAY). However, PHP7 will 
> set it as reference (IS_REFERENCE).
> Example:
> {code}
> $s = new Serializer\TBinarySerializer();
> // Foo is a Thrift type class
> class FooExtended extends Foo {}
> $o = new Foo();
> $o2 = new FooExtended();
> // this works just fine:
> $s->serialize($o); // this uses thrift_protocol_write_binary if available
> // Next line throws \Thrift\Exception\TProtocolException if 
> thrift_protocol_write_binary is used
> // However, it doesn't break if no extension is available.
> $s->serialize($o);
> {code}
> Proposed solution is to dereference using ZVAL_DEREF before checking types 
> (attached). Alternative would be to mark struct type classes as final, but 
> that break compatibility.



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

[jira] [Commented] (THRIFT-4373) Extending Thrift class results in "Attempt serialize from non-Thrift object"

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4373:


GitHub user sokac opened a pull request:

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

THRIFT-4373: Derefer PHP zval _TSPEC



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

$ git pull https://github.com/sokac/thrift php

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

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


commit d6d493d0f0dcae2f892fe0f5ed99884689069e13
Author: Josip Sokcevic 
Date:   2017-10-25T16:45:16Z

THRIFT-4373: Derefer PHP zval _TSPEC




> Extending Thrift class results in "Attempt serialize from non-Thrift object"
> 
>
> Key: THRIFT-4373
> URL: https://issues.apache.org/jira/browse/THRIFT-4373
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0
> Environment: Linux 4.13.3-1-ARCH
> PHP 7.1.10
>Reporter: Josip Sokcevic
> Attachments: 0001-THRIFT-4373-Derefer-PHP-zval-_TSPEC.patch
>
>
> This happens when using php extension. thrift_protocol_write_binary will 
> check Z_TYPE_P of spec and expects to be array (IS_ARRAY). However, PHP7 will 
> set it as reference (IS_REFERENCE).
> Example:
> {code}
> $s = new Serializer\TBinarySerializer();
> // Foo is a Thrift type class
> class FooExtended extends Foo {}
> $o = new Foo();
> $o2 = new FooExtended();
> // this works just fine:
> $s->serialize($o); // this uses thrift_protocol_write_binary if available
> // Next line throws \Thrift\Exception\TProtocolException if 
> thrift_protocol_write_binary is used
> // However, it doesn't break if no extension is available.
> $s->serialize($o);
> {code}
> Proposed solution is to dereference using ZVAL_DEREF before checking types 
> (attached). Alternative would be to mark struct type classes as final, but 
> that break compatibility.



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

[GitHub] thrift pull request #1401: THRIFT-4373: Derefer PHP zval _TSPEC

2017-10-25 Thread sokac

GitHub user sokac opened a pull request:

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

THRIFT-4373: Derefer PHP zval _TSPEC



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

$ git pull https://github.com/sokac/thrift php

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

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


commit d6d493d0f0dcae2f892fe0f5ed99884689069e13
Author: Josip Sokcevic 
Date:   2017-10-25T16:45:16Z

THRIFT-4373: Derefer PHP zval _TSPEC




---

[jira] [Created] (THRIFT-4373) Extending Thrift class results in "Attempt serialize from non-Thrift object"

2017-10-25 Thread Josip Sokcevic (JIRA)

Josip Sokcevic created THRIFT-4373:
--

 Summary: Extending Thrift class results in "Attempt serialize from 
non-Thrift object"
 Key: THRIFT-4373
 URL: https://issues.apache.org/jira/browse/THRIFT-4373
 Project: Thrift
  Issue Type: Bug
  Components: PHP - Library
Affects Versions: 0.10.0
 Environment: Linux 4.13.3-1-ARCH
PHP 7.1.10
Reporter: Josip Sokcevic


This happens when using php extension. thrift_protocol_write_binary will check 
Z_TYPE_P of spec and expects to be array (IS_ARRAY). However, PHP7 will set it 
as reference (IS_REFERENCE).

Example:

{code}
$s = new Serializer\TBinarySerializer();

// Foo is a Thrift type class
class FooExtended extends Foo {}

$o = new Foo();
$o2 = new FooExtended();

// this works just fine:
$s->serialize($o); // this uses thrift_protocol_write_binary if available

// Next line throws \Thrift\Exception\TProtocolException if 
thrift_protocol_write_binary is used
// However, it doesn't break if no extension is available.
$s->serialize($o);
{code}

Proposed solution is to dereference using ZVAL_DEREF before checking types 
(attached). Alternative would be to mark struct type classes as final, but that 
break compatibility.



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

[jira] [Commented] (THRIFT-4356) thrift_protocol call Transport cause Segmentation fault

2017-10-25 Thread Daniel Smith (JIRA)


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

Daniel Smith commented on THRIFT-4356:
--

Thanks much!  Confirmed this fixes what I was seeing.  Curious that the issue 
was not present in 7.2.0RC4

> thrift_protocol call Transport cause Segmentation fault
> ---
>
> Key: THRIFT-4356
> URL: https://issues.apache.org/jira/browse/THRIFT-4356
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: PHP 7.0.23 (cli) (built: Sep 25 2017 08:07:30) ( NTS )
> macOS 10.13.1 Beta (17B25c)
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Critical
> Fix For: 0.11.0
>
>
> When thrift_protocol extension try to read or write some bytes, if there is 
> some exception, will cause Segmentation fault



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

[jira] [Commented] (THRIFT-4356) thrift_protocol call Transport cause Segmentation fault

2017-10-25 Thread Robert Lu (JIRA)


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

Robert Lu commented on THRIFT-4356:
---

[~danielsmithsd]

Thanks for your feedback,

I submit a PR: https://github.com/apache/thrift/pull/1400

 

[~jking3]

Sorry for leave a bug, should I open a new issue? Or, just review 
https://github.com/apache/thrift/pull/1400?

> thrift_protocol call Transport cause Segmentation fault
> ---
>
> Key: THRIFT-4356
> URL: https://issues.apache.org/jira/browse/THRIFT-4356
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: PHP 7.0.23 (cli) (built: Sep 25 2017 08:07:30) ( NTS )
> macOS 10.13.1 Beta (17B25c)
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Critical
> Fix For: 0.11.0
>
>
> When thrift_protocol extension try to read or write some bytes, if there is 
> some exception, will cause Segmentation fault



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

[jira] [Comment Edited] (THRIFT-4356) thrift_protocol call Transport cause Segmentation fault

2017-10-25 Thread Daniel Smith (JIRA)


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

Daniel Smith edited comment on THRIFT-4356 at 10/25/17 6:54 PM:


[~Robert Lu] What version of PHP was this tested on? It looks like this 
introduced a different bug for me:

PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/local/lib/php/extensions/no-debug-non-zts-20160303/thrift_protocol.so' - 
/usr/local/lib/php/extensions/no-debug-non-zts-20160303/thrift_protocol.so: 
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE in Unknown on line 0

PHP 7.1.10 (cli) (built: Oct 10 2017 01:25:12) ( NTS )

I'm running this in Docker with a base image of php:7.1-apache.  I'll try 
running it just on that image without my changes and see if there's a 
difference.

ETA: PHP 7.2.0RC4 seems to work


was (Author: danielsmithsd):
[~Robert Lu] What version of PHP was this tested on? It looks like this 
introduced a different bug for me:

PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/local/lib/php/extensions/no-debug-non-zts-20160303/thrift_protocol.so' - 
/usr/local/lib/php/extensions/no-debug-non-zts-20160303/thrift_protocol.so: 
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE in Unknown on line 0

PHP 7.1.10 (cli) (built: Oct 10 2017 01:25:12) ( NTS )

I'm running this in Docker with a base image of php:7.1-apache.  I'll try 
running it just on that image without my changes and see if there's a 
difference.

> thrift_protocol call Transport cause Segmentation fault
> ---
>
> Key: THRIFT-4356
> URL: https://issues.apache.org/jira/browse/THRIFT-4356
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: PHP 7.0.23 (cli) (built: Sep 25 2017 08:07:30) ( NTS )
> macOS 10.13.1 Beta (17B25c)
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Critical
> Fix For: 0.11.0
>
>
> When thrift_protocol extension try to read or write some bytes, if there is 
> some exception, will cause Segmentation fault



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

[GitHub] thrift pull request #1400: add stdc++ back

2017-10-25 Thread RobberPhex

GitHub user RobberPhex opened a pull request:

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

add stdc++ back

at Linux x86,

will cause errror:

# php -d extension=./thrift_protocol.so -m
PHP Warning:  PHP Startup: Unable to load dynamic library 
'./thrift_protocol.so' - ./thrift_protocol.so: undefined symbol: 
_ZTVN10__cxxabiv120__si_class_type_infoE in Unknown on line 0


ref 
[commit](https://issues.apache.org/jira/browse/THRIFT-4356?focusedCommentId=16219118=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16219118)

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

$ git pull https://github.com/RobberPhex/thrift fix-libcpp-dep

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

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


commit 194b730d565c822dd516f705e51f49d5632e1052
Author: Robert Lu 
Date:   2017-10-25T18:39:17Z

add stdc++ back




---

[jira] [Commented] (THRIFT-4356) thrift_protocol call Transport cause Segmentation fault

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4356:


GitHub user RobberPhex opened a pull request:

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

add stdc++ back

at Linux x86,

will cause errror:

# php -d extension=./thrift_protocol.so -m
PHP Warning:  PHP Startup: Unable to load dynamic library 
'./thrift_protocol.so' - ./thrift_protocol.so: undefined symbol: 
_ZTVN10__cxxabiv120__si_class_type_infoE in Unknown on line 0


ref 
[commit](https://issues.apache.org/jira/browse/THRIFT-4356?focusedCommentId=16219118=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16219118)

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

$ git pull https://github.com/RobberPhex/thrift fix-libcpp-dep

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

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


commit 194b730d565c822dd516f705e51f49d5632e1052
Author: Robert Lu 
Date:   2017-10-25T18:39:17Z

add stdc++ back




> thrift_protocol call Transport cause Segmentation fault
> ---
>
> Key: THRIFT-4356
> URL: https://issues.apache.org/jira/browse/THRIFT-4356
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: PHP 7.0.23 (cli) (built: Sep 25 2017 08:07:30) ( NTS )
> macOS 10.13.1 Beta (17B25c)
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Critical
> Fix For: 0.11.0
>
>
> When thrift_protocol extension try to read or write some bytes, if there is 
> some exception, will cause Segmentation fault



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

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4207:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
I pulled these changes into a sandbox and started the `ubuntu-xenial` 
docker image, and then ran `build/docker/scripts/autotools.sh` which is what 
Travis CI would do for one of the unit test jobs.  It failed:
```
make[4]: Entering directory '/thrift/src/test/py'

 Executing individual test scripts with various generated code directories
 Directories to be tested: gen-py-default, gen-py-slots, gen-py-oldstyle, 
gen-py-no_utf8strings, gen-py-dynamic, gen-py-dynamicslots
 Scripts to be tested: FastbinaryTest.py, TestFrozen.py, 
TSimpleJSONProtocolTest.py, SerializationTest.py, TestEof.py, TestSyntax.py, 
TestSocket.py


Testing script: /usr/bin/python /thrift/src/test/py/FastbinaryTest.py

Testing TBinaryAccelerated
Traceback (most recent call last):
  File "/thrift/src/test/py/FastbinaryTest.py", line 278, in 
do_test(TBinaryProtocolAccelerated, TBinaryProtocol)
  File "/thrift/src/test/py/FastbinaryTest.py", line 244, in do_test
Test(fast, slow).do_test()
  File "/thrift/src/test/py/FastbinaryTest.py", line 198, in do_test
self._check_write(hm)
  File "/thrift/src/test/py/FastbinaryTest.py", line 137, in _check_write
o.write(prot_slow)
  File "/thrift/src/test/py/gen-py-default/DebugProtoTest/ttypes.py", line 
637, in write
iter52.write(oprot)
  File "/thrift/src/test/py/gen-py-default/DebugProtoTest/ttypes.py", line 
371, in write
oprot.writeString(self.zomg_unicode.encode('utf-8') if 
sys.version_info[0] == 2 else self.zomg_unicode)
  File 
"/thrift/src/lib/py/build/lib.linux-x86_64-2.7/thrift/protocol/TProtocol.py", 
line 123, in writeString
self.writeBinary(str_to_binary(str_val))
  File 
"/thrift/src/lib/py/build/lib.linux-x86_64-2.7/thrift/protocol/TBinaryProtocol.py",
 line 131, in writeBinary
self.trans.write(str)
  File 
"/thrift/src/lib/py/build/lib.linux-x86_64-2.7/thrift/transport/TTransport.py", 
line 233, in write
self._buffer.write(buf)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xd7' in 
position 0: ordinal not in range(128)
*** FAILED ***
LIBDIR: /thrift/src/lib/py/build/lib.linux-x86_64-2.7
PY_GEN: gen-py-default
SCRIPT: FastbinaryTest.py
Traceback (most recent call last):
  File "./RunClientServer.py", line 321, in 
sys.exit(main())
  File "./RunClientServer.py", line 300, in main
runScriptTest(options.libdir, options.gen_base, genpydir, script)
  File "./RunClientServer.py", line 101, in runScriptTest
raise Exception("Script subprocess failed, retcode=%d, args: %s" % 
(ret, ' '.join(script_args)))
Exception: Script subprocess failed, retcode=1, args: /usr/bin/python 
/thrift/src/test/py/FastbinaryTest.py
FAIL: RunClientServer.py
==
1 of 1 test failed
==
```


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



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

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
I pulled these changes into a sandbox and started the `ubuntu-xenial` 
docker image, and then ran `build/docker/scripts/autotools.sh` which is what 
Travis CI would do for one of the unit test jobs.  It failed:
```
make[4]: Entering directory '/thrift/src/test/py'

 Executing individual test scripts with various generated code directories
 Directories to be tested: gen-py-default, gen-py-slots, gen-py-oldstyle, 
gen-py-no_utf8strings, gen-py-dynamic, gen-py-dynamicslots
 Scripts to be tested: FastbinaryTest.py, TestFrozen.py, 
TSimpleJSONProtocolTest.py, SerializationTest.py, TestEof.py, TestSyntax.py, 
TestSocket.py


Testing script: /usr/bin/python /thrift/src/test/py/FastbinaryTest.py

Testing TBinaryAccelerated
Traceback (most recent call last):
  File "/thrift/src/test/py/FastbinaryTest.py", line 278, in 
do_test(TBinaryProtocolAccelerated, TBinaryProtocol)
  File "/thrift/src/test/py/FastbinaryTest.py", line 244, in do_test
Test(fast, slow).do_test()
  File "/thrift/src/test/py/FastbinaryTest.py", line 198, in do_test
self._check_write(hm)
  File "/thrift/src/test/py/FastbinaryTest.py", line 137, in _check_write
o.write(prot_slow)
  File "/thrift/src/test/py/gen-py-default/DebugProtoTest/ttypes.py", line 
637, in write
iter52.write(oprot)
  File "/thrift/src/test/py/gen-py-default/DebugProtoTest/ttypes.py", line 
371, in write
oprot.writeString(self.zomg_unicode.encode('utf-8') if 
sys.version_info[0] == 2 else self.zomg_unicode)
  File 
"/thrift/src/lib/py/build/lib.linux-x86_64-2.7/thrift/protocol/TProtocol.py", 
line 123, in writeString
self.writeBinary(str_to_binary(str_val))
  File 
"/thrift/src/lib/py/build/lib.linux-x86_64-2.7/thrift/protocol/TBinaryProtocol.py",
 line 131, in writeBinary
self.trans.write(str)
  File 
"/thrift/src/lib/py/build/lib.linux-x86_64-2.7/thrift/transport/TTransport.py", 
line 233, in write
self._buffer.write(buf)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xd7' in 
position 0: ordinal not in range(128)
*** FAILED ***
LIBDIR: /thrift/src/lib/py/build/lib.linux-x86_64-2.7
PY_GEN: gen-py-default
SCRIPT: FastbinaryTest.py
Traceback (most recent call last):
  File "./RunClientServer.py", line 321, in 
sys.exit(main())
  File "./RunClientServer.py", line 300, in main
runScriptTest(options.libdir, options.gen_base, genpydir, script)
  File "./RunClientServer.py", line 101, in runScriptTest
raise Exception("Script subprocess failed, retcode=%d, args: %s" % 
(ret, ' '.join(script_args)))
Exception: Script subprocess failed, retcode=1, args: /usr/bin/python 
/thrift/src/test/py/FastbinaryTest.py
FAIL: RunClientServer.py
==
1 of 1 test failed
==
```


---

[jira] [Updated] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)


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

Jens Geyer updated THRIFT-4372:
---
Description: 
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

Symptom is that
 * the server acts as if he had written all the bytes (in fact, he did)
 * but the remainder of ~ 65535 bytes is just lost somewhere and never reaches 
the client

Consequently, the client get stuck while waiting for the remaining bytes.

  was:
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.


> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Critical
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.
> Symptom is that
>  * the server acts as if he had written all the bytes (in fact, he did)
>  * but the remainder of ~ 65535 bytes is just lost somewhere and never 
> reaches the client
> Consequently, the client get stuck while waiting for the remaining bytes.



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

[jira] [Updated] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)


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

Jens Geyer updated THRIFT-4372:
---
Priority: Critical  (was: Major)

> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Critical
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.



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

[jira] [Updated] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)


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

Jens Geyer updated THRIFT-4372:
---
Description: 
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: [WriteFileEx 
function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]

I managed to run into exactly that limit today. Patch follows.

  was:
{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: 
[https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx|WriteFileEx
 function]

I managed to run into exactly that limit today. Patch follows.


> Pipe write operations across a network are limited to 65,535 bytes per write. 
> --
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per 
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx 
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.



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

[jira] [Created] (THRIFT-4372) Pipe write operations across a network are limited to 65,535 bytes per write.

2017-10-25 Thread Jens Geyer (JIRA)

Jens Geyer created THRIFT-4372:
--

 Summary: Pipe write operations across a network are limited to 
65,535 bytes per write. 
 Key: THRIFT-4372
 URL: https://issues.apache.org/jira/browse/THRIFT-4372
 Project: Thrift
  Issue Type: Bug
  Components: C# - Library
Reporter: Jens Geyer
Assignee: Jens Geyer


{quote}Pipe write operations across a network are limited to 65,535 bytes per 
write. For more information regarding pipes, see the Remarks section.{quote}

Source: 
[https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx|WriteFileEx
 function]

I managed to run into exactly that limit today. Patch follows.



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

[jira] [Commented] (THRIFT-2998) Node.js: Missing header from http request

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-2998:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/378
  
@tstanev Thank you for putting in the time.  The PR backlog on the project 
is getting better - there were over 100 PRs at the beginning of the year and 
we're down to 50, so every little bit helps.  Of course today of all days 
Travis CI is having some pretty nasty issues with Docker Hub. :)


> Node.js: Missing header from http request
> -
>
> Key: THRIFT-2998
> URL: https://issues.apache.org/jira/browse/THRIFT-2998
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Traian Stanev
>
> The "Content-Type" header is not being set to "application/x-thrift" when 
> making http requests in the node.js implementation. This results in error 
> response (status 400) for any such connections (depending on whether the 
> server checks the header). The Python implementation for example adds the 
> header explicitly:
> https://github.com/tstanev/thrift/blob/master/lib/py/src/transport/THttpClient.py#L127



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

[GitHub] thrift issue #378: THRIFT-2998: Set Content-Type for HTTP request in Node.js...

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/378
  
@tstanev Thank you for putting in the time.  The PR backlog on the project 
is getting better - there were over 100 PRs at the beginning of the year and 
we're down to 50, so every little bit helps.  Of course today of all days 
Travis CI is having some pretty nasty issues with Docker Hub. :)


---

[jira] [Commented] (THRIFT-4271) warning: 'register' storage class is deprecated

2017-10-25 Thread Robert Lu (JIRA)


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

Robert Lu commented on THRIFT-4271:
---

When you build thrift_prototcol php extension,

after run phpize, .configure

when run make,

you will get some warming:


{code}
In file included from 
/path/to/thrift/lib/php/src/ext/thrift_protocol/php_thrift_protocol.cpp:23:
In file included from 
/usr/local/Cellar/php70/7.0.24_16/include/php/main/php.h:35:
In file included from 
/usr/local/Cellar/php70/7.0.24_16/include/php/Zend/zend.h:35:
/usr/local/Cellar/php70/7.0.24_16/include/php/Zend/zend_string.h:326:2: 
warning: 'register' storage class specifier is deprecated and incompatible with 
C++1z [-Wdeprecated-register]
register zend_ulong hash = Z_UL(5381);
^
In file included from 
/path/to/thrift/lib/php/src/ext/thrift_protocol/php_thrift_protocol.cpp:23:
In file included from 
/usr/local/Cellar/php70/7.0.24_16/include/php/main/php.h:35:
In file included from 
/usr/local/Cellar/php70/7.0.24_16/include/php/Zend/zend.h:36:
/usr/local/Cellar/php70/7.0.24_16/include/php/Zend/zend_hash.h:251:2: warning: 
'register' storage class specifier is deprecated and incompatible with C++1z 
[-Wdeprecated-register]
register const char *tmp = key;
^
In file included from 
/path/to/thrift/lib/php/src/ext/thrift_protocol/php_thrift_protocol.cpp:23:
In file included from 
/usr/local/Cellar/php70/7.0.24_16/include/php/main/php.h:35:
In file included from 
/usr/local/Cellar/php70/7.0.24_16/include/php/Zend/zend.h:343:
/usr/local/Cellar/php70/7.0.24_16/include/php/Zend/zend_operators.h:188:2: 
warning: 'register' storage class specifier is deprecated and incompatible with 
C++1z [-Wdeprecated-register]
register const unsigned char *e;
^
{code}

But, as I mentioned.

This is caused by code at PHP headers, and PHP7.1 fixed this warning.


>  warning: 'register' storage class is deprecated
> 
>
> Key: THRIFT-4271
> URL: https://issues.apache.org/jira/browse/THRIFT-4271
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Reporter: Jens Geyer
>Priority: Minor
>
> Travis emits warnings:
> {{warning: 'register' storage class specifier is deprecated 
> [-Wdeprecated-register]}}
> at multiple places.



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

[jira] [Commented] (THRIFT-2998) Node.js: Missing header from http request

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-2998:


Github user tstanev commented on the issue:

https://github.com/apache/thrift/pull/378
  
By the way -- it's been nearly three years and I have since switched to 
another way of doing things. You can close the PR if nobody else needs it.


> Node.js: Missing header from http request
> -
>
> Key: THRIFT-2998
> URL: https://issues.apache.org/jira/browse/THRIFT-2998
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Traian Stanev
>
> The "Content-Type" header is not being set to "application/x-thrift" when 
> making http requests in the node.js implementation. This results in error 
> response (status 400) for any such connections (depending on whether the 
> server checks the header). The Python implementation for example adds the 
> header explicitly:
> https://github.com/tstanev/thrift/blob/master/lib/py/src/transport/THttpClient.py#L127



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

[GitHub] thrift issue #378: THRIFT-2998: Set Content-Type for HTTP request in Node.js...

2017-10-25 Thread tstanev

Github user tstanev commented on the issue:

https://github.com/apache/thrift/pull/378
  
By the way -- it's been nearly three years and I have since switched to 
another way of doing things. You can close the PR if nobody else needs it.


---

[jira] [Commented] (THRIFT-2790) thrift -gen all => an option to generate all languages and features

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-2790:


Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/782
  
This will not generate nodejs code, to name just one case.


> thrift -gen all => an option to generate all languages and features
> ---
>
> Key: THRIFT-2790
> URL: https://issues.apache.org/jira/browse/THRIFT-2790
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General), Documentation, Test Suite
>Reporter: Roger Meier
> Attachments: 
> 0001-THRIFT-2790-gen-all-option-to-easily-test-compatibil.patch, 
> generate-all-languages.bat
>
>
> I would like to have a *thrift -gen all* option to generate everything we 
> have in one step. This would allow proper testing of all compiler changes by 
> using  test/ThriftTest.thrift. An optional make check target could compare 
> different versions based on their git hash or to previous gen-all.backup 
> folder.
> Suggested-by: Roger Meier 



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

[GitHub] thrift issue #782: THRIFT-2790 thrift -gen all => an option to generate all ...

2017-10-25 Thread Jens-G

Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/782
  
This will not generate nodejs code, to name just one case.


---

[jira] [Commented] (THRIFT-2998) Node.js: Missing header from http request

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-2998:


Github user tstanev commented on the issue:

https://github.com/apache/thrift/pull/378
  
It's rebased now.


> Node.js: Missing header from http request
> -
>
> Key: THRIFT-2998
> URL: https://issues.apache.org/jira/browse/THRIFT-2998
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Traian Stanev
>
> The "Content-Type" header is not being set to "application/x-thrift" when 
> making http requests in the node.js implementation. This results in error 
> response (status 400) for any such connections (depending on whether the 
> server checks the header). The Python implementation for example adds the 
> header explicitly:
> https://github.com/tstanev/thrift/blob/master/lib/py/src/transport/THttpClient.py#L127



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

[GitHub] thrift issue #378: THRIFT-2998: Set Content-Type for HTTP request in Node.js...

2017-10-25 Thread tstanev

Github user tstanev commented on the issue:

https://github.com/apache/thrift/pull/378
  
It's rebased now.


---

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

2017-10-25 Thread James E. King, III (JIRA)


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

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

Assignee: James E. King, III

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



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

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4207:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
I'll pull the changes into my sandbox and run unit, cross, ubsan, and sca 
jobs.


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



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

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
I'll pull the changes into my sandbox and run unit, cross, ubsan, and sca 
jobs.


---

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4207:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
Travis is experiencing an outage event w.r.t Docker Hub that started this 
morning.


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



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

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
Travis is experiencing an outage event w.r.t Docker Hub that started this 
morning.


---

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4207:


Github user elprans commented on the issue:

https://github.com/apache/thrift/pull/1274
  
Fixed, but travis seems to be unstable again.


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



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

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

2017-10-25 Thread elprans

Github user elprans commented on the issue:

https://github.com/apache/thrift/pull/1274
  
Fixed, but travis seems to be unstable again.


---

[jira] [Commented] (THRIFT-4356) thrift_protocol call Transport cause Segmentation fault

2017-10-25 Thread Daniel Smith (JIRA)


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

Daniel Smith commented on THRIFT-4356:
--

[~Robert Lu] What version of PHP was this tested on? It looks like this 
introduced a different bug for me:

PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/local/lib/php/extensions/no-debug-non-zts-20160303/thrift_protocol.so' - 
/usr/local/lib/php/extensions/no-debug-non-zts-20160303/thrift_protocol.so: 
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE in Unknown on line 0

PHP 7.1.10 (cli) (built: Oct 10 2017 01:25:12) ( NTS )

I'm running this in Docker with a base image of php:7.1-apache.  I'll try 
running it just on that image without my changes and see if there's a 
difference.

> thrift_protocol call Transport cause Segmentation fault
> ---
>
> Key: THRIFT-4356
> URL: https://issues.apache.org/jira/browse/THRIFT-4356
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: PHP 7.0.23 (cli) (built: Sep 25 2017 08:07:30) ( NTS )
> macOS 10.13.1 Beta (17B25c)
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Critical
> Fix For: 0.11.0
>
>
> When thrift_protocol extension try to read or write some bytes, if there is 
> some exception, will cause Segmentation fault



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

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

2017-10-25 Thread RandyAbernethy

Github user RandyAbernethy commented on the issue:

https://github.com/apache/thrift/pull/1318
  
I can get to this this weekend.


---

[jira] [Commented] (THRIFT-4362) Missing size-check can lead to huge memory allocation

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4362:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1398
  
We only have resources on this project to handle one release stream (and 
even then it's a challenge), so we're starting the process of making 0.11.0 
with all the changes since 0.10.0 right now.


> Missing size-check can lead to huge memory allocation
> -
>
> Key: THRIFT-4362
> URL: https://issues.apache.org/jira/browse/THRIFT-4362
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Christian Ciach
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: check-size.patch
>
>
> In some cases the method 
> {{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets 
> called with a "size" parameter that has not been validated by the existing 
> method {{checkStringReadLength(int size)}}.
> This is true if the method is called by {{readMessageBegin()}} of the same 
> class. The method {{readString()}} checks the size correctly before calling 
> {{readStringBody(int size)}}.
> Since the methods {{readStringBody(int size)}} and {{readMessageBegin()}} are 
> public, there may be other callers who don't check the size correctly.
> We encountered this issue in production several times. Because of this we are 
> currently using our own patched version of libthrift-0.9.3. The patch is 
> attached, but it is surely not the best solution, because with this patch the 
> size may be checked twice, depending on the caller.



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

[jira] [Commented] (THRIFT-4362) Missing size-check can lead to huge memory allocation

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4362:


Github user ChristianCiach commented on the issue:

https://github.com/apache/thrift/pull/1398
  
So there won't be a version 0.9.4 or 0.10.1?


> Missing size-check can lead to huge memory allocation
> -
>
> Key: THRIFT-4362
> URL: https://issues.apache.org/jira/browse/THRIFT-4362
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Christian Ciach
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: check-size.patch
>
>
> In some cases the method 
> {{org.apache.thrift.protocol.TBinaryProtocol.readStringBody(int size)}} gets 
> called with a "size" parameter that has not been validated by the existing 
> method {{checkStringReadLength(int size)}}.
> This is true if the method is called by {{readMessageBegin()}} of the same 
> class. The method {{readString()}} checks the size correctly before calling 
> {{readStringBody(int size)}}.
> Since the methods {{readStringBody(int size)}} and {{readMessageBegin()}} are 
> public, there may be other callers who don't check the size correctly.
> We encountered this issue in production several times. Because of this we are 
> currently using our own patched version of libthrift-0.9.3. The patch is 
> attached, but it is surely not the best solution, because with this patch the 
> size may be checked twice, depending on the caller.



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

[GitHub] thrift issue #1398: THRIFT-4362 check "read length" in readStringBody(int)

2017-10-25 Thread ChristianCiach

Github user ChristianCiach commented on the issue:

https://github.com/apache/thrift/pull/1398
  
So there won't be a version 0.9.4 or 0.10.1?


---

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4187:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1269
  
Don't worry, I'm just doing my usual "push things forward" bit. :)  I got 
the backlog down to 52 open PRs, but that's still about 45 too many for my 
taste.


> Dart -> Rust Framed cross tests fail
> 
>
> Key: THRIFT-4187
> URL: https://issues.apache.org/jira/browse/THRIFT-4187
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Minor
>
> For some reason the Dart (client) -> Rust (server) framed-transport cross 
> tests fail. Initial investigation shows that *somehow* the dart client think 
> the socket was closed, which means it doesn't read the message from the 
> underlying transport.



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

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1269
  
Don't worry, I'm just doing my usual "push things forward" bit. :)  I got 
the backlog down to 52 open PRs, but that's still about 45 too many for my 
taste.


---

[jira] [Commented] (THRIFT-3676) Cocoa server does not emit exceptions

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3676:


Github user asfgit closed the pull request at:

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


> Cocoa server does not emit exceptions
> -
>
> Key: THRIFT-3676
> URL: https://issues.apache.org/jira/browse/THRIFT-3676
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Reporter: Niels Grewe
>
> The server side code emitted by the Cocoa generator does not send exceptions 
> back to the client. Instead the client will be hung waiting for a response.



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

[jira] [Commented] (THRIFT-2987) TProtocol should return NSString directly rather than by reference to appease ARC

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-2987:


Github user asfgit closed the pull request at:

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


> TProtocol should return NSString directly rather than by reference to appease 
> ARC
> -
>
> Key: THRIFT-2987
> URL: https://issues.apache.org/jira/browse/THRIFT-2987
> Project: Thrift
>  Issue Type: Improvement
>  Components: Cocoa - Library
>Reporter: Jeremy W. Sherman
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As currently written, the compiler gripes like so:
> {code}
> thrift/lib/cocoa/src/protocol/TBinaryProtocol.m:161:55: warning: method 
> parameter of type 'NSString *__autoreleasing *' with no explicit ownership 
> [-Wexplicit-ownership-type]
> - (void) readMessageBeginReturningName: (NSString **) name
>   ^
> {code}
> Annotating for ownership might make non-ARC builds unhappy, but since there 
> is only one object being returned by reference, this and similar methods can 
> just be changed to return the name directly.



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

[jira] [Commented] (THRIFT-3539) Use self.process_* instead of Processor.process_* in generated processor code

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3539:


Github user asfgit closed the pull request at:

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


> Use self.process_* instead of Processor.process_* in generated processor code
> -
>
> Key: THRIFT-3539
> URL: https://issues.apache.org/jira/browse/THRIFT-3539
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Reporter: Thomas Bartelmess
>Assignee: James E. King, III
>
> In our codebase we ended up overriding the process_* handlers because we had 
> some special requirements, how exceptions are handled.
> in the __init__ function of processor the self._processMap refers to all the 
> process_* functions on the Processor class.
> {code}
> def __init__(self):
>   self._processMap = {}
>   self._processMap = Processor.process_foo
> {code}
> The processor should refer to the functions using self, so when they are 
> overridden in the subclass, the subclass implementation is used.
> {code}
> def __init__(self):
>   self._processMap = {}
>   self._processMap = self.process_foo
> {code}



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

[jira] [Commented] (THRIFT-3405) Go THttpClient misuses http.Client objects

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3405:


Github user asfgit closed the pull request at:

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


> Go THttpClient misuses http.Client objects
> --
>
> Key: THRIFT-3405
> URL: https://issues.apache.org/jira/browse/THRIFT-3405
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.9.3
> Environment: Any
>Reporter: Justin Larrabee
>Assignee: Justin Larrabee
> Fix For: 0.10.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> THttpClient:Flush creates an http.Client object every time it is called. From 
> the Go docs regarding the use of these client objects:
> "Clients and Transports are safe for concurrent use by multiple goroutines 
> and for efficiency should only be created once and re-used."
> I suggest that the client used by the THttpTransport default to using either 
> the http.DefaultClient or a package scoped default client. The transport 
> should also accept a http.Client as an optional parameter so users of the 
> library are free to control this behavior.
> With the current implementation I have run into issues when spinning up ~1000 
> separate instances of the THttpClient for a load test application I have 
> written. Switching to using a single shared http client resolved all 
> connection issues I had.



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

[jira] [Commented] (THRIFT-3395) Cocoa compiler produces corrupt code when boxing enums inside map.

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3395:


Github user asfgit closed the pull request at:

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


> Cocoa compiler produces corrupt code when boxing enums inside map.
> --
>
> Key: THRIFT-3395
> URL: https://issues.apache.org/jira/browse/THRIFT-3395
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Reporter: Aleksei Shevchenko
>Assignee: Aleksei Shevchenko
> Fix For: 0.10.0
>
>
> Essentially fix for https://issues.apache.org/jira/browse/THRIFT-2905 and PR 
> #652.
> Given something like this:
> {code}
> void someRpcCall(1:map param);
> {code}
> Cocoa compiler produces corrupt implementation.
> {code}
> - (BOOL) someRpcCall:(NSDictionary< , > *) param error: (NSError 
> *__autoreleasing *)__thriftError;
> {code}
> This fixes it so code rendered properly, boxing enums into NSNumber*.
>  



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

[jira] [Commented] (THRIFT-3830) Add detail exception message between server-side and client-side

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3830:


Github user asfgit closed the pull request at:

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


> Add  detail exception message between server-side and  client-side
> --
>
> Key: THRIFT-3830
> URL: https://issues.apache.org/jira/browse/THRIFT-3830
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Dongchao Ding
>Priority: Minor
>
> At present，when one TExcpetion occurs at server-side,  we just get one same 
> error tip like "Internal error processing ${invoke-method-name}", the detail 
> exception(exception message and exception stack) was gone.
> I think it's better to send detail  error info to client .



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

[jira] [Commented] (THRIFT-3743) Java JSON protocol left in incorrect state when an exception is thrown during read or write operations

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3743:


Github user asfgit closed the pull request at:

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


> Java JSON protocol left in incorrect state when an exception is thrown during 
> read or write operations
> --
>
> Key: THRIFT-3743
> URL: https://issues.apache.org/jira/browse/THRIFT-3743
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Reporter: Tyler Treat
>Assignee: Tyler Treat
> Fix For: 0.10.0
>
>
> This is the same issue as THRIFT-1473 (Delphi) and THRIFT-3735 (Go) but for 
> the Java library.
> The JSON context stack may be left in an incorrect state when an exception is 
> thrown during read or write operations. This leads to further errors while 
> writing/reading the NEXT message, because incorrect characters may be written 
> or expected.



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

[GitHub] thrift pull request #947: THRIFT-3743 Java JSON protocol left in incorrect s...

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #657: Cocoa compiler: fixed incorrect boxing of enums in...

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #896: THRIFT-3676

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #1012: THRIFT-3830

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #387: THRIFT-2987: returns message/struct/field names di...

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #794: Update NodeClient.js

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #701: THRIFT-3405

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #1015: Update connection.js

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #562: Thrift 3265--servers for pipe applications (stdin,...

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] thrift pull request #480: make generated js file strict mode for nodejs

2017-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4187:


Github user allengeorge commented on the issue:

https://github.com/apache/thrift/pull/1269
  
Hi James - I’m really sorry for the delay; slammed at work. I’ll work on it 
this weekend.

Again, super sorry about this


From: James E. King, III 
Sent: Wednesday, October 25, 2017 10:44:19 AM
To: apache/thrift
Cc: Allen George; Mention
Subject: Re: [apache/thrift] THRIFT-4187 Allow dart framed transport to 
read incomplete frame (#1269)


@allengeorge if you add framed transport in 
dart to the cross test, that would test a lot... but it would not test error 
conditions such as this one. Just a reminder, this needs to move forward.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.



> Dart -> Rust Framed cross tests fail
> 
>
> Key: THRIFT-4187
> URL: https://issues.apache.org/jira/browse/THRIFT-4187
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Minor
>
> For some reason the Dart (client) -> Rust (server) framed-transport cross 
> tests fail. Initial investigation shows that *somehow* the dart client think 
> the socket was closed, which means it doesn't read the message from the 
> underlying transport.



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

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

2017-10-25 Thread allengeorge

Github user allengeorge commented on the issue:

https://github.com/apache/thrift/pull/1269
  
Hi James - Iâm really sorry for the delay; slammed at work. Iâll work 
on it this weekend.

Again, super sorry about this


From: James E. King, III 
Sent: Wednesday, October 25, 2017 10:44:19 AM
To: apache/thrift
Cc: Allen George; Mention
Subject: Re: [apache/thrift] THRIFT-4187 Allow dart framed transport to 
read incomplete frame (#1269)


@allengeorge if you add framed transport in 
dart to the cross test, that would test a lot... but it would not test error 
conditions such as this one. Just a reminder, this needs to move forward.

â
You are receiving this because you were mentioned.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.



---

[GitHub] thrift issue #1380: Support x64 build mode on Windows with DMD v2.076.0.

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1380
  
Any news?


---

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1318
  
@dthaluru, @RandyAbernethy any updates?


---

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4207:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
This had some errors and needs more work - please move it forward.


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



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

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

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


---

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

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4187:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1269
  
@allengeorge if you add framed transport in dart to the cross test, that 
would test a lot... but it would not test error conditions such as this one.  
Just a reminder, this needs to move forward.


> Dart -> Rust Framed cross tests fail
> 
>
> Key: THRIFT-4187
> URL: https://issues.apache.org/jira/browse/THRIFT-4187
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Minor
>
> For some reason the Dart (client) -> Rust (server) framed-transport cross 
> tests fail. Initial investigation shows that *somehow* the dart client think 
> the socket was closed, which means it doesn't read the message from the 
> underlying transport.



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

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

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

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

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


---

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1274
  
This had some errors and needs more work - please move it forward.


---

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1269
  
@allengeorge if you add framed transport in dart to the cross test, that 
would test a lot... but it would not test error conditions such as this one.  
Just a reminder, this needs to move forward.


---

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

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1261
  
@djzort reminder we need a Jira THRIFT issue and squash and rebase on 
master.


---

[GitHub] thrift pull request #1141: support for timeout in node http connection

2017-10-25 Thread jeking3

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

https://github.com/apache/thrift/pull/1141#discussion_r146879631
  
--- Diff: lib/nodejs/lib/thrift/http_connection.js ---
@@ -214,6 +214,18 @@ HttpConnection.prototype.write = function(data) {
   var req = (self.https) ?
   https.request(self.nodeOptions, self.responseCallback) :
   http.request(self.nodeOptions, self.responseCallback);
+
+  //support for timeout
+  var timeout = self.nodeOptions.timeout;
+  if(timeout){
+req.on('socket', function (socket) {
+socket.setTimeout(timeout);  
+socket.on('timeout', function() {
+req.abort();
+});
+});
+  }
--- End diff --

It looks like additional work is needed here; @guptanishank will you be 
moving this forward?


---

[jira] [Commented] (THRIFT-3773) Swift Library

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3773:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1084
  
What needs to happen next to move this forward?


> Swift Library
> -
>
> Key: THRIFT-3773
> URL: https://issues.apache.org/jira/browse/THRIFT-3773
> Project: Thrift
>  Issue Type: New Feature
>  Components: Swift - Library
>Reporter: Thomas Bartelmess
>Assignee: Chris Simpson
>
> We already have the option to generate Swift code in the Cocoa compiler, 
> however large parts of the (Objective-C) Cocoa Library still depend on Cocoa 
> and  Objective-C.
> It would be good to have a native Swift library that doesn't depend on the 
> Cocoa libraries.
> Design goals:
> - Fully compatible with the code that is currently generated by the Cocoa 
> compiler (both Objective-C and Swift).
> - Ability to run on Linux
> - Pure Swift, no Objective-C code.
> - No dependencies on closed source apple libraries
> - Keep the same interface, so that the library is compatible with the code 
> the current cocoa compiler generates
> - Better server support that the current Objective-C library.
> - Follow the new Swift packaging format to be compatible with the Swift 
> Package manager



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

[GitHub] thrift issue #1093: Add persistence patch

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1093
  
@StachOverflow will you be moving this forward or should it be closed?


---

[jira] [Commented] (THRIFT-3916) Errors thrown from JavaScript client is strings and not errors

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3916:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1075
  
@SimenB if you are interested in resurrecting this let me know - rebase on 
current master and push to CI will run all our tests.


> Errors thrown from JavaScript client is strings and not errors
> --
>
> Key: THRIFT-3916
> URL: https://issues.apache.org/jira/browse/THRIFT-3916
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler
>Reporter: Simen Bekkhus
>Priority: Minor
>  Labels: javascript
>
> In JavaScript, you can {{throw}} any object, including strings, but to get 
> stack traces one should throw {{Errors}}.
> The generated JS code throws the error string directly, instead of wrapping 
> it in {{new Error}}.
> Node core _only_ rejects with/throws Errors, never strings, and Thrift should 
> follow the same standard.
> https://nodejs.org/api/errors.html#errors_class_error
> {quote}
> All errors generated by Node.js, including all System and JavaScript errors, 
> will either be instances of, or inherit from, the Error class.
> {quote}
> PR for the change [here|https://github.com/apache/thrift/pull/1075].



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

[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1084
  
What needs to happen next to move this forward?


---

[GitHub] thrift issue #1075: THRIFT-3916 Throw proper errors from JS, not strings

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1075
  
@SimenB if you are interested in resurrecting this let me know - rebase on 
current master and push to CI will run all our tests.


---

[jira] [Commented] (THRIFT-3876) haxe js/nodejs client

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3876:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1045
  
So I agree that changes like this need representation in the cross test.  
It would be nice if folks could patch up any ill will and move this forward.


> haxe js/nodejs client
> -
>
> Key: THRIFT-3876
> URL: https://issues.apache.org/jira/browse/THRIFT-3876
> Project: Thrift
>  Issue Type: Improvement
>  Components: Haxe - Library
>Reporter: Oleksii Prudkyi
>Assignee: Oleksii Prudkyi
>




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

[GitHub] thrift issue #1058: Node.js: Set/unset client seqid for json_protocol and co...

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1058
  
This change needs a Jira ticket; please see 
https://thrift.apache.org/docs/HowToContribute. Also if you can rebase on 
master and push that will kick a new CI build; CI needs to pass (or failures 
easily explained) to merge.


---

[GitHub] thrift issue #1056: java: adding factories to the generated Java classes

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1056
  
This needs to be rebased on the current master and resubmitted; we need a 
clean CI build before we can proceed.


---

[GitHub] thrift issue #1045: THRIFT-3876 haxe js/nodejs client

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1045
  
So I agree that changes like this need representation in the cross test.  
It would be nice if folks could patch up any ill will and move this forward.


---

[GitHub] thrift issue #1038: replace 'binary' on the base types

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1038
  
This needs a Jira item opened for it, and needs to be rebased and merge 
conflicts fixed.
See; https://thrift.apache.org/docs/HowToContribute
Thanks.


---

[GitHub] thrift issue #1003: passing exception back to handler for custom use cases

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1003
  
@gonthe can you rebase on master?


---

[jira] [Commented] (THRIFT-3812) Option to prefix namespace to Swift type names

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3812:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1002
  
This hasn't been touched in over a year - what needs to be done?


> Option to prefix namespace to Swift type names
> --
>
> Key: THRIFT-3812
> URL: https://issues.apache.org/jira/browse/THRIFT-3812
> Project: Thrift
>  Issue Type: New Feature
>  Components: Swift - Compiler
>Reporter: Håkon Hitland
>Priority: Minor
>
> Swift does have a way to namespace things within a pod, which can lead to 
> name collisions.
> This adds an option "swift:prefix_namespace" that will add Cocoa-style 
> prefixes to the generated code if the file has a defined Swift namespace.



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

[GitHub] thrift issue #1002: THRIFT-3812 Add option to prefix namespace Swift type na...

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1002
  
This hasn't been touched in over a year - what needs to be done?


---

[jira] [Commented] (THRIFT-3783) python code generator dose not handle struct dependent

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3783:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/982
  
Does this need further work or should it be closed?


> python code generator dose not handle struct dependent
> --
>
> Key: THRIFT-3783
> URL: https://issues.apache.org/jira/browse/THRIFT-3783
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Reporter: Huabin
>Priority: Minor
>
> given thrift idl
> {code}
> struct A {
> 1: B b,
> }
> struct B {
> 1: i32 b,
> }
> {code}
> generated ttypes.py
> {code}
> 20   class A:
>  21   """
>  22   Attributes:
>  23- b
>  24   """
>  25  
>  26   thrift_spec = (
>  27 None, # 0
>  28 (1, TType.STRUCT, 'b', (B, B.thrift_spec), None, ), # 1
>  29   )
>  30  
> {code}
> import A will cause error since it referenced B, which has not be defined.



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

[GitHub] thrift issue #982: THRIFT-3783: python code generator dose not handle struct...

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/982
  
Does this need further work or should it be closed?


---

[GitHub] thrift issue #979: THRIFT-3779 Qt Client Android and Windows QTcpSocket

2017-10-25 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/979
  
Folks who originally commented on this, please follow up.


---

[jira] [Commented] (THRIFT-3779) Qt Client Android and Windows QTcpSocket

2017-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3779:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/979
  
Folks who originally commented on this, please follow up.


> Qt Client Android and Windows QTcpSocket
> 
>
> Key: THRIFT-3779
> URL: https://issues.apache.org/jira/browse/THRIFT-3779
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Library
> Environment: Qt Windows, Qt Android on windows
>Reporter: Gjergji Ramku
>Priority: Minor
>  Labels: features
>
> Thrift Client library based on QTcpSocket.
> QTcpSocket should help make a tcp socket client run on all platforms where Qt 
> runs.
> Is there such port?
> I already have a port that I have tested on Qt Android and Qt Windows clients.



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

1 2 >

1 - 100 of 166 matches

Mail list logo