[jira] [Resolved] (THRIFT-4089) Several issues with generated Python code: TFrozenDict, _fast_encode

2017-02-21 Thread Manasi Vartak (JIRA)

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

Manasi Vartak resolved THRIFT-4089.
---
Resolution: Information Provided

> Several issues with generated Python code: TFrozenDict, _fast_encode
> 
>
> Key: THRIFT-4089
> URL: https://issues.apache.org/jira/browse/THRIFT-4089
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Affects Versions: 0.10.0
> Environment: Python 2.7, 3.5. OS-X
>Reporter: Manasi Vartak
>
> When you generate Python sources for a simple thrift file (e.g. Thrift 
> tutorial from https://thrift.apache.org/tutorial/py will also repro erros), 
> errors are thrown while running the PythonServer and PythonClient.
> 1.  When running the vanilla PythonServer, I get the following error:
> File "gen-py/shared/SharedService.py", line 9, in 
> from thrift.Thrift import TType, TMessageType, TFrozenDict, TException, 
> TApplicationException 
> ImportError: cannot import name TFrozenDict
> I see this error consistently for all generated thrift files. The error 
> disappears on removing TFrozenDict from the generated files (it is not used 
> anywhere in the file).
> 2. When running the vanilla PythonClient (the server is now running after the 
> above fix), I get the following error:
>  File "PythonClient.py", line 51, in main
> client.ping()
>   File "gen-py/tutorial/Calculator.py", line 73, in ping
> self.send_ping()
>   File "gen-py/tutorial/Calculator.py", line 79, in send_ping
> args.write(self._oprot)
>   File "gen-py/tutorial/Calculator.py", line 297, in write
> if oprot._fast_encode is not None and self.thrift_spec is not None:
> AttributeError: TBinaryProtocol instance has no attribute '_fast_encode'
> I am not sure why this error is being thrown/what can be done to fix it.
> These two errors, and mainly the latter one, are rendering the Server/Client 
> un-usable. Is this a known issue? And how do you recommend working around it?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-4089) Several issues with generated Python code: TFrozenDict, _fast_encode

2017-02-21 Thread Manasi Vartak (JIRA)

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

Manasi Vartak commented on THRIFT-4089:
---

That was indeed the issue, thank you!

> Several issues with generated Python code: TFrozenDict, _fast_encode
> 
>
> Key: THRIFT-4089
> URL: https://issues.apache.org/jira/browse/THRIFT-4089
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Affects Versions: 0.10.0
> Environment: Python 2.7, 3.5. OS-X
>Reporter: Manasi Vartak
>
> When you generate Python sources for a simple thrift file (e.g. Thrift 
> tutorial from https://thrift.apache.org/tutorial/py will also repro erros), 
> errors are thrown while running the PythonServer and PythonClient.
> 1.  When running the vanilla PythonServer, I get the following error:
> File "gen-py/shared/SharedService.py", line 9, in 
> from thrift.Thrift import TType, TMessageType, TFrozenDict, TException, 
> TApplicationException 
> ImportError: cannot import name TFrozenDict
> I see this error consistently for all generated thrift files. The error 
> disappears on removing TFrozenDict from the generated files (it is not used 
> anywhere in the file).
> 2. When running the vanilla PythonClient (the server is now running after the 
> above fix), I get the following error:
>  File "PythonClient.py", line 51, in main
> client.ping()
>   File "gen-py/tutorial/Calculator.py", line 73, in ping
> self.send_ping()
>   File "gen-py/tutorial/Calculator.py", line 79, in send_ping
> args.write(self._oprot)
>   File "gen-py/tutorial/Calculator.py", line 297, in write
> if oprot._fast_encode is not None and self.thrift_spec is not None:
> AttributeError: TBinaryProtocol instance has no attribute '_fast_encode'
> I am not sure why this error is being thrown/what can be done to fix it.
> These two errors, and mainly the latter one, are rendering the Server/Client 
> un-usable. Is this a known issue? And how do you recommend working around it?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (THRIFT-4081) Provide a MinGW 64-bit Appveyor CI build for better pull request validation

2017-02-21 Thread James E. King, III (JIRA)

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

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

Assignee: James E. King, III

> Provide a MinGW 64-bit Appveyor CI build for better pull request validation
> ---
>
> Key: THRIFT-4081
> URL: https://issues.apache.org/jira/browse/THRIFT-4081
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appveyor
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> We currently build in Visual Studio 2015 on Appveyor.  We do not use the 
> Windows CI environment to verify that MinGW still builds successfully (there 
> is a 32-bit job on linux, #16, which runs on every pull request).  I would 
> recommend that we add a CI build job to Appveyor and/or extend the existing 
> job to build with the latest MinGW 64-bit environment which includes 
> gcc-6.3.0; we could perhaps remove Travis job #16 which is using 32-bit mingw 
> on linux as a result?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1200
  
Pushed an empty commit to get a clean CI build, despite the fact that the 
only Travis CI build failure was environmental (couldn't reach a docker server).


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift issue #1200: THRIFT-3706: glib client/java server/crosstest multiplex...

2017-02-21 Thread jeking3
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1200
  
Pushed an empty commit to get a clean CI build, despite the fact that the 
only Travis CI build failure was environmental (couldn't reach a docker server).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-4091) Removed unused realloc test causing autoconf warnings at bootstrap time

2017-02-21 Thread James E. King, III (JIRA)

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

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


Issue was introduced in 0.11.0 and reverted in 0.11.0 so I marked it as Fix 
Version "None".

> Removed unused realloc test causing autoconf warnings at bootstrap time
> ---
>
> Key: THRIFT-4091
> URL: https://issues.apache.org/jira/browse/THRIFT-4091
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu 14.04
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Trivial
>
> Following THRIFT-4045 bootstrap posts a couple warnings:
> {noformat}
> configure.ac: warning: missing AC_FUNC_MALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:99
> configure.ac: warning: missing AC_FUNC_REALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:29
> {noformat}
> This test is not built or used so it can be removed.  Removing the test 
> uncovers others, so THRIFT-4045 is a bad fix.  Revert it and provide guidance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (THRIFT-4091) Removed unused realloc test causing autoconf warnings at bootstrap time

2017-02-21 Thread James E. King, III (JIRA)

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

James E. King, III closed THRIFT-4091.
--

> Removed unused realloc test causing autoconf warnings at bootstrap time
> ---
>
> Key: THRIFT-4091
> URL: https://issues.apache.org/jira/browse/THRIFT-4091
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu 14.04
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Trivial
>
> Following THRIFT-4045 bootstrap posts a couple warnings:
> {noformat}
> configure.ac: warning: missing AC_FUNC_MALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:99
> configure.ac: warning: missing AC_FUNC_REALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:29
> {noformat}
> This test is not built or used so it can be removed.  Removing the test 
> uncovers others, so THRIFT-4045 is a bad fix.  Revert it and provide guidance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (THRIFT-4091) Removed unused realloc test causing autoconf warnings at bootstrap time

2017-02-21 Thread James E. King, III (JIRA)

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

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

> Removed unused realloc test causing autoconf warnings at bootstrap time
> ---
>
> Key: THRIFT-4091
> URL: https://issues.apache.org/jira/browse/THRIFT-4091
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu 14.04
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Trivial
>
> Following THRIFT-4045 bootstrap posts a couple warnings:
> {noformat}
> configure.ac: warning: missing AC_FUNC_MALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:99
> configure.ac: warning: missing AC_FUNC_REALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:29
> {noformat}
> This test is not built or used so it can be removed.  Removing the test 
> uncovers others, so THRIFT-4045 is a bad fix.  Revert it and provide guidance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (THRIFT-4091) Removed unused realloc test causing autoconf warnings at bootstrap time

2017-02-21 Thread James E. King, III (JIRA)

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

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

> Removed unused realloc test causing autoconf warnings at bootstrap time
> ---
>
> Key: THRIFT-4091
> URL: https://issues.apache.org/jira/browse/THRIFT-4091
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu 14.04
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Trivial
>
> Following THRIFT-4045 bootstrap posts a couple warnings:
> {noformat}
> configure.ac: warning: missing AC_FUNC_MALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:99
> configure.ac: warning: missing AC_FUNC_REALLOC wanted by: 
> test/cpp/realloc/realloc_test.c:29
> {noformat}
> This test is not built or used so it can be removed.  Removing the test 
> uncovers others, so THRIFT-4045 is a bad fix.  Revert it and provide guidance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (THRIFT-3522) In multiplexer mode, when data gets big, error occurs in accepting data

2017-02-21 Thread James E. King, III (JIRA)

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

James E. King, III closed THRIFT-3522.
--

> In multiplexer mode, when data gets big, error occurs in accepting data
> ---
>
> Key: THRIFT-3522
> URL: https://issues.apache.org/jira/browse/THRIFT-3522
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
> Environment: node.js
>Reporter: Amos Chen
>Assignee: James E. King, III
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (THRIFT-3522) In multiplexer mode, when data gets big, error occurs in accepting data

2017-02-21 Thread James E. King, III (JIRA)

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

James E. King, III resolved THRIFT-3522.

Resolution: Duplicate

See THRIFT-3801

> In multiplexer mode, when data gets big, error occurs in accepting data
> ---
>
> Key: THRIFT-3522
> URL: https://issues.apache.org/jira/browse/THRIFT-3522
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
> Environment: node.js
>Reporter: Amos Chen
>Assignee: James E. King, III
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (THRIFT-3522) In multiplexer mode, when data gets big, error occurs in accepting data

2017-02-21 Thread James E. King, III (JIRA)

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

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

Assignee: James E. King, III

> In multiplexer mode, when data gets big, error occurs in accepting data
> ---
>
> Key: THRIFT-3522
> URL: https://issues.apache.org/jira/browse/THRIFT-3522
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
> Environment: node.js
>Reporter: Amos Chen
>Assignee: James E. King, III
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (THRIFT-3801) Node Thrift client throws exception with multiplexer and responses that are bigger than a single buffer

2017-02-21 Thread James E. King, III (JIRA)

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

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

Assignee: James E. King, III

> Node Thrift client throws exception with multiplexer and responses that are 
> bigger than a single buffer
> ---
>
> Key: THRIFT-3801
> URL: https://issues.apache.org/jira/browse/THRIFT-3801
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
>Reporter: Mark White
>Assignee: James E. King, III
>
> In a situation using the node.js library to make requests using the buffered 
> transport, binary protocol and the multiplexer, I've been getting an 
> exception on receiving responses from line 145 of connection.js 
> (https://github.com/apache/thrift/blob/0.9.3/lib/nodejs/lib/thrift/connection.js).
> at TCP.onread (net.js:531:20)
> at Socket.Readable.push (_stream_readable.js:111:10)
> at readableAddChunk (_stream_readable.js:153:18)
> at Socket.emit (events.js:169:7)
> at emitOne (events.js:77:13)
> at Socket. 
> (/src/node_modules/thrift/lib/nodejs/lib/thrift/buffered_transport.js:48:5)
> at /src/node_modules/thrift/lib/nodejs/lib/thrift/connection.js:151:35
> TypeError: Cannot set property '-1' of undefined
> It looks like the issue is that if a message consists of multiple parts, the 
> first part removes the seqid to service mapping in line 142, then it's no 
> longer available for the second part thus the error. If I'm right the fix 
> would be to remove the mapping later on once the final part has arrived.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3801) Node Thrift client throws exception with multiplexer and responses that are bigger than a single buffer

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3801:


GitHub user jeking3 opened a pull request:

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

THRIFT-3801: Fix exception with nodejs multiplexer

THRIFT-3801 - Node Thrift client throws exception with multiplexer and 
responses that are bigger than a single buffer

Supercedes https://github.com/apache/thrift/pull/1063
Supercedes https://github.com/apache/thrift/pull/773

Just want a clean CI build before merging.

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

$ git pull https://github.com/jeking3/thrift THRIFT-3801

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

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


commit b7578b966197592bc30577e07af368461477
Author: Adam Curtis 
Date:   2016-08-11T09:47:37Z

Fix exception with nodejs multiplexer

THRIFT-3801 - Node Thrift client throws exception with multiplexer and 
responses that are bigger than a single buffer




> Node Thrift client throws exception with multiplexer and responses that are 
> bigger than a single buffer
> ---
>
> Key: THRIFT-3801
> URL: https://issues.apache.org/jira/browse/THRIFT-3801
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.3
>Reporter: Mark White
>
> In a situation using the node.js library to make requests using the buffered 
> transport, binary protocol and the multiplexer, I've been getting an 
> exception on receiving responses from line 145 of connection.js 
> (https://github.com/apache/thrift/blob/0.9.3/lib/nodejs/lib/thrift/connection.js).
> at TCP.onread (net.js:531:20)
> at Socket.Readable.push (_stream_readable.js:111:10)
> at readableAddChunk (_stream_readable.js:153:18)
> at Socket.emit (events.js:169:7)
> at emitOne (events.js:77:13)
> at Socket. 
> (/src/node_modules/thrift/lib/nodejs/lib/thrift/buffered_transport.js:48:5)
> at /src/node_modules/thrift/lib/nodejs/lib/thrift/connection.js:151:35
> TypeError: Cannot set property '-1' of undefined
> It looks like the issue is that if a message consists of multiple parts, the 
> first part removes the seqid to service mapping in line 142, then it's no 
> longer available for the second part thus the error. If I'm right the fix 
> would be to remove the mapping later on once the final part has arrived.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1202: THRIFT-3801: Fix exception with nodejs multiplexe...

2017-02-21 Thread jeking3
GitHub user jeking3 opened a pull request:

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

THRIFT-3801: Fix exception with nodejs multiplexer

THRIFT-3801 - Node Thrift client throws exception with multiplexer and 
responses that are bigger than a single buffer

Supercedes https://github.com/apache/thrift/pull/1063
Supercedes https://github.com/apache/thrift/pull/773

Just want a clean CI build before merging.

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

$ git pull https://github.com/jeking3/thrift THRIFT-3801

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

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


commit b7578b966197592bc30577e07af368461477
Author: Adam Curtis 
Date:   2016-08-11T09:47:37Z

Fix exception with nodejs multiplexer

THRIFT-3801 - Node Thrift client throws exception with multiplexer and 
responses that are bigger than a single buffer




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Resolved] (THRIFT-4076) Appveyor builds failing because ant 1.9.8 was removed from apache servers

2017-02-21 Thread James E. King, III (JIRA)

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

James E. King, III resolved THRIFT-4076.

Resolution: Fixed

> Appveyor builds failing because ant 1.9.8 was removed from apache servers
> -
>
> Key: THRIFT-4076
> URL: https://issues.apache.org/jira/browse/THRIFT-4076
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appyevor CI
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Blocker
> Fix For: 0.11.0
>
>
> ant was upgraded to 1.9.9 and broke our build
> I am going to switch it over to using chocolatey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-4076) Appveyor builds failing because ant 1.9.8 was removed from apache servers

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-4076:


Github user asfgit closed the pull request at:

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


> Appveyor builds failing because ant 1.9.8 was removed from apache servers
> -
>
> Key: THRIFT-4076
> URL: https://issues.apache.org/jira/browse/THRIFT-4076
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appyevor CI
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Blocker
> Fix For: 0.11.0
>
>
> ant was upgraded to 1.9.9 and broke our build
> I am going to switch it over to using chocolatey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1201: THRIFT-4076: appveyor needs to pick up PATH chang...

2017-02-21 Thread asfgit
Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3752) nil collections are serialized as empty collections

2017-02-21 Thread John Sirois (JIRA)

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

John Sirois commented on THRIFT-3752:
-

[~jking], I don't think so. The compiler still does the {{IsSetXXX, 
WriteFieldBegin}} sequence, and the problem noted in this issue is this encodes 
a different notion of "unset requiredness" than the java compiler. The issue 
was specifically cross-lang incompatibility. So unless the java compiler has 
been changed to have the same notion of "unset requiredness" in the intervening 
time (aka if the cross-tests are enabled, complete and including all 
languages), this is probably still an issue.

> nil collections are serialized as empty collections
> ---
>
> Key: THRIFT-3752
> URL: https://issues.apache.org/jira/browse/THRIFT-3752
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: John Sirois
>Assignee: John Sirois
>
> See discussion here: https://reviews.apache.org/r/45193/
> This is likely related to THRIFT-3700.
> In short, for this struct:
> {noformat}
> struct TaskQuery {
> 4: optional set taskIds
> }
> {noformat}
> The following go struct is generated:
> {noformat}
> type TaskQuery struct {
>   TaskIds  map[string]bool `thrift:"taskIds,4" json:"taskIds"`
> }
> {noformat}
> This is all well and good, since {{TaskQuery{}.TaskIds == nil}}; ie the 
> {{TaskIds}} collection field is - by default - unset.
> The problem is in the serialization for the field, which wipes out the unset 
> ({{nil}}) vs empty collection distinction at the wire level:
> {noformat}
> func (p *TaskQuery) writeField4(oprot thrift.TProtocol) (err error) {
>   if err := oprot.WriteFieldBegin("taskIds", thrift.SET, 4); err != nil {
>   return thrift.PrependError(fmt.Sprintf("%T write field begin 
> error 4:taskIds: ", p), err)
>   }
>   if err := oprot.WriteSetBegin(thrift.STRING, len(p.TaskIds)); err != 
> nil {
>   return thrift.PrependError("error writing set begin: ", err)
>   }
>   for v, _ := range p.TaskIds {
>   if err := oprot.WriteString(string(v)); err != nil {
>   return thrift.PrependError(fmt.Sprintf("%T. (0) field 
> write error: ", p), err)
>   }
>   }
>   if err := oprot.WriteSetEnd(); err != nil {
>   return thrift.PrependError("error writing set end: ", err)
>   }
>   if err := oprot.WriteFieldEnd(); err != nil {
>   return thrift.PrependError(fmt.Sprintf("%T write field end 
> error 4:taskIds: ", p), err)
>   }
>   return err
> }
> {noformat}
> So on the receiving end of the wire, a {{nil}} collection is turned into an 
> empty collection and so unset-ness cannot be distinguished from set but empty.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3752) nil collections are serialized as empty collections

2017-02-21 Thread James E. King, III (JIRA)

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

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


Is it possible THRIFT-4011 helped to resolve this issue?

> nil collections are serialized as empty collections
> ---
>
> Key: THRIFT-3752
> URL: https://issues.apache.org/jira/browse/THRIFT-3752
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: John Sirois
>Assignee: John Sirois
>
> See discussion here: https://reviews.apache.org/r/45193/
> This is likely related to THRIFT-3700.
> In short, for this struct:
> {noformat}
> struct TaskQuery {
> 4: optional set taskIds
> }
> {noformat}
> The following go struct is generated:
> {noformat}
> type TaskQuery struct {
>   TaskIds  map[string]bool `thrift:"taskIds,4" json:"taskIds"`
> }
> {noformat}
> This is all well and good, since {{TaskQuery{}.TaskIds == nil}}; ie the 
> {{TaskIds}} collection field is - by default - unset.
> The problem is in the serialization for the field, which wipes out the unset 
> ({{nil}}) vs empty collection distinction at the wire level:
> {noformat}
> func (p *TaskQuery) writeField4(oprot thrift.TProtocol) (err error) {
>   if err := oprot.WriteFieldBegin("taskIds", thrift.SET, 4); err != nil {
>   return thrift.PrependError(fmt.Sprintf("%T write field begin 
> error 4:taskIds: ", p), err)
>   }
>   if err := oprot.WriteSetBegin(thrift.STRING, len(p.TaskIds)); err != 
> nil {
>   return thrift.PrependError("error writing set begin: ", err)
>   }
>   for v, _ := range p.TaskIds {
>   if err := oprot.WriteString(string(v)); err != nil {
>   return thrift.PrependError(fmt.Sprintf("%T. (0) field 
> write error: ", p), err)
>   }
>   }
>   if err := oprot.WriteSetEnd(); err != nil {
>   return thrift.PrependError("error writing set end: ", err)
>   }
>   if err := oprot.WriteFieldEnd(); err != nil {
>   return thrift.PrependError(fmt.Sprintf("%T write field end 
> error 4:taskIds: ", p), err)
>   }
>   return err
> }
> {noformat}
> So on the receiving end of the wire, a {{nil}} collection is turned into an 
> empty collection and so unset-ness cannot be distinguished from set but empty.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions

2017-02-21 Thread James E. King, III (JIRA)

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

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


[~jensg], [~nsuke], [~roger.meier] could one (or more, of course!) of you 
review the current pull request which completed CI testing successfully?  There 
was a lot of discussion on this and I don't want to merge it until at least one 
of you has a chance to review and approve.  
https://github.com/apache/thrift/pull/1186


> Thrift should not swallow ALL exceptions
> 
>
> Key: THRIFT-1805
> URL: https://issues.apache.org/jira/browse/THRIFT-1805
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.9
>Reporter: Diwaker Gupta
>Assignee: Diwaker Gupta
> Attachments: THRIFT-1805.patch
>
>
> In Thrift 0.8.0, Thrift generated Java code did not swallow application 
> exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and 
> now the generated code swallows ALL application exceptions (via 
> ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while 
> I see the rationale, it is breaking our applications.
> Our code relies on the fact that exceptions can propagate outside of Thrift 
> for certain things (e.g., to aggressively drop connections for clients that 
> send invalid/malformed requests). ProcessFunction makes it near impossible to 
> do this -- not only does it swallow the exception, it also loses all 
> information about the original exception and just writes out a generic 
> TApplicationException.
> IMO ProcessFunction should only catch TException. If the application code 
> wants to use other exceptions for some reason (in particular, Errors and 
> RuntimeExceptions), Thrift shouldn't prevent that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1200
  
@gadLinux thank you for such a thorough review.  All good questions, 
hopefully my answers make sense.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift issue #1200: THRIFT-3706: glib client/java server/crosstest multiplex...

2017-02-21 Thread jeking3
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1200
  
@gadLinux thank you for such a thorough review.  All good questions, 
hopefully my answers make sense.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102357395
  
--- Diff: lib/java/test/org/apache/thrift/test/TestServer.java ---
@@ -190,7 +193,9 @@ public static void main(String [] args) {
 if (protocol_type.equals("binary")) {
 } else if (protocol_type.equals("compact")) {
 } else if (protocol_type.equals("json")) {
-} else if (protocol_type.equals("multiplexed")) {
+} else if (protocol_type.equals("multi")) {
--- End diff --

I did it this way to work within the spec:impl naming convention that 
currently exists in make cross.  See tests.json, specifically "binary:accel" or 
"compact:accelc".  I wanted to follow the pattern that already existed in the 
test suite so we have a single use pattern, not two.  In the end the behavior 
is mostly the same, except by using "multi:binary" on the java server and 
"binary:multi" on the c_glib client, we end up testing:  c_glib (binary client) 
=> java (multi server) as well as c_glib (multi client wrapping binary) => java 
(multi server wrapping binary).  Using the "multiplexed-binary" naming 
convention would not have leveraged the existing logic in crosstest/collect.py 
to make this happen.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server/crosstest mu...

2017-02-21 Thread jeking3
Github user jeking3 commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102357395
  
--- Diff: lib/java/test/org/apache/thrift/test/TestServer.java ---
@@ -190,7 +193,9 @@ public static void main(String [] args) {
 if (protocol_type.equals("binary")) {
 } else if (protocol_type.equals("compact")) {
 } else if (protocol_type.equals("json")) {
-} else if (protocol_type.equals("multiplexed")) {
+} else if (protocol_type.equals("multi")) {
--- End diff --

I did it this way to work within the spec:impl naming convention that 
currently exists in make cross.  See tests.json, specifically "binary:accel" or 
"compact:accelc".  I wanted to follow the pattern that already existed in the 
test suite so we have a single use pattern, not two.  In the end the behavior 
is mostly the same, except by using "multi:binary" on the java server and 
"binary:multi" on the c_glib client, we end up testing:  c_glib (binary client) 
=> java (multi server) as well as c_glib (multi client wrapping binary) => java 
(multi server wrapping binary).  Using the "multiplexed-binary" naming 
convention would not have leveraged the existing logic in crosstest/collect.py 
to make this happen.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102356989
  
--- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_socket.h ---
@@ -50,11 +50,8 @@ struct _ThriftSocket
 
   /* private */
   gchar *hostname;
-  gshort port;
+  guint port;
   int sd;
-  guint8 *buf;
--- End diff --

"buf" is not used anywhere in thrift_socket.c and it was marked as private. 
 This means it was there for no reason that's useful.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server/crosstest mu...

2017-02-21 Thread jeking3
Github user jeking3 commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102356989
  
--- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_socket.h ---
@@ -50,11 +50,8 @@ struct _ThriftSocket
 
   /* private */
   gchar *hostname;
-  gshort port;
+  guint port;
   int sd;
-  guint8 *buf;
--- End diff --

"buf" is not used anywhere in thrift_socket.c and it was marked as private. 
 This means it was there for no reason that's useful.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server/crosstest mu...

2017-02-21 Thread jeking3
Github user jeking3 commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102356814
  
--- Diff: lib/c_glib/src/thrift/c_glib/protocol/thrift_protocol.c ---
@@ -61,15 +61,15 @@ thrift_protocol_set_property (GObject *object, guint 
property_id,
   switch (property_id)
   {
 case PROP_THRIFT_PROTOCOL_TRANSPORT:
-  protocol->transport = g_value_get_object (value);
--- End diff --

"should" live as long.  Why should we impose a requirement that the 
consuming application, using an object oriented-ish language like glib, be 
required to ensure the underlying transport outlives the protocol that is 
consuming it?

The copy should not lead to memory issues because the dispose method in 
this class unreferences and clears the pointer.  This means the consuming 
application does a g_object_new, that's one reference.  The protocol consumes 
it, that's a second reference.  If the consuming application were to unref the 
transport, it would crash.  But by using reference counts on objects the way 
they were intended to be used, a consuming application could quite literally 
unref everything but the server before serve() and then unref the server when 
it returns, and there would be no leaks or problems.  I don't think it's a good 
practice to force the consuming application to guarantee the lifetime of 
pointers that reference each-other when the object library itself provides 
reference counting and garbage collection.  That's why I changed it here and in 
other classes like ThriftServer.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102356814
  
--- Diff: lib/c_glib/src/thrift/c_glib/protocol/thrift_protocol.c ---
@@ -61,15 +61,15 @@ thrift_protocol_set_property (GObject *object, guint 
property_id,
   switch (property_id)
   {
 case PROP_THRIFT_PROTOCOL_TRANSPORT:
-  protocol->transport = g_value_get_object (value);
--- End diff --

"should" live as long.  Why should we impose a requirement that the 
consuming application, using an object oriented-ish language like glib, be 
required to ensure the underlying transport outlives the protocol that is 
consuming it?

The copy should not lead to memory issues because the dispose method in 
this class unreferences and clears the pointer.  This means the consuming 
application does a g_object_new, that's one reference.  The protocol consumes 
it, that's a second reference.  If the consuming application were to unref the 
transport, it would crash.  But by using reference counts on objects the way 
they were intended to be used, a consuming application could quite literally 
unref everything but the server before serve() and then unref the server when 
it returns, and there would be no leaks or problems.  I don't think it's a good 
practice to force the consuming application to guarantee the lifetime of 
pointers that reference each-other when the object library itself provides 
reference counting and garbage collection.  That's why I changed it here and in 
other classes like ThriftServer.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-4031) Go plugin generates invalid code for lists of typedef'ed built-in types

2017-02-21 Thread Can Celasun (JIRA)

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

Can Celasun commented on THRIFT-4031:
-

[~jensg] that commit was a while ago, but do you remember why that was 
necessary? Maybe it can be reverted?

> Go plugin generates invalid code for lists of typedef'ed built-in types
> ---
>
> Key: THRIFT-4031
> URL: https://issues.apache.org/jira/browse/THRIFT-4031
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Thrift version 0.10.0
> go version go1.7.4 linux/386
>Reporter: Benoit Sigoure
>Priority: Critical
>
> Reproduction:
> {code}
> mkdir /tmp/bug
> cd /tmp/bug
> cat >test.thrift < typedef i32 foo
> struct s {
>  1:list a
> }
> EOF
> mkdir _build
> thrift -out _build --gen go:package=pkg -r test.thrift
> {code}
> Then try to compile the resulting {{go build _build/pkg/test.go}} and you'll 
> get:
> {code}
> _build/pkg/test.go:81: cannot use _elem0 (type int32) as type Foo in append
> {code}
> Here's the generated code with line numbers and a couple comments I added:
> {code}
>  67 func (p *S)  ReadField1(iprot thrift.TProtocol) error {
>  68   _, size, err := iprot.ReadListBegin()
>  69   if err != nil {
>  70 return thrift.PrependError("error reading list begin: ", err)
>  71   }
>  72   tSlice := make([]Foo, 0, size)  // The slice contain Foo values
>  73   p.A =  tSlice
>  74   for i := 0; i < size; i ++ {
>  75 var _elem0 int32
>  76 if v, err := iprot.ReadI32(); err != nil {
>  77 return thrift.PrependError("error reading field 0: ", err)
>  78 } else {
>  79 _elem0 = v
>  80 }
>  81 p.A = append(p.A, _elem0)  // Here the code should do append(p.A, 
> Foo(_elem0))
>  82   }
>  83   if err := iprot.ReadListEnd(); err != nil {
>  84 return thrift.PrependError("error reading list end: ", err)
>  85   }
>  86   return nil
>  87 }
> {code}
> This was working fine with 0.9.3 so this is a regression in 0.10.0.  With 
> 0.9.3 the slice {{tSlice}} is a {{[]int32}}, as opposed to a {{[]Foo}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-4031) Go plugin generates invalid code for lists of typedef'ed built-in types

2017-02-21 Thread Benoit Sigoure (JIRA)

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

Benoit Sigoure commented on THRIFT-4031:


For the example {{.thrift}} file that I provided, the code compile fines before 
this commit, but breaks after that commit.  I imagine the commit intended to 
fix something but broke something else in the process.

> Go plugin generates invalid code for lists of typedef'ed built-in types
> ---
>
> Key: THRIFT-4031
> URL: https://issues.apache.org/jira/browse/THRIFT-4031
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Thrift version 0.10.0
> go version go1.7.4 linux/386
>Reporter: Benoit Sigoure
>Priority: Critical
>
> Reproduction:
> {code}
> mkdir /tmp/bug
> cd /tmp/bug
> cat >test.thrift < typedef i32 foo
> struct s {
>  1:list a
> }
> EOF
> mkdir _build
> thrift -out _build --gen go:package=pkg -r test.thrift
> {code}
> Then try to compile the resulting {{go build _build/pkg/test.go}} and you'll 
> get:
> {code}
> _build/pkg/test.go:81: cannot use _elem0 (type int32) as type Foo in append
> {code}
> Here's the generated code with line numbers and a couple comments I added:
> {code}
>  67 func (p *S)  ReadField1(iprot thrift.TProtocol) error {
>  68   _, size, err := iprot.ReadListBegin()
>  69   if err != nil {
>  70 return thrift.PrependError("error reading list begin: ", err)
>  71   }
>  72   tSlice := make([]Foo, 0, size)  // The slice contain Foo values
>  73   p.A =  tSlice
>  74   for i := 0; i < size; i ++ {
>  75 var _elem0 int32
>  76 if v, err := iprot.ReadI32(); err != nil {
>  77 return thrift.PrependError("error reading field 0: ", err)
>  78 } else {
>  79 _elem0 = v
>  80 }
>  81 p.A = append(p.A, _elem0)  // Here the code should do append(p.A, 
> Foo(_elem0))
>  82   }
>  83   if err := iprot.ReadListEnd(); err != nil {
>  84 return thrift.PrependError("error reading list end: ", err)
>  85   }
>  86   return nil
>  87 }
> {code}
> This was working fine with 0.9.3 so this is a regression in 0.10.0.  With 
> 0.9.3 the slice {{tSlice}} is a {{[]int32}}, as opposed to a {{[]Foo}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (THRIFT-4090) compile error with array of alias in golang

2017-02-21 Thread Can Celasun (JIRA)

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

Can Celasun closed THRIFT-4090.
---
Resolution: Duplicate

Duplicate of [THRIFT-4031|https://issues.apache.org/jira/browse/THRIFT-4031].

> compile error with array of alias in golang
> ---
>
> Key: THRIFT-4090
> URL: https://issues.apache.org/jira/browse/THRIFT-4090
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: mac sierra latest
>Reporter: Yi Zheng
>
> This case works well under 0.9.3 but not in 0.10.0
> -aaa.thrift
> typedef i64 SomeStruct
> -bbb.thrift
> include "aaa.thrift"
> struct AnotherStruct {
> 1: required list another_struct;
> }
> ==
> I read the compiled code, there will be code in "ReadFieldX" function like:
> for i := 0; i < size; i ++ {
> var _elem0 int64
> if v, err := iprot.ReadI64(); err != nil {
> return thrift.PrependError("error reading field 0: ", err)
> } else {
> _elem0 = v
> }
> p.EswLinkList = append(p.EswLinkList, _elem0)  // <= compilation 
> error here!
>   }
> However, it is not allowed to append a int64 to an array of int64's alias.
> But this works in 0.9.3, I don't know whether this is an expected behavior?
> Thanks very much!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-4031) Go plugin generates invalid code for lists of typedef'ed built-in types

2017-02-21 Thread Can Celasun (JIRA)

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

Can Celasun commented on THRIFT-4031:
-

Seems this was intentional: 
https://github.com/apache/thrift/commit/12d430e723b020f7a8ce42a40c19edf88f948367

Does it compile fine if you revert that commit?

> Go plugin generates invalid code for lists of typedef'ed built-in types
> ---
>
> Key: THRIFT-4031
> URL: https://issues.apache.org/jira/browse/THRIFT-4031
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Thrift version 0.10.0
> go version go1.7.4 linux/386
>Reporter: Benoit Sigoure
>Priority: Critical
>
> Reproduction:
> {code}
> mkdir /tmp/bug
> cd /tmp/bug
> cat >test.thrift < typedef i32 foo
> struct s {
>  1:list a
> }
> EOF
> mkdir _build
> thrift -out _build --gen go:package=pkg -r test.thrift
> {code}
> Then try to compile the resulting {{go build _build/pkg/test.go}} and you'll 
> get:
> {code}
> _build/pkg/test.go:81: cannot use _elem0 (type int32) as type Foo in append
> {code}
> Here's the generated code with line numbers and a couple comments I added:
> {code}
>  67 func (p *S)  ReadField1(iprot thrift.TProtocol) error {
>  68   _, size, err := iprot.ReadListBegin()
>  69   if err != nil {
>  70 return thrift.PrependError("error reading list begin: ", err)
>  71   }
>  72   tSlice := make([]Foo, 0, size)  // The slice contain Foo values
>  73   p.A =  tSlice
>  74   for i := 0; i < size; i ++ {
>  75 var _elem0 int32
>  76 if v, err := iprot.ReadI32(); err != nil {
>  77 return thrift.PrependError("error reading field 0: ", err)
>  78 } else {
>  79 _elem0 = v
>  80 }
>  81 p.A = append(p.A, _elem0)  // Here the code should do append(p.A, 
> Foo(_elem0))
>  82   }
>  83   if err := iprot.ReadListEnd(); err != nil {
>  84 return thrift.PrependError("error reading list end: ", err)
>  85   }
>  86   return nil
>  87 }
> {code}
> This was working fine with 0.9.3 so this is a regression in 0.10.0.  With 
> 0.9.3 the slice {{tSlice}} is a {{[]int32}}, as opposed to a {{[]Foo}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102329070
  
--- Diff: 
lib/c_glib/src/thrift/c_glib/protocol/thrift_multiplexed_protocol.c ---
@@ -42,146 +41,119 @@ static GParamSpec 
*thrift_multiplexed_protocol_obj_properties[PROP_THRIFT_MULTIP
 
 gint32
 thrift_multiplexed_protocol_write_message_begin (ThriftMultiplexedProtocol 
*protocol,
-   const gchar *name, const ThriftMessageType message_type,
-   const gint32 seqid, GError **error)
+const gchar *name, const ThriftMessageType message_type,
+const gint32 seqid, GError **error)
 {
-   gint32 ret;
-   gchar *service_name = NULL;
-   g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
+  gint32 ret;
+  gchar *service_name = NULL;
+  g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
 
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL 
(protocol);
-   ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
-   ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
+  ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (protocol);
+  ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
+  ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
 
-   if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
-   service_name = g_strdup_printf("%s%s%s", self->service_name, 
self->separator, name);
+  if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
+service_name = g_strdup_printf("%s%s%s", self->service_name, 
THRIFT_MULTIPLEXED_PROTOCOL_DEFAULT_SEPARATOR, name);
+  }else{
+service_name = g_strdup(name);
+  }
 
-   }else{
-   service_name = g_strdup(name);
-   }
+  // relay to the protocol_decorator
+  ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
 
-   // relay to the protocol_decorator
-   ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
+  g_free(service_name);
 
-   g_free(service_name);
-
-   return ret;
+  return ret;
 }
 
 
-
-
 static void
 thrift_multiplexed_protocol_set_property (GObject  *object,
-   guint property_id,
-   const GValue *value,
-   GParamSpec   *pspec)
+guint property_id,
+const GValue *value,
+GParamSpec   *pspec)
 {
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (object);
-
-   switch (property_id)
-   {
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SERVICE_NAME:
-   if(self->service_name!=NULL)
-   g_free (self->service_name);
-   self->service_name= g_value_dup_string (value);
-   break;
-
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SEPARATOR:
--- End diff --

Suppose a protocol or transport that add a separator to the packet to, for 
example, add a header of encryption. And the separator is the same. It may be 
confused because found twice, once for the protocol and another for the 
multiplexed. Changing the multiplexed separator will fix the possible issue. 


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server multiplexed ...

2017-02-21 Thread gadLinux
Github user gadLinux commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102329070
  
--- Diff: 
lib/c_glib/src/thrift/c_glib/protocol/thrift_multiplexed_protocol.c ---
@@ -42,146 +41,119 @@ static GParamSpec 
*thrift_multiplexed_protocol_obj_properties[PROP_THRIFT_MULTIP
 
 gint32
 thrift_multiplexed_protocol_write_message_begin (ThriftMultiplexedProtocol 
*protocol,
-   const gchar *name, const ThriftMessageType message_type,
-   const gint32 seqid, GError **error)
+const gchar *name, const ThriftMessageType message_type,
+const gint32 seqid, GError **error)
 {
-   gint32 ret;
-   gchar *service_name = NULL;
-   g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
+  gint32 ret;
+  gchar *service_name = NULL;
+  g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
 
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL 
(protocol);
-   ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
-   ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
+  ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (protocol);
+  ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
+  ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
 
-   if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
-   service_name = g_strdup_printf("%s%s%s", self->service_name, 
self->separator, name);
+  if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
+service_name = g_strdup_printf("%s%s%s", self->service_name, 
THRIFT_MULTIPLEXED_PROTOCOL_DEFAULT_SEPARATOR, name);
+  }else{
+service_name = g_strdup(name);
+  }
 
-   }else{
-   service_name = g_strdup(name);
-   }
+  // relay to the protocol_decorator
+  ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
 
-   // relay to the protocol_decorator
-   ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
+  g_free(service_name);
 
-   g_free(service_name);
-
-   return ret;
+  return ret;
 }
 
 
-
-
 static void
 thrift_multiplexed_protocol_set_property (GObject  *object,
-   guint property_id,
-   const GValue *value,
-   GParamSpec   *pspec)
+guint property_id,
+const GValue *value,
+GParamSpec   *pspec)
 {
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (object);
-
-   switch (property_id)
-   {
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SERVICE_NAME:
-   if(self->service_name!=NULL)
-   g_free (self->service_name);
-   self->service_name= g_value_dup_string (value);
-   break;
-
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SEPARATOR:
--- End diff --

Suppose a protocol or transport that add a separator to the packet to, for 
example, add a header of encryption. And the separator is the same. It may be 
confused because found twice, once for the protocol and another for the 
multiplexed. Changing the multiplexed separator will fix the possible issue. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102328202
  
--- Diff: lib/java/test/org/apache/thrift/test/TestServer.java ---
@@ -190,7 +193,9 @@ public static void main(String [] args) {
 if (protocol_type.equals("binary")) {
 } else if (protocol_type.equals("compact")) {
 } else if (protocol_type.equals("json")) {
-} else if (protocol_type.equals("multiplexed")) {
+} else if (protocol_type.equals("multi")) {
--- End diff --

I don't know much about tests. But you can get crazy here if there's a lot 
of procotols. 
I suggest what I did. Adding a prefix and sufix. The prefix can be matched 
against multiplexed (multi) the suffix is the name of the protocol of the 
underlaying implementation. 
This convention doesn't add anything to the code. And makes you be ready 
for the multiplexed whether a new protocol is added with no effort. 
Convention over configuration.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102326459
  
--- Diff: lib/c_glib/src/thrift/c_glib/protocol/thrift_protocol.c ---
@@ -549,12 +549,27 @@ thrift_protocol_init (ThriftProtocol *protocol)
 }
 
 static void
+thrift_protocol_dispose (GObject *gobject)
+{
+  ThriftProtocol *self = THRIFT_PROTOCOL (gobject);
+
+  g_clear_object(>transport);
+
+  /* Always chain up to the parent class; there is no need to check if
+   * the parent class implements the dispose() virtual function: it is
+   * always guaranteed to do so
+   */
+  G_OBJECT_CLASS (thrift_protocol_parent_class)->dispose(gobject);
--- End diff --

Yes I forgot that! Sorry.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102325143
  
--- Diff: 
lib/c_glib/src/thrift/c_glib/protocol/thrift_multiplexed_protocol.c ---
@@ -42,146 +41,119 @@ static GParamSpec 
*thrift_multiplexed_protocol_obj_properties[PROP_THRIFT_MULTIP
 
 gint32
 thrift_multiplexed_protocol_write_message_begin (ThriftMultiplexedProtocol 
*protocol,
-   const gchar *name, const ThriftMessageType message_type,
-   const gint32 seqid, GError **error)
+const gchar *name, const ThriftMessageType message_type,
+const gint32 seqid, GError **error)
 {
-   gint32 ret;
-   gchar *service_name = NULL;
-   g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
+  gint32 ret;
+  gchar *service_name = NULL;
+  g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
 
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL 
(protocol);
-   ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
-   ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
+  ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (protocol);
+  ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
+  ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
 
-   if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
-   service_name = g_strdup_printf("%s%s%s", self->service_name, 
self->separator, name);
+  if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
+service_name = g_strdup_printf("%s%s%s", self->service_name, 
THRIFT_MULTIPLEXED_PROTOCOL_DEFAULT_SEPARATOR, name);
+  }else{
+service_name = g_strdup(name);
+  }
 
-   }else{
-   service_name = g_strdup(name);
-   }
+  // relay to the protocol_decorator
+  ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
 
-   // relay to the protocol_decorator
-   ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
+  g_free(service_name);
 
-   g_free(service_name);
-
-   return ret;
+  return ret;
 }
 
 
-
-
 static void
 thrift_multiplexed_protocol_set_property (GObject  *object,
-   guint property_id,
-   const GValue *value,
-   GParamSpec   *pspec)
+guint property_id,
+const GValue *value,
+GParamSpec   *pspec)
 {
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (object);
-
-   switch (property_id)
-   {
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SERVICE_NAME:
-   if(self->service_name!=NULL)
-   g_free (self->service_name);
-   self->service_name= g_value_dup_string (value);
-   break;
-
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SEPARATOR:
--- End diff --

Why you did remove the ability to select the separator. It seems that Java 
and maybe others support it. Think that some protocols may required to change 
it to something special to make it work. I would leave it.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102326623
  
--- Diff: lib/c_glib/src/thrift/c_glib/server/thrift_server.c ---
@@ -76,22 +76,22 @@ thrift_server_set_property (GObject *object, guint 
property_id,
   switch (property_id)
   {
 case PROP_THRIFT_SERVER_PROCESSOR:
-  server->processor = g_value_get_object (value);
--- End diff --

Same here. Are you sure you must duplicate them?


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server multiplexed ...

2017-02-21 Thread gadLinux
Github user gadLinux commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102326459
  
--- Diff: lib/c_glib/src/thrift/c_glib/protocol/thrift_protocol.c ---
@@ -549,12 +549,27 @@ thrift_protocol_init (ThriftProtocol *protocol)
 }
 
 static void
+thrift_protocol_dispose (GObject *gobject)
+{
+  ThriftProtocol *self = THRIFT_PROTOCOL (gobject);
+
+  g_clear_object(>transport);
+
+  /* Always chain up to the parent class; there is no need to check if
+   * the parent class implements the dispose() virtual function: it is
+   * always guaranteed to do so
+   */
+  G_OBJECT_CLASS (thrift_protocol_parent_class)->dispose(gobject);
--- End diff --

Yes I forgot that! Sorry.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102327046
  
--- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_socket.h ---
@@ -50,11 +50,8 @@ struct _ThriftSocket
 
   /* private */
   gchar *hostname;
-  gshort port;
+  guint port;
   int sd;
-  guint8 *buf;
--- End diff --

This is the default implementation of the socket. Are you sure about it? If 
this is changed I suppose this should be done in it's own ticket.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server multiplexed ...

2017-02-21 Thread gadLinux
Github user gadLinux commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102328202
  
--- Diff: lib/java/test/org/apache/thrift/test/TestServer.java ---
@@ -190,7 +193,9 @@ public static void main(String [] args) {
 if (protocol_type.equals("binary")) {
 } else if (protocol_type.equals("compact")) {
 } else if (protocol_type.equals("json")) {
-} else if (protocol_type.equals("multiplexed")) {
+} else if (protocol_type.equals("multi")) {
--- End diff --

I don't know much about tests. But you can get crazy here if there's a lot 
of procotols. 
I suggest what I did. Adding a prefix and sufix. The prefix can be matched 
against multiplexed (multi) the suffix is the name of the protocol of the 
underlaying implementation. 
This convention doesn't add anything to the code. And makes you be ready 
for the multiplexed whether a new protocol is added with no effort. 
Convention over configuration.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


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

https://github.com/apache/thrift/pull/1200#discussion_r102326250
  
--- Diff: lib/c_glib/src/thrift/c_glib/protocol/thrift_protocol.c ---
@@ -61,15 +61,15 @@ thrift_protocol_set_property (GObject *object, guint 
property_id,
   switch (property_id)
   {
 case PROP_THRIFT_PROTOCOL_TRANSPORT:
-  protocol->transport = g_value_get_object (value);
--- End diff --

Why you duplicate it? The underlaying transport should live as long as the 
multiplexed one. And must be destroyed after protocol is destroyed. Duplicating 
the transport may lead to object references hold and maybe memory freeing 
problems. 
I think this property must hold a reference to it and not a copy. 
The copy can lead to memory freeing problems.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server multiplexed ...

2017-02-21 Thread gadLinux
Github user gadLinux commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102327046
  
--- Diff: lib/c_glib/src/thrift/c_glib/transport/thrift_socket.h ---
@@ -50,11 +50,8 @@ struct _ThriftSocket
 
   /* private */
   gchar *hostname;
-  gshort port;
+  guint port;
   int sd;
-  guint8 *buf;
--- End diff --

This is the default implementation of the socket. Are you sure about it? If 
this is changed I suppose this should be done in it's own ticket.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server multiplexed ...

2017-02-21 Thread gadLinux
Github user gadLinux commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102326250
  
--- Diff: lib/c_glib/src/thrift/c_glib/protocol/thrift_protocol.c ---
@@ -61,15 +61,15 @@ thrift_protocol_set_property (GObject *object, guint 
property_id,
   switch (property_id)
   {
 case PROP_THRIFT_PROTOCOL_TRANSPORT:
-  protocol->transport = g_value_get_object (value);
--- End diff --

Why you duplicate it? The underlaying transport should live as long as the 
multiplexed one. And must be destroyed after protocol is destroyed. Duplicating 
the transport may lead to object references hold and maybe memory freeing 
problems. 
I think this property must hold a reference to it and not a copy. 
The copy can lead to memory freeing problems.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server multiplexed ...

2017-02-21 Thread gadLinux
Github user gadLinux commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102326623
  
--- Diff: lib/c_glib/src/thrift/c_glib/server/thrift_server.c ---
@@ -76,22 +76,22 @@ thrift_server_set_property (GObject *object, guint 
property_id,
   switch (property_id)
   {
 case PROP_THRIFT_SERVER_PROCESSOR:
-  server->processor = g_value_get_object (value);
--- End diff --

Same here. Are you sure you must duplicate them?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] thrift pull request #1200: THRIFT-3706: glib client/java server multiplexed ...

2017-02-21 Thread gadLinux
Github user gadLinux commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1200#discussion_r102325143
  
--- Diff: 
lib/c_glib/src/thrift/c_glib/protocol/thrift_multiplexed_protocol.c ---
@@ -42,146 +41,119 @@ static GParamSpec 
*thrift_multiplexed_protocol_obj_properties[PROP_THRIFT_MULTIP
 
 gint32
 thrift_multiplexed_protocol_write_message_begin (ThriftMultiplexedProtocol 
*protocol,
-   const gchar *name, const ThriftMessageType message_type,
-   const gint32 seqid, GError **error)
+const gchar *name, const ThriftMessageType message_type,
+const gint32 seqid, GError **error)
 {
-   gint32 ret;
-   gchar *service_name = NULL;
-   g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
+  gint32 ret;
+  gchar *service_name = NULL;
+  g_return_val_if_fail (THRIFT_IS_MULTIPLEXED_PROTOCOL (protocol), -1);
 
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL 
(protocol);
-   ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
-   ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
+  ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (protocol);
+  ThriftMultiplexedProtocolClass *multiplexClass = 
THRIFT_MULTIPLEXED_PROTOCOL_GET_CLASS(self);
+  ThriftProtocolClass *cls = THRIFT_PROTOCOL_CLASS (multiplexClass);
 
-   if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
-   service_name = g_strdup_printf("%s%s%s", self->service_name, 
self->separator, name);
+  if( (message_type == T_CALL || message_type == T_ONEWAY) && 
self->service_name != NULL) {
+service_name = g_strdup_printf("%s%s%s", self->service_name, 
THRIFT_MULTIPLEXED_PROTOCOL_DEFAULT_SEPARATOR, name);
+  }else{
+service_name = g_strdup(name);
+  }
 
-   }else{
-   service_name = g_strdup(name);
-   }
+  // relay to the protocol_decorator
+  ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
 
-   // relay to the protocol_decorator
-   ret = thrift_protocol_decorator_write_message_begin(protocol, 
service_name, message_type, seqid, error);
+  g_free(service_name);
 
-   g_free(service_name);
-
-   return ret;
+  return ret;
 }
 
 
-
-
 static void
 thrift_multiplexed_protocol_set_property (GObject  *object,
-   guint property_id,
-   const GValue *value,
-   GParamSpec   *pspec)
+guint property_id,
+const GValue *value,
+GParamSpec   *pspec)
 {
-   ThriftMultiplexedProtocol *self = THRIFT_MULTIPLEXED_PROTOCOL (object);
-
-   switch (property_id)
-   {
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SERVICE_NAME:
-   if(self->service_name!=NULL)
-   g_free (self->service_name);
-   self->service_name= g_value_dup_string (value);
-   break;
-
-   case PROP_THRIFT_MULTIPLEXED_PROTOCOL_SEPARATOR:
--- End diff --

Why you did remove the ability to select the separator. It seems that Java 
and maybe others support it. Think that some protocols may required to change 
it to something special to make it work. I would leave it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Assigned] (THRIFT-4011) Sets of Thrift structs generate Go code that can't be serialized to JSON

2017-02-21 Thread Jens Geyer (JIRA)

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

Jens Geyer reassigned THRIFT-4011:
--

Assignee: Can Celasun

> Sets of Thrift structs generate Go code that can't be serialized to JSON
> 
>
> Key: THRIFT-4011
> URL: https://issues.apache.org/jira/browse/THRIFT-4011
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: Can Celasun
>Assignee: Can Celasun
> Fix For: 0.11.0
>
>
> Consider the following structs:
> {code}
> struct Foo {
>   1: optional string foo
> }
> struct Bar {
>   1: optional set foos
> }
> {code}
> This compiles into the following Go code:
> {code}
> type Bar struct {
>   Foos map[*Foo]struct{} `thrift:"foos,1" db:"foos" json:"foos,omitempty"`
> }
> {code}
> Even though the generated code has tags for JSON support, Bar can't be 
> serialized to JSON:
> {code}
> json: unsupported type: map[*Foo]struct {}
> {code}
> One solution would be to use slices, not maps, for Thrift sets. Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-4011) Sets of Thrift structs generate Go code that can't be serialized to JSON

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-4011:


Github user asfgit closed the pull request at:

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


> Sets of Thrift structs generate Go code that can't be serialized to JSON
> 
>
> Key: THRIFT-4011
> URL: https://issues.apache.org/jira/browse/THRIFT-4011
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: Can Celasun
>
> Consider the following structs:
> {code}
> struct Foo {
>   1: optional string foo
> }
> struct Bar {
>   1: optional set foos
> }
> {code}
> This compiles into the following Go code:
> {code}
> type Bar struct {
>   Foos map[*Foo]struct{} `thrift:"foos,1" db:"foos" json:"foos,omitempty"`
> }
> {code}
> Even though the generated code has tags for JSON support, Bar can't be 
> serialized to JSON:
> {code}
> json: unsupported type: map[*Foo]struct {}
> {code}
> One solution would be to use slices, not maps, for Thrift sets. Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1156: THRIFT-4011 Use slices for Thrift sets

2017-02-21 Thread asfgit
Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] thrift pull request #1201: THRIFT-4076: appveyor needs to pick up PATH chang...

2017-02-21 Thread jeking3
GitHub user jeking3 opened a pull request:

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

THRIFT-4076: appveyor needs to pick up PATH changes and JAVA_HOME from the 
registry 

after using chocolatey to install ant (and jdk, which it depends on) we 
need to refresh the environment

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

$ git pull https://github.com/jeking3/thrift THRIFT-4076

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

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


commit 8a3b8318d18296f56a1dfe1d6be22b58098d38c7
Author: James E. King, III 
Date:   2017-02-21T21:18:11Z

THRIFT-4076: pick up PATH changes and JAVA_HOME from the registry after 
using chocolatey to install ant (and jdk, which it depends on)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-4076) Appveyor builds failing because ant 1.9.8 was removed from apache servers

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-4076:


GitHub user jeking3 opened a pull request:

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

THRIFT-4076: appveyor needs to pick up PATH changes and JAVA_HOME from the 
registry 

after using chocolatey to install ant (and jdk, which it depends on) we 
need to refresh the environment

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

$ git pull https://github.com/jeking3/thrift THRIFT-4076

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

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


commit 8a3b8318d18296f56a1dfe1d6be22b58098d38c7
Author: James E. King, III 
Date:   2017-02-21T21:18:11Z

THRIFT-4076: pick up PATH changes and JAVA_HOME from the registry after 
using chocolatey to install ant (and jdk, which it depends on)




> Appveyor builds failing because ant 1.9.8 was removed from apache servers
> -
>
> Key: THRIFT-4076
> URL: https://issues.apache.org/jira/browse/THRIFT-4076
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appyevor CI
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Blocker
> Fix For: 0.11.0
>
>
> ant was upgraded to 1.9.9 and broke our build
> I am going to switch it over to using chocolatey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1200
  
Build failure attributed to the fix for THRIFT-4076.  I reopened it, I will 
submit a PR for that and make sure it works, and then rebase this one to fix 
the Appveyor issue.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift issue #1200: THRIFT-3706: glib client/java server multiplexed improve...

2017-02-21 Thread jeking3
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1200
  
Build failure attributed to the fix for THRIFT-4076.  I reopened it, I will 
submit a PR for that and make sure it works, and then rebase this one to fix 
the Appveyor issue.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Reopened] (THRIFT-4076) Appveyor builds failing because ant 1.9.8 was removed from apache servers

2017-02-21 Thread James E. King, III (JIRA)

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

James E. King, III reopened THRIFT-4076:


I need to reopen this as it caused a build failure:

https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/build/1042

{noformat}
appveyor-retry cinst -y ant
Chocolatey v0.10.3
Installing the following packages:
ant
By installing you accept licenses for the packages.
jdk8 v8.0.121 [Approved]
jdk8 package files install completed. Performing other installation steps.
Downloading JDK from 
http://download.oracle.com/otn-pub/java/jdk/8u121-b13/e9e7ea248e2c4826b92b3f075a80e441/jdk-8u121-windows-x64.exe
Installing jdk8...
jdk8 has been installed.
PATH environment variable does not have C:\Program Files\Java\jdk1.8.0_121\bin 
in it. Adding...
Environment Vars (like PATH) have changed. Close/reopen your shell to
 see the changes (or in powershell/cmd.exe just type `refreshenv`).
 The install of jdk8 was successful.
  Software installed as 'exe', install location is likely default.
{noformat}

Followed by:

{noformat}
InitializeBuildStatus:
  Creating "x64\Release\ThriftJava\ThriftJava.tlog\unsuccessfulbuild" because 
"AlwaysCreate" was specified.
CustomBuild:
  Building Custom Rule C:/projects/thrift/lib/java/CMakeLists.txt
  CMake does not need to re-run because 
C:\projects\thrift\cmake-build\lib\java\CMakeFiles\generate.stamp is up-to-date.
  Generating libthrift-1.0.0.jar, libthrift-1.0.0.pom
  '"java.exe"' is not recognized as an internal or external command,
  operable program or batch file.
C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error 
MSB6006: "cmd.exe" exited with code 9009. 
[C:\projects\thrift\cmake-build\lib\java\ThriftJava.vcxproj]
Done Building Project 
"C:\projects\thrift\cmake-build\lib\java\ThriftJava.vcxproj" (default targets) 
-- FAILED.
{noformat}

It looks like the appveyor script needs "refreshenv".

> Appveyor builds failing because ant 1.9.8 was removed from apache servers
> -
>
> Key: THRIFT-4076
> URL: https://issues.apache.org/jira/browse/THRIFT-4076
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appyevor CI
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Blocker
> Fix For: 0.11.0
>
>
> ant was upgraded to 1.9.9 and broke our build
> I am going to switch it over to using chocolatey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1199
  
@gadLinux if you could review PR #1200 I would appreciate it.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift issue #1199: THRIFT-3706 - Implement multiplex protocol and crosstest...

2017-02-21 Thread jeking3
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1199
  
@gadLinux if you could review PR #1200 I would appreciate it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library

2017-02-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3706:


Github user gadLinux commented on the issue:

https://github.com/apache/thrift/pull/1199
  
Greta, tell me if you need something from me.


> There's no support for Multiplexed protocol on c_glib library
> -
>
> Key: THRIFT-3706
> URL: https://issues.apache.org/jira/browse/THRIFT-3706
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Library
>Affects Versions: 0.9.3
>Reporter: Gonzalo Aguilar
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift issue #1199: THRIFT-3706 - Implement multiplex protocol and crosstest...

2017-02-21 Thread gadLinux
Github user gadLinux commented on the issue:

https://github.com/apache/thrift/pull/1199
  
Greta, tell me if you need something from me.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---