Daniel Henninger - 01/11/08 11:28 AM I'm not following this exactly. Why would multiple external components be allowed to connect to the same JVM? In part of the description here, it sounds like what you really want is the ability for the same external component JID to connect to multiple nodes in a cluster. In other words, given that you have ext1, ext2, and ext3 for external components, and node1, node2, and node3 for cluster nodes. It's not that you want ext1, ext2, and ext3 to all be able to connect to node1, but rather you want ext1 to connect to node1, ext2 to connect to node2, and ext3 to connect to node3. Is this correct?

Daniel Henninger - 01/14/08 03:46 PM Per our conversation: (1:23 PM) Gato: we already support external components connecting to different cluster nodes (1:23 PM) Gato: to some or all (1:24 PM) Gato: but that is not the issue (1:24 PM) Gato: this is the problem: CS may be running in a clluster and OF may not (1:24 PM) Gato: so lets say that we have more CS JVMs than OF JVMs (1:24 PM) Gato: in that case you will have a N-1 relationship from CS to OF (1:24 PM) Gato: so that means that a single OF JVM will get connections from several CS JVMs (1:25 PM) Daniel: all at the same component id?? (1:25 PM) Gato: that is why we need to allow some external components to connect to the same JVM from several places (1:25 PM) Gato: iow, allow several sockeet connections (1:25 PM) Daniel: how will it know how to route things? (1:25 PM) Gato: round robin (1:26 PM) Gato: if the same external component is connecting many times (1:26 PM) Gato: then it is expected for that external component to wiork in a cluster mode (1:26 PM) Daniel: let me look at this from a different type of external component perspective (1:26 PM) Daniel: pyicq-t (1:26 PM) Daniel: connects and takes over icq.example.org (1:27 PM) Daniel: 3 more pyicq-t's connection and also use icq.example.org (1:27 PM) Daniel: user a connects, pyicq-t #1 gets the connection, logs the user on (1:27 PM) Daniel: if we simply round robin .. next message coming through could go to pyicq-t #2 which doesn't have the user's session (1:27 PM) Gato: yes (1:28 PM) Gato: that is why this should be done only for components that can handle this (1:28 PM) Gato: I was thinking of adding some hint in the initial XML sent from the component to the server (1:29 PM) Daniel: so maybe it's not something the server admin can configure? (1:29 PM) Gato: that was what I thought when I checked the code in OF (1:29 PM) Gato: well, we can go that road or the XML road (1:29 PM) Daniel: the component itself tells openfire "hey yo i can connect multiple times to this, bow to me" (1:29 PM) Gato: yes, that was my initial intention (1:29 PM) Daniel: i feel semi-strongly that we shouldn't have it in the admin interface (1:29 PM) Gato: but the XEP114 is not that flexible (1:30 PM) Daniel: i think it would get very confusing to server admins that don't know what they are doing (1:30 PM) Daniel: oh great i can connection 32 pyicq-ts! (1:30 PM) Gato: since the requested domain goes in the initial stream header (1:30 PM) Daniel: hey why isn't this working? (1:30 PM) Gato: if we make it in the XML then admins cannot screw it (1:30 PM) Gato: if we let admins configure it from the admin console they can let pyicq connect many times and break it