Re: No "Receive Application Task Message"

[杨江骅]

Hi，Arsen：
    I have upgrade unimrcp to 0.8.0, and do my stress tests again. But the problem does still exist!
So can you give me more advice to slove this problem?
 

    PS:my new log is following.

[Arsen Chaloyan]

Hi,

Make sure you're not blocking in callbacks raised from client stack or
mpf layer.

Pay attention to what mrcp_application_channel_add() returns.
If it returns FALSE, most probably message queue which stores
application requests is full.
If it returns TRUE, but there is no further processing, most probably
client stack is locked.

There were similar problem, where message queue in mpf layer was
getting full, but this issue has been fixed.

Finally, what you application did when it received the following message.
2009-11-07 10:16:21:448756 [INFO] Receive MRCPv2 Stream
192.168.1.107:54326 <-> 192.168.1.109:5070 [202 bytes]
MRCP/2.0 000000202 RECOGNITION-COMPLETE 2 COMPLETE
Channel-Identifier: 6d0a070a022b@speechrecog
Completion-Cause: 15 no-match-maxtime
Completion-Reason: "recognize failure of recognition timeout"

Thereafter MRCP server terminated the session (I assume the session timed out)
2009-11-07 10:17:45:698869 [NOTICE] SIP Call State 0x8c45d0 [terminated]
2009-11-07 10:17:45:698888 [DEBUG] Signal Signaling Task Message
2009-11-07 10:25:22:832820 [INFO] TCP/MRCPv2 Peer Disconnected
192.168.1.107:54320 <-> 192.168.1.109:5070
2009-11-07 10:25:22:832903 [DEBUG] Signal Connection Task Message

So provide the information I requested first, then if needed, I'll add
more debug output to see what is going on.

--
Arsen Chaloyan
The author of UniMRCP
http://www.unimrcp.org

[spirit_only]

Sorry, Arsen. I have to deal with something orther those days. See my
answer blow.

On Nov 8, 2:42 pm, Arsen Chaloyan <achalo...@gmail.com> wrote:
> Hi,
>
> Make sure you're not blocking in callbacks raised from client stack or
> mpf layer.

I check my code again, I am not sure that there is any block in my
callbacks, but it seems not now.

>
> Pay attention to what mrcp_application_channel_add() returns.
> If it returns FALSE, most probably message queue which stores
> application requests is full.
> If it returns TRUE, but there is no further processing, most probably
> client stack is locked.

I make sure that it returns TRUE and the messae queue is not full. I
check my other log and print the message queue length,
the message queue begin to increase when the problem start.

>
> There were similar problem, where message queue in mpf layer was
> getting full, but this issue has been fixed.
>
> Finally, what you application did when it received the following message.
> 2009-11-07 10:16:21:448756 [INFO]   Receive MRCPv2 Stream
> 192.168.1.107:54326 <-> 192.168.1.109:5070 [202 bytes]
> MRCP/2.0 000000202 RECOGNITION-COMPLETE 2 COMPLETE
> Channel-Identifier: 6d0a070a022b@speechrecog
> Completion-Cause: 15 no-match-maxtime
> Completion-Reason: "recognize failure of recognition timeout"

I call "mrcp_application_channel_remove(session, channel)" after the
recogniztion-complete and
in my "recog_application_on_channel_remove" function I call
"mrcp_application_session_terminate"
to terminate the session. Then in my
"recog_application_on_session_terminate" function I call
"mrcp_application_session_destroy" to destroy the session.

So you can see the below log which the session is been terminated.

I read the mod_mrcp in freeswitch and I doesn't find it remove the
channel and terminate the session
after recognition-complete, so am I wrong?

>
> Thereafter MRCP server terminated the session (I assume the session timed out)
> 2009-11-07 10:17:45:698869 [NOTICE] SIP Call State 0x8c45d0 [terminated]
> 2009-11-07 10:17:45:698888 [DEBUG]  Signal Signaling Task Message
> 2009-11-07 10:25:22:832820 [INFO]   TCP/MRCPv2 Peer Disconnected
> 192.168.1.107:54320 <-> 192.168.1.109:5070
> 2009-11-07 10:25:22:832903 [DEBUG]  Signal Connection Task Message
>
> So provide the information I requested first, then if needed, I'll add
> more debug output to see what is going on.
>

[Arsen Chaloyan]

See my comments below.

On Sat, Nov 14, 2009 at 7:36 AM, spirit_only <spiri...@gmail.com> wrote:
>
> Sorry, Arsen. I have to deal with something orther those days. See my
> answer blow.
>
> On Nov 8, 2:42 pm, Arsen Chaloyan <achalo...@gmail.com> wrote:
>> Hi,
>>
>> Make sure you're not blocking in callbacks raised from client stack or
>> mpf layer.
>
> I check my code again, I am not sure that there is any block in my
> callbacks, but it seems not now.
>
>>
>> Pay attention to what mrcp_application_channel_add() returns.
>> If it returns FALSE, most probably message queue which stores
>> application requests is full.
>> If it returns TRUE, but there is no further processing, most probably
>> client stack is locked.
>
> I make sure that it returns TRUE and the messae queue is not full. I
> check my other log and print the message queue length,
> the message queue begin to increase when the problem start.

It means the core thread of client stack was locked by that time.
I still think callback which raises MRCP messages from client stack to
your application was never returned. I clearly see that this was the
last thing the client stack did, meanwhile other threads such as
Sofia-SIP agent, MRCPv2 connection agent as well as your application
were still alive and were sending messages to client stack.

Anyway, I've added a debug trace, which should help narrow down the problem.
http://code.google.com/p/unimrcp/source/detail?r=1284

You can easily apply this change over the released version you use.

>
>>
>> There were similar problem, where message queue in mpf layer was
>> getting full, but this issue has been fixed.
>>
>> Finally, what you application did when it received the following message.
>> 2009-11-07 10:16:21:448756 [INFO]   Receive MRCPv2 Stream
>> 192.168.1.107:54326 <-> 192.168.1.109:5070 [202 bytes]
>> MRCP/2.0 000000202 RECOGNITION-COMPLETE 2 COMPLETE
>> Channel-Identifier: 6d0a070a022b@speechrecog
>> Completion-Cause: 15 no-match-maxtime
>> Completion-Reason: "recognize failure of recognition timeout"
>
> I call "mrcp_application_channel_remove(session, channel)" after the
> recogniztion-complete and
> in my "recog_application_on_channel_remove" function I call
> "mrcp_application_session_terminate"
> to terminate the session. Then in my
> "recog_application_on_session_terminate" function I call
> "mrcp_application_session_destroy" to destroy the session.

OK

>
> So you can see the below log which the session is been terminated.
>
> I read the mod_mrcp in freeswitch and I doesn't find it remove the
> channel and terminate the session
> after recognition-complete, so am I wrong?

It's not necessary to remove channel first, you can directly terminate
session instead and it will release all allocated resources.

> "mrcp_application_session_terminate"
> to terminate the session. Then in my
> "recog_application_on_session_terminate" function I call
> "mrcp_application_session_destroy" to destroy the session.

>
>>

[spirit_only]

I will add your debug trace to the 0.8.0 unimrcp version this night,
and try again.

Thanks!

> Anyway, I've added a debug trace, which should help narrow down the problem.http://code.google.com/p/unimrcp/source/detail?r=1284

[Arsen Chaloyan]

What is the status of this issue?

7 days and nights have already passed.