[IPython-dev] Two frontends, one kernel

[MinRK]

ROUTER sockets use an IDENTITY prefix to determine who the recipient should
be. In an IPython message, this would be the frames prior to the
'<IDS|MSG>' delimiter. You must send these as the beginning of the reply in
order for the reply to arrive at the correct peer.

-MinRK


On Thu, May 1, 2014 at 1:24 PM, Doug Blank <doug.blank at gmail.com> wrote:

> On Thu, May 1, 2014 at 4:01 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>> All of those DEALER sockets should be ROUTER sockets. The DEALER behavior
>> is correct for only one peer, but it will round-robin replies if there is
>> more than one.
>>
>
> If I change the ShellChannel to ROUTER then the kernel will no longer
> respond.
>
> If I change the others to ROUTER, then I don't see a difference with prior
> behavior.
>
>
>
>>  Clearly some documentation is wrong. Where did you get the suggestion
>> that they should be DEALER sockets?
>>
>
> Probably a combination of finding what would work, and looking at other
> code (it is sometimes hard to translate code and docs between different ZMQ
> libraries).
>
> Thank you for helping me track this down!
>
> -Doug
>
>
>>
>> -MinRK
>>
>>
>> On Thu, May 1, 2014 at 12:45 PM, Doug Blank <doug.blank at gmail.com> wrote:
>>
>>> On Thu, May 1, 2014 at 2:37 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>
>>>> What are your socket types on the Kernel side?
>>>>
>>>
>>> Here is the definitions for our channels:
>>>
>>>     public class ShellChannel : Channel {
>>>     base(session, auth, transport, address, port, SocketType.DEALER) {
>>>             }
>>>     }
>>> public class IOPubChannel : Channel {
>>>     base(session, auth, transport, address, port, SocketType.PUB) {
>>>             }
>>>     }
>>> public class ControlChannel : Channel {
>>>     base(session, auth, transport, address, port, SocketType.DEALER) {
>>>             }
>>>     }
>>> public class StdInChannel : Channel {
>>>     base(session, auth, transport, address, port, SocketType.DEALER) {
>>>             }
>>>     }
>>> public class HeartBeatChannel : Channel {
>>>      base(session, auth, transport, address, port, SocketType.REP) {
>>>             }
>>>     }
>>>
>>> Could that really effect multi-frontend, but not single?
>>>
>>> -Doug
>>>
>>>
>>>
>>>>
>>>>
>>>> On Thu, May 1, 2014 at 9:58 AM, Doug Blank <doug.blank at gmail.com>wrote:
>>>>
>>>>> Devs, I have been trying to find the cause of this bug for some time,
>>>>> and I thought that someone might be able to provide a hint as to where to
>>>>> look to find the issue.
>>>>>
>>>>> We have an external kernel that works very well when you connect onto
>>>>> it with a single frontend. But when you connect two frontends (console or
>>>>> notebook), then the conversation gets confused.
>>>>>
>>>>> More detail:
>>>>>
>>>>> Terminal 1:
>>>>>
>>>>> ipython console --profile calico
>>>>>
>>>>> works fine.
>>>>>
>>>>> Terminal 2:
>>>>>
>>>>> ipython console --profile calico --existing
>>>>>
>>>>> starts, but now things are confused. Now, each terminal takes turns
>>>>> being able to get the prompt. If run in notebook, then code execution never
>>>>> signals the end of computing (the [*] never turns to a number, but you can
>>>>> still enter and get results back). In the console, output is received, but
>>>>> the prompt is in the other terminal.
>>>>>
>>>>> It works fine with a single front end.
>>>>>
>>>>> Any ideas appreciated!
>>>>>
>>>>> -Doug
>>>>>
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140501/160a0975/attachment.html>