[jira] [Updated] (THRIFT-5547) C++ - Can't interrupt the handler on the server side while using TMultiplexedProcessor in case of client deconnection
[
https://issues.apache.org/jira/browse/THRIFT-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
julien greard updated THRIFT-5547:
--
Description:
Hello,
I have the following architecture in my code:
* 1 thrift Server
* 1 thrift MultiplexedProcessor
* several Services & associated processors/handlers
* N thrift clients (several by processor/handler)
* 1 queue which contains the tasks asked by the clients
What I*really*want is to be able cancel a task when a client crashes.
Let me explain:
Let's say I have the following service handler method :
|// inside thrift handler
// this method is currently instanciated once and called by every client
void do_stuff(const std::string& parameter) {
auto task = make_task(parameter);
auto future_result = task .get_future();
add_to_queue(task);
auto status = resultFuture.wait_for(timeout); // wait here until the task is
over
if (status != std::future_status::timeout)
{
return future_result.get();
}
}|
If the client crashes/disconnects, there is no need to process with the task
anymore, so I would like to cancel it (remove from my queue) asap.
To do so, I had the following ideas:
1/ Using the*setServerEventHandler*method from my Thrift Server to be notified
when a client disconnects (deleteContext method). It works very well but I am
not able to know which request was made by which specific client: within my
handler I do not have access to the client infos, and I can't use (or didnt
managed to) the void * context created by the method creatContext in my
ServerEventHandler
2/ Using the contructor & destructor of my handler object to link 1 client to 1
handler. Then when the client disconnects, I only have to cancel every task he
asked in the handler destructor. Currently I have N client and 1 handler, so it
doesn't work. I figured I could use a TMultiplexedProcessorFactory but there is
no such class in thrift. The TMultiplexedProcessor has to register Processor
(with single handler) when I'd like to register a Factory which will create one
handler instance by client. I could implement my own
TMultiplexedProcessorFactory but I think there might be a good reason this
doesn't exist yet.
Any idea of what I should do ?
I can post it inhttps://issues.apache.org/but it's not exactly an issue with
thrift (great lib btw), rather than a question.
Thanks in advance, don't hesitate to ask for more details
This post is a duplicate of a StackOverflow question I asked last Friday
[|https://stackoverflow.com/questions/71707726/using-a-processor-factory-with-tmultiplexedprocessor-in-thrift]
Thanks in advance,
Julien Greard
There has been an answer to this request in
[dev@thrift.apache.org|mailto:dev@thrift.apache.org] : the user Yuxuan Wang has
described having the same issue in Go and he solved it by adding a context to
the handler services + a thread watchding regularly the opened sockets
was:
Hello,
I have the following architecture in my code:
* 1 thrift Server
* 1 thrift MultiplexedProcessor
* several Services & associated processors/handlers
* N thrift clients (several by processor/handler)
* 1 queue which contains the tasks asked by the clients
What I*really*want is to be able cancel a task when a client crashes.
Let me explain:
Let's say I have the following service handler method :
|// inside thrift handler // this method is currently instanciated once and
called by every client void do_stuff(const std::string& parameter) \{ auto task
= make_task(parameter); auto future_result = task .get_future();
add_to_queue(task); auto status = resultFuture.wait_for(timeout); // wait here
until the task is over if (status != std::future_status::timeout) { return
future_result.get(); } } |
If the client crashes/disconnects, there is no need to process with the task
anymore, so I would like to cancel it (remove from my queue) asap.
To do so, I had the following ideas:
1/ Using the*setServerEventHandler*method from my Thrift Server to be notified
when a client disconnects (deleteContext method). It works very well but I am
not able to know which request was made by which specific client: within my
handler I do not have access to the client infos, and I can't use (or didnt
managed to) the void * context created by the method creatContext in my
ServerEventHandler
2/ Using the contructor & destructor of my handler object to link 1 client to 1
handler. Then when the client disconnects, I only have to cancel every task he
asked in the handler destructor. Currently I have N client and 1 handler, so it
doesn't work. I figured I could use a TMultiplexedProcessorFactory but there is
no such class in thrift. The TMultiplexedProcessor has to register Processor
(with single handler) when I'd like to register a Factory which
[jira] [Created] (THRIFT-5547) C++ - Can't interrupt the handler on the server side while using TMultiplexedProcessor in case of client deconnection
julien greard created THRIFT-5547:
-
Summary: C++ - Can't interrupt the handler on the server side
while using TMultiplexedProcessor in case of client deconnection
Key: THRIFT-5547
URL: https://issues.apache.org/jira/browse/THRIFT-5547
Project: Thrift
Issue Type: Brainstorming
Components: C++ - Library
Affects Versions: 0.16.0
Reporter: julien greard
Hello,
I have the following architecture in my code:
* 1 thrift Server
* 1 thrift MultiplexedProcessor
* several Services & associated processors/handlers
* N thrift clients (several by processor/handler)
* 1 queue which contains the tasks asked by the clients
What I*really*want is to be able cancel a task when a client crashes.
Let me explain:
Let's say I have the following service handler method :
|// inside thrift handler // this method is currently instanciated once and
called by every client void do_stuff(const std::string& parameter) \{ auto task
= make_task(parameter); auto future_result = task .get_future();
add_to_queue(task); auto status = resultFuture.wait_for(timeout); // wait here
until the task is over if (status != std::future_status::timeout) { return
future_result.get(); } } |
If the client crashes/disconnects, there is no need to process with the task
anymore, so I would like to cancel it (remove from my queue) asap.
To do so, I had the following ideas:
1/ Using the*setServerEventHandler*method from my Thrift Server to be notified
when a client disconnects (deleteContext method). It works very well but I am
not able to know which request was made by which specific client: within my
handler I do not have access to the client infos, and I can't use (or didnt
managed to) the void * context created by the method creatContext in my
ServerEventHandler
2/ Using the contructor & destructor of my handler object to link 1 client to 1
handler. Then when the client disconnects, I only have to cancel every task he
asked in the handler destructor. Currently I have N client and 1 handler, so it
doesn't work. I figured I could use a TMultiplexedProcessorFactory but there is
no such class in thrift. The TMultiplexedProcessor has to register Processor
(with single handler) when I'd like to register a Factory which will create one
handler instance by client. I could implement my own
TMultiplexedProcessorFactory but I think there might be a good reason this
doesn't exist yet.
Any idea of what I should do ?
I can post it inhttps://issues.apache.org/but it's not exactly an issue with
thrift (great lib btw), rather than a question.
Thanks in advance, don't hesitate to ask for more details
This post is a duplicate of a StackOverflow question I asked last Friday
[|https://stackoverflow.com/questions/71707726/using-a-processor-factory-with-tmultiplexedprocessor-in-thrift]
Thanks in advance,
Julien Greard
There has been an answer to this request in
[dev@thrift.apache.org|mailto:dev@thrift.apache.org] : the user Yuxuan Wang has
described having the same issue in Go and he solved it by adding a context to
the handler services + a thread watchding regularly the opened sockets
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076684#comment-16076684
]
julien greard commented on THRIFT-2642:
---
Just did it, looks fine to me
> Recursive structs don't work in python
> --
>
> Key: THRIFT-2642
> URL: https://issues.apache.org/jira/browse/THRIFT-2642
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler, Python - Library
>Affects Versions: 0.9.2
>Reporter: Igor Kostenko
>Assignee: Eric Conner
>
> Recursive structs in 0.9.2 work fine in c++ & c#, but not in python, because
> generated code trying to use objects which not constructed yet.
> Struct:
> {code}
> struct Recursive {
> 1: list Children
> }
> {code}
> Python code:
> {code}
> class Recursive:
> thrift_spec = (
> None, # 0
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> )
> {code}
> Error message:
> {code}
> Traceback (most recent call last):
> File "ttypes.py", line 20, in
> class Recursive:
> File "ttypes.py", line 28, in Recursive
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> NameError: name 'Recursive' is not defined
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075536#comment-16075536
]
julien greard commented on THRIFT-2642:
---
Ok it should be better now !
> Recursive structs don't work in python
> --
>
> Key: THRIFT-2642
> URL: https://issues.apache.org/jira/browse/THRIFT-2642
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler, Python - Library
>Affects Versions: 0.9.2
>Reporter: Igor Kostenko
>Assignee: Eric Conner
>
> Recursive structs in 0.9.2 work fine in c++ & c#, but not in python, because
> generated code trying to use objects which not constructed yet.
> Struct:
> {code}
> struct Recursive {
> 1: list Children
> }
> {code}
> Python code:
> {code}
> class Recursive:
> thrift_spec = (
> None, # 0
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> )
> {code}
> Error message:
> {code}
> Traceback (most recent call last):
> File "ttypes.py", line 20, in
> class Recursive:
> File "ttypes.py", line 28, in Recursive
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> NameError: name 'Recursive' is not defined
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075452#comment-16075452
]
julien greard commented on THRIFT-2642:
---
Ok it's done, do you see my comments/reviews?
> Recursive structs don't work in python
> --
>
> Key: THRIFT-2642
> URL: https://issues.apache.org/jira/browse/THRIFT-2642
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler, Python - Library
>Affects Versions: 0.9.2
>Reporter: Igor Kostenko
>Assignee: Eric Conner
>
> Recursive structs in 0.9.2 work fine in c++ & c#, but not in python, because
> generated code trying to use objects which not constructed yet.
> Struct:
> {code}
> struct Recursive {
> 1: list Children
> }
> {code}
> Python code:
> {code}
> class Recursive:
> thrift_spec = (
> None, # 0
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> )
> {code}
> Error message:
> {code}
> Traceback (most recent call last):
> File "ttypes.py", line 20, in
> class Recursive:
> File "ttypes.py", line 28, in Recursive
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> NameError: name 'Recursive' is not defined
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075429#comment-16075429
]
julien greard commented on THRIFT-2642:
---
Hi,
I'll try a review, but it's my first one on github and I don't know thrift
source code well, so forgive me if I'm wrong ;-)
> Recursive structs don't work in python
> --
>
> Key: THRIFT-2642
> URL: https://issues.apache.org/jira/browse/THRIFT-2642
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler, Python - Library
>Affects Versions: 0.9.2
>Reporter: Igor Kostenko
>Assignee: Eric Conner
>
> Recursive structs in 0.9.2 work fine in c++ & c#, but not in python, because
> generated code trying to use objects which not constructed yet.
> Struct:
> {code}
> struct Recursive {
> 1: list Children
> }
> {code}
> Python code:
> {code}
> class Recursive:
> thrift_spec = (
> None, # 0
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> )
> {code}
> Error message:
> {code}
> Traceback (most recent call last):
> File "ttypes.py", line 20, in
> class Recursive:
> File "ttypes.py", line 28, in Recursive
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> NameError: name 'Recursive' is not defined
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074792#comment-16074792
]
julien greard commented on THRIFT-2642:
---
Hi,
My company uses thrift & python. We use a workaround for the recursive
structures and it's kind of works but I think that's thrift should be
working the same no matter the language (that's the point of thrift I
believe).
In my opinion, there are 3 options:
- disable recursive structures for everyone
- make it work for Python
- live with it as we do for now, but a bug like that shows a bad image and
will possibly make someone who uses thrift switch to another language,
isn't it?
> Recursive structs don't work in python
> --
>
> Key: THRIFT-2642
> URL: https://issues.apache.org/jira/browse/THRIFT-2642
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler, Python - Library
>Affects Versions: 0.9.2
>Reporter: Igor Kostenko
>
> Recursive structs in 0.9.2 work fine in c++ & c#, but not in python, because
> generated code trying to use objects which not constructed yet.
> Struct:
> {code}
> struct Recursive {
> 1: list Children
> }
> {code}
> Python code:
> {code}
> class Recursive:
> thrift_spec = (
> None, # 0
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> )
> {code}
> Error message:
> {code}
> Traceback (most recent call last):
> File "ttypes.py", line 20, in
> class Recursive:
> File "ttypes.py", line 28, in Recursive
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> NameError: name 'Recursive' is not defined
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057106#comment-16057106
]
julien greard commented on THRIFT-2642:
---
Hi
Thanks for the work, I'll have a look this week. I don't know yet how to
review code on JIRA but I'm sure it's well documented.
> Recursive structs don't work in python
> --
>
> Key: THRIFT-2642
> URL: https://issues.apache.org/jira/browse/THRIFT-2642
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler, Python - Library
>Affects Versions: 0.9.2
>Reporter: Igor Kostenko
>
> Recursive structs in 0.9.2 work fine in c++ & c#, but not in python, because
> generated code trying to use objects which not constructed yet.
> Struct:
> {code}
> struct Recursive {
> 1: list Children
> }
> {code}
> Python code:
> {code}
> class Recursive:
> thrift_spec = (
> None, # 0
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> )
> {code}
> Error message:
> {code}
> Traceback (most recent call last):
> File "ttypes.py", line 20, in
> class Recursive:
> File "ttypes.py", line 28, in Recursive
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> NameError: name 'Recursive' is not defined
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
julien greard updated THRIFT-2642:
--
Hello,
I agree with Jens and I'm available for giving my opinion even if I don't
know much about thrift architecture.
Wish you luck !
Julien
> Recursive structs don't work in python
> --
>
> Key: THRIFT-2642
> URL: https://issues.apache.org/jira/browse/THRIFT-2642
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler, Python - Library
>Affects Versions: 0.9.2
>Reporter: Igor Kostenko
>
> Recursive structs in 0.9.2 work fine in c++ & c#, but not in python, because
> generated code trying to use objects which not constructed yet.
> Struct:
> {code}
> struct Recursive {
> 1: list Children
> }
> {code}
> Python code:
> {code}
> class Recursive:
> thrift_spec = (
> None, # 0
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> )
> {code}
> Error message:
> {code}
> Traceback (most recent call last):
> File "ttypes.py", line 20, in
> class Recursive:
> File "ttypes.py", line 28, in Recursive
> (1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
> Recursive.thrift_spec)), None, ), # 1
> NameError: name 'Recursive' is not defined
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635740#comment-14635740
]
julien greard commented on THRIFT-2642:
---
Right now, I have a workaround, I have to edit the generated files by hand.
It's working, but each time I update my objects data structure or create new
ones, I have to do it. I just need to know if this bugs is major enought
according to Thrift community's point of view to be fixed soon for my ^next
developements: I can use recursive data struct if this bug is fixed soon,
otherwise, I'll find another pattern, no worries ^^
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{code}
struct Recursive {
1: listRecursive Children
}
{code}
Python code:
{code}
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Error message:
{code}
Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635029#comment-14635029
]
julien greard commented on THRIFT-2642:
---
Hello,
Do you know if this bug is planned to be corrected soon ? I haven't been able
to do any progress on a patch yet, and I probably won't have the time to look
at it in the next months...
I just need to know if I have to wait for a correction or if I have to get rid
of the recursivity
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{code}
struct Recursive {
1: listRecursive Children
}
{code}
Python code:
{code}
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Error message:
{code}
Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14541728#comment-14541728
]
julien greard commented on THRIFT-2642:
---
Hi,
Thanks for the indication about the formatting,
For the patch, I'll test my solution for a while and I'll look at the python
generator. But I'm not sure I'll be able to make something clean.
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{code}
struct Recursive {
1: listRecursive Children
}
{code}
Python code:
{code}
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Error message:
{code}
Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3147) Segfault while receiving data
[ https://issues.apache.org/jira/browse/THRIFT-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] julien greard resolved THRIFT-3147. --- Resolution: Not A Problem Fix Version/s: 0.9.2 not a bug after all - it was a compilation issue, my compiler was mixing 0.9.1 and 0.9.2 sources... It works well after deleting 0.9.1 sources Segfault while receiving data - Key: THRIFT-3147 URL: https://issues.apache.org/jira/browse/THRIFT-3147 Project: Thrift Issue Type: Bug Components: C++ - Compiler, C++ - Library Affects Versions: 0.9.2 Environment: Ubuntu 12.04 Reporter: julien greard Fix For: 0.9.2 Hello, I'm working on a Thrift Client/Server app for a while. I was working with 0.9.1 successfully and I wanted to try the 0.9.2. I now get a segfault when my client tries to reach the server: Thread [19] 14167 [core: 6] (Suspended : Signal : SIGSEGV:Segmentation fault) apache::thrift::transport::TTransport::readAll() at TTransport.h:126 0x1f4ac60 apache::thrift::protocol::TBinaryProtocolTapache::thrift::transport::TTransport::readI32() at TBinaryProtocol.tcc:375 0x1f63794 apache::thrift::protocol::TBinaryProtocolTapache::thrift::transport::TTransport::readMessageBegin() at TBinaryProtocol.tcc:206 0x1f62fa5 apache::thrift::protocol::TVirtualProtocolapache::thrift::protocol::TBinaryProtocolTapache::thrift::transport::TTransport, apache::thrift::protocol::TProtocolDefaults::readMessageBegin_virt() at TVirtualProtocol.h:432 0x1f61d0e apache::thrift::protocol::TProtocol::readMessageBegin() at TProtocol.h:531 0x26ca66e apache::thrift::TDispatchProcessor::process() at TDispatchProcessor.h:113 0x26cac59 apache::thrift::server::TSimpleServer::serve() at TSimpleServer.cpp:100 0x70cbb714 evitech::ConfigurationThriftServer::open() at ConfigurationThriftServer.cpp:111 0x26c8c0e evitech::DistantConfigurationManager::execute() at DistantConfigurationManager.cpp:62 0x26d22c2 evitech::Task::runOneIteration() at Task.cpp:408 0x26f8eec ...more frames... On the server side, I have a C++ app with (snapshot of code): _processor.reset(new jaguar_configuration::JaguarConfigurationServiceProcessor(_handler)); _protocolFactory.reset(new apache::thrift::protocol::TBinaryProtocolFactory()); _serverTransport.reset(new apache::thrift::transport::TServerSocket(_serverPort)); _transportFactory.reset(new apache::thrift::transport::TBufferedTransportFactory()); _server.reset(new apache::thrift::server::TSimpleServer(_processor, _serverTransport, _transportFactory, _protocolFactory)); _server.serve(); On the client side, I run a python app with: - TSocket - TBufferedTransport - TBinaryProtocol Here is the method I use (idl): void keep_alive(1: string identifier) throws (1:InvalidOperation op), I'm probably doing something wrong, but I've no idea what. I've seen in wireshark that I'm indeed sending the correct data on the correct side. If you need more samples to investigate let me know. What could have changed between 0.9.1 and 0.9.2 that could give me this result ? Thanks in advance, J. Greard -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14539620#comment-14539620
]
julien greard edited comment on THRIFT-2642 at 5/13/15 7:42 AM:
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by (sorry for the bad indent, I don't know how to have a nice display)
{code}
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
was (Author: juliengreard):
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by (sorry for the bad indent, I don't know how to have a nice display)
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{code}
struct Recursive {
1: listRecursive Children
}
{code}
Python code:
{code}
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Error message:
{code}
Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14539620#comment-14539620
]
julien greard edited comment on THRIFT-2642 at 5/13/15 7:42 AM:
I did my own work around:
in the example above, I replaced the code:
{code}
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
by
{code}
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
was (Author: juliengreard):
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by (sorry for the bad indent, I don't know how to have a nice display)
{code}
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{code}
struct Recursive {
1: listRecursive Children
}
{code}
Python code:
{code}
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{code}
Error message:
{code}
Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-3147) Segfault while receiving data
julien greard created THRIFT-3147: - Summary: Segfault while receiving data Key: THRIFT-3147 URL: https://issues.apache.org/jira/browse/THRIFT-3147 Project: Thrift Issue Type: Bug Components: C++ - Compiler, C++ - Library Affects Versions: 0.9.2 Environment: Ubuntu 12.04 Reporter: julien greard Hello, I'm working on a Thrift Client/Server app for a while. I was working with 0.9.1 successfully and I wanted to try the 0.9.2. I now get a segfault when my client tries to reach the server: Thread [19] 14167 [core: 6] (Suspended : Signal : SIGSEGV:Segmentation fault) apache::thrift::transport::TTransport::readAll() at TTransport.h:126 0x1f4ac60 apache::thrift::protocol::TBinaryProtocolTapache::thrift::transport::TTransport::readI32() at TBinaryProtocol.tcc:375 0x1f63794 apache::thrift::protocol::TBinaryProtocolTapache::thrift::transport::TTransport::readMessageBegin() at TBinaryProtocol.tcc:206 0x1f62fa5 apache::thrift::protocol::TVirtualProtocolapache::thrift::protocol::TBinaryProtocolTapache::thrift::transport::TTransport, apache::thrift::protocol::TProtocolDefaults::readMessageBegin_virt() at TVirtualProtocol.h:432 0x1f61d0e apache::thrift::protocol::TProtocol::readMessageBegin() at TProtocol.h:531 0x26ca66e apache::thrift::TDispatchProcessor::process() at TDispatchProcessor.h:113 0x26cac59 apache::thrift::server::TSimpleServer::serve() at TSimpleServer.cpp:100 0x70cbb714 evitech::ConfigurationThriftServer::open() at ConfigurationThriftServer.cpp:111 0x26c8c0e evitech::DistantConfigurationManager::execute() at DistantConfigurationManager.cpp:62 0x26d22c2 evitech::Task::runOneIteration() at Task.cpp:408 0x26f8eec ...more frames... On the server side, I have a C++ app with (snapshot of code): _processor.reset(new jaguar_configuration::JaguarConfigurationServiceProcessor(_handler)); _protocolFactory.reset(new apache::thrift::protocol::TBinaryProtocolFactory()); _serverTransport.reset(new apache::thrift::transport::TServerSocket(_serverPort)); _transportFactory.reset(new apache::thrift::transport::TBufferedTransportFactory()); _server.reset(new apache::thrift::server::TSimpleServer(_processor, _serverTransport, _transportFactory, _protocolFactory)); _server.serve(); On the client side, I run a python app with: - TSocket - TBufferedTransport - TBinaryProtocol Here is the method I use (idl): void keep_alive(1: string identifier) throws (1:InvalidOperation op), I'm probably doing something wrong, but I've no idea what. I've seen in wireshark that I'm indeed sending the correct data on the correct side. If you need more samples to investigate let me know. What could have changed between 0.9.1 and 0.9.2 that could give me this result ? Thanks in advance, J. Greard -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14539620#comment-14539620
]
julien greard edited comment on THRIFT-2642 at 5/12/15 10:14 AM:
-
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
was (Author: juliengreard):
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{quote}struct Recursive {
1: listRecursive Children
}
{quote}
Python code:
{quote}class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{quote}
An error:
{quote}Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14539620#comment-14539620
]
julien greard edited comment on THRIFT-2642 at 5/12/15 10:14 AM:
-
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by (sorry for the bad indent, I don't know how to have a nice display)
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
was (Author: juliengreard):
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{quote}struct Recursive {
1: listRecursive Children
}
{quote}
Python code:
{quote}class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{quote}
An error:
{quote}Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14539620#comment-14539620
]
julien greard commented on THRIFT-2642:
---
I did my own work around:
in the example above, I replaced the code:
class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
by
class Recursive:
pass
Recursive.thrift_spec = None
depth = 0
max_depth = 50
while (depth max_depth):
depth += 1
Recursive. thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
Which seems to do the job... It's ugly because I have to edit the generated
code afterward, but I didn't want to touch at the code generator in Thrift
code... what do you think ?
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{quote}struct Recursive {
1: listRecursive Children
}
{quote}
Python code:
{quote}class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{quote}
An error:
{quote}Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2642) Recursive structs don't work in python
[
https://issues.apache.org/jira/browse/THRIFT-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14539571#comment-14539571
]
julien greard commented on THRIFT-2642:
---
Hello,
Is there a work around for this bug ? Do you know when it's going to be fixed ?
Thanks
Recursive structs don't work in python
--
Key: THRIFT-2642
URL: https://issues.apache.org/jira/browse/THRIFT-2642
Project: Thrift
Issue Type: Bug
Components: Python - Compiler, Python - Library
Affects Versions: 0.9.2
Reporter: Igor Kostenko
Recursive structs in 0.9.2 work fine in c++ c#, but not in python, because
generated code trying to use objects which not constructed yet.
Struct:
{quote}struct Recursive {
1: listRecursive Children
}
{quote}
Python code:
{quote}class Recursive:
thrift_spec = (
None, # 0
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
)
{quote}
An error:
{quote}Traceback (most recent call last):
File ttypes.py, line 20, in module
class Recursive:
File ttypes.py, line 28, in Recursive
(1, TType.LIST, 'Children', (TType.STRUCT,(Recursive,
Recursive.thrift_spec)), None, ), # 1
NameError: name 'Recursive' is not defined
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-2573) thrift 0.9.2 release
julien greard created THRIFT-2573: - Summary: thrift 0.9.2 release Key: THRIFT-2573 URL: https://issues.apache.org/jira/browse/THRIFT-2573 Project: Thrift Issue Type: Question Affects Versions: 0.9.2 Reporter: julien greard Hello, I need to use recursive struct in Thrift. I saw that the next release will allow this functionality (see link below) but I can't see if this version is going to be released soon or not. Would you have the information ? Is there any stable enough version I could use in the meantime? Thanks ! Link to the feature : https://issues.apache.org/jira/browse/THRIFT-2421 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814746#comment-13814746 ] julien greard commented on THRIFT-2243: --- here are the logs from thrift: TNonblockingServer: Serving on port 9090, 1 io threads. TNonblockingServer: using libevent 2.0.16-stable method epoll TNonblocking: IO thread #0 registered for listen. TNonblocking: IO thread #0 registered for notify. TNonblockingServer: IO thread #0 entering loop... Unexpected Socket State 32754 I'm looking at the TestServer.cpp now TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.8, 0.9.1 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker Labels: nonblocking Fix For: 0.9.2 This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814048#comment-13814048 ] julien greard commented on THRIFT-2243: --- Thanks for your answers @Ben: I tried that, it's not working. The pb is indeed not on the client side I believe as I'm just opening a socket... TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.8, 0.9.1 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker Labels: nonblocking Fix For: 0.9.2 This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809473#comment-13809473 ] julien greard commented on THRIFT-2243: --- Yep, the problem is exactly on this line...more exactly on line 442 switch (socketState_) the value of socketState_ according to gdb is 32767 (?!) and not SOCKET_RECV_FRAMING, SOCKET_RECV or SOCKET_SEND. TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.8, 0.9.1 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker Labels: nonblocking Fix For: 0.9.2 This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] julien greard updated THRIFT-2243: -- Fix Version/s: (was: 0.9.1) TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Affects Versions: 0.8, 0.9.1 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808573#comment-13808573 ] julien greard commented on THRIFT-2243: --- Thanks first for this answer. No, what I meant was: it's working with both TSimpleServer on C++ and a TBufferedTransport on the client side and it's not working with the couple : TNonblockingServer (server side) / TFramedTransport (client side). TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Affects Versions: 0.8, 0.9.1 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
julien greard created THRIFT-2243: - Summary: TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Affects Versions: 0.9.1, 0.8 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] julien greard updated THRIFT-2243: -- Description: This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side was: I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side
[jira] [Resolved] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] julien greard resolved THRIFT-2243. --- Resolution: Fixed Fix Version/s: 0.9.1 TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Affects Versions: 0.8, 0.9.1 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker Fix For: 0.9.1 This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (THRIFT-2243) TNonblockingServer in thrift crashes when TFramedTransport opens
[ https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] julien greard reopened THRIFT-2243: --- issue wrongly closed TNonblockingServer in thrift crashes when TFramedTransport opens Key: THRIFT-2243 URL: https://issues.apache.org/jira/browse/THRIFT-2243 Project: Thrift Issue Type: Bug Affects Versions: 0.8, 0.9.1 Environment: Ubuntu 12.04 Reporter: julien greard Priority: Blocker Fix For: 0.9.1 This bug is also a question on StackOverflow, the code extracts are easier to read here : http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens I've been trying to implement a thrift server in C++ to communicate with a Python client. here is my code: C++ server: shared_ptrThriftHandler _handler (new myHandler()); shared_ptrTProcessor _processor (new myService(_handler)); shared_ptrTProtocolFactory _protocolFactory (new TBinaryProtocolFactory()); shared_ptrThreadManager _threadManager = ThreadManager::newSimpleThreadManager(15); shared_ptrPosixThreadFactory _threadFactory(new PosixThreadFactory()); _threadManager-threadFactory(_threadFactory); _threadManager-start(); shared_ptrTNonblockingServer _server(new TNonblockingServer(_processor, _protocolFactory, 9090 ,_threadManager));; _server-serve(); Python Client code: transport = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(transport) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = MyService.Client(protocol) transport.open() log.info(connection success!) When I start the server and then the client, I get the following: On the client side (Python): ./myPythonExec.py connection success! socket.error: [Errno 104] Connection reset by peer On the server side (c++): assertion 0 failed 0 0x70942425 in __GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 1 0x70945b8b in __GI_abort () at abort.c:91 2 0x7093b0ee in __assert_fail_base (fmt=optimized out, assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=optimized out, function=optimized out) at assert.c:94 3 0x7093b192 in __GI___assert_fail (assertion=0x71438f1a 0, file=0x71439298 src/server/TNonblockingServer.cpp, line=558, function=0x71439c60 void apache::thrift::server::TNonblockingServer::TConnection::workSocket()) at assert.c:103 4 0x714336e4 in apache::thrift::server::TNonblockingServer::TConnection::workSocket (this=0x7fffc0004ac0) at src/server/TNonblockingServer.cpp:558 5 0x711ed94c in event_base_loop () from /usr/lib/libevent-2.0.so.5 I've tested this bug on thrift 0.8.0 and 0.9.1 It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport on the client side -- This message was sent by Atlassian JIRA (v6.1#6144)
