Davletvm / soashable

Automatically exported from code.google.com/p/soashable
0 stars 0 forks source link

Explore Jive Connection Manager for Scalability #48

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
http://www.igniterealtime.org/projects/openfire/connection_manager.jsp

It seems to ship with an HTTP binding servlet that uses Jetty
continuations. This would alleviate the need to proxy connections to
Openfire, or use JHB.

Original issue reported on code.google.com by h.iver...@gmail.com on 29 Feb 2008 at 11:06

GoogleCodeExporter commented 9 years ago
Source for connection manager v3.4.5 committed in revision 704 with maven 
pom.xml. 
Not enabled as part of Soashable yet.

Original comment by m.purl...@gmail.com on 21 Mar 2008 at 12:00

GoogleCodeExporter commented 9 years ago
Apparently the Servlet constructor requires a session manager to be passed in, 
so it
won't be as simple as dropping it into the webapp. This session manager (from 
what I
hear) does some initialization, including opening ports, etc. 

The Jive connection manager needs to be modified to suit our needs.

Original comment by h.iver...@gmail.com on 27 Mar 2008 at 2:04

GoogleCodeExporter commented 9 years ago
Cmon guys, please solve this issue.
if i was a expert programmer i would have solved it.
best regards

Original comment by theone3...@gmail.com on 9 Apr 2008 at 12:51

GoogleCodeExporter commented 9 years ago
Here is what happens with ConnectionManager. Patch attached is a start of what 
SHOULD
happen. Basically I've start decoupling standalone functionality from
ConnectionManager class and moving it into ServerStarter and 
EmbeddedHttpBindServlet.

ServerStarter.main() loads Jive's classloader and creates a new instance of
ConnectionManager

The constructor of ConnectionManager throws an IllegalStateException if it has 
been
created before. Otherwise it calls ConnectionManager.start()

ConnectionManager.start() calls ConnectionManager.inititalize() and then
ConnectionManager.startModules() if it is not in "setupMode".

ConnectionManager.inititalize() calls ConnectionManager.locateHome(), sets name 
and
serverName properties and adds a shutdown hook if 
ConnectionManager.isStandalone()
returns true. Sets "setupMode" to false if serverName is not null.

ConnectionManager.locateHome() checks for managerHome property, then 
manager_init.xml
from classpath to load that property, them home directory, then dies. Calls
ConnectionManager.verifyHome() on any path it finds.

ConnectionManager.verifyHome() ensures that a config file (conf_manager.xml) 
exists
within directory

ConnectionManager.isStandalone() returns true if ServerStarter exists in the 
class
path. false otherwise.

ConnectionManager.startModules() starts standard, SSL and HTTP binding.

ConnectionManager.startHttpBindServlet() creates a new HttpBindManager and calls
HttpBindManager.startup()

HttpBindManager.startup() creates Jettty connectors, adds a handler created by
HttpBindManager.createServletHandler(), and calls server.start()

HttpBindManager.createServletHandler() creates a new HttpBindServlet and maps 
the
handler to /

Original comment by h.iver...@gmail.com on 16 Apr 2008 at 6:38

Attachments:

GoogleCodeExporter commented 9 years ago
It's semi-functional. It connects, authenticates, and relays the first packet. 
Enough
to authenticate, but not enough to send the initial presence. The response to 
the
first packet is relayed back to the browser.

It's so close. But it's so 2AM and I so have to get up at 7AM :[

Original comment by h.iver...@gmail.com on 23 Apr 2008 at 6:49

GoogleCodeExporter commented 9 years ago
Created a thread in Ignite Realtime forum. Let's see if anyone bites:

http://www.igniterealtime.org/community/thread/32617

Original comment by h.iver...@gmail.com on 28 Apr 2008 at 2:36

GoogleCodeExporter commented 9 years ago
No bites on Ignite Realtime forum. I've dug a little bit more (~30 minutes) and 
found
that the ConnectionManager singleton serves three purposes:

1. read and expose properties (server name, etc)
2. create and hold an instance of ServerSurrogate
3. start client listeners (xmpp, xmpp+ssl, httpbinding)

For our usage, we want to completely ignore #3. The main approaches would be to
either factor that functionality elsewhere through inheritance/delegation, or to
completely refactor the ConnectionManager. Or be completely ghetto and use if
statements. I'd prefer the first option because it won't be much work and it 
won't be
terribly inelegant and probably has the highest probability of being accepted 
as a patch.

Original comment by h.iver...@gmail.com on 4 May 2008 at 3:06