[jira] Created: (SYNAPSE-526) Add server connector to make use of existing MBeans
Add server connector to make use of existing MBeans --- Key: SYNAPSE-526 URL: https://issues.apache.org/jira/browse/SYNAPSE-526 Project: Synapse Issue Type: Improvement Affects Versions: 1.2 Reporter: Eric Hubert Priority: Minor Fix For: 1.3 Hi, currently Synapse does not create a JMX server connector to enable the user to make use of the existing MBeans via JConsole or any other JMX-compliant management solution. The attached patch introduces a small JMXAdapter class to create an RMI registry using a specified JNDI port in synapse.properties (synapse.jmx.jndiPort). Only if this port is specified it will create the registry and start the server connector. If the user additionally specifies a fixed RMI port in synapse.properties (synapse.jmx.rmiPort) instead of using a dynamic RMI port Synapse will use the specified port thus allowing a firewalled setup (you have to open both ports in your firewall). The Javadoc of the class explains the connect syntax: service:jmx:rmi:///jndi/rmi://:/synapse or service:jmx:rmi://:/jndi/rmi://:/synapse This patch shall just demonstrate the basic idea. I'm of course willing to contribute further work on this (including documentation). The best place in the startup and shutdown phase of Synapse should be discussed. I'm going to start a separate discussion on the order of actions in the Synapse startup phase anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
startup order - correct place to start transport listeners
Hi all, while working on patch to make direct use of the existing MBeans in Synapse I was wondering about the current order of actions during Synapse startup. If I'm not wrong it looks like the transports are started somewhere in the middle of the Synapse startup. Is this observation correct? Is this on purpose? Too me this looks like a serious error. The listeners should be started only once the whole configuration process has been successfully finished. Otherwise traffic would be accepted even though the initialization of the configuration (proxies, sequences, endpoints and so on) may fail. Here is what I have read from the code (standalone deployment): 1 SynapseServer.main() 1.1 ServerConfigurationInformationFactory.createServerConfigurationInformation(args); 1.2 ServerManager.getInstance(); 1.3 ServerManager.init() 1.3.1 SynapseControllerFactory.createSynapseController(configurationInformation); 1.3.2 ServerManager.doInit() 1.3.2.1 Axis2SynapseController.init() 1.3.2.1.1 Axis2SynapseController.createNewInstance() 1.3.2.1.1.1 Axis2SynapseController.createConfigurationContextFromFileSystem() 1.3.2.1.2 create and Init Listener Manager 1.3.2.1.3 start transports <--- this looks terribly wrong 1.3.2.2 Axis2SynapseController.initDefaults() 1.3.2.2.1 Axis2SynapseController.addDefaultBuildersAndFormatters(configurationContext.getAxisConfiguration()); 1.3.2.2.2 Axis2SynapseController.loadMediatorExtensions(); 1.3.2.2.3 Axis2SynapseController.setupDataSources(); 1.4 ServerManager.start() 1.4.1 ServerManager.assertInitialized() 1.4.2 ServerManager.doInit() 1.4.3 ServerManager.doStart() 1.4.3.1 Axis2SynapseController.createSynapseConfiguration(); 1.4.3.2 Axis2SynapseController.createSynapseEnvironment(); 1.4.3.2.1 Axis2SynapseController.setupSynapse() 1.4.3.2.1.1 Axis2SynapseController.addServerIPAndHostEnrties(); 1.4.3.2.1.2 Axis2SynapseController.setupMainMediation(); 1.4.3.2.1.3 Axis2SynapseController.setupProxyServiceMediation(); 1.4.3.2.1.4 Axis2SynapseController.setupEventSources(); 1.4.3.2.2 SynapseConfiguration.init() --> up to this point a lot of errors can occur resulting in "Synapse startup failed" Why don't we start listeners only if we reach this point without an error? I would propose to start the listeners immediately before the log output: ServerManager - Ready for processing Is there anything which will prevent this to work? If not I would be willing to work on a patch. So far I didn't test those hypotheses, so I may be wrong. Please feel to correct my current understanding! Regards, Eric
[jira] Updated: (SYNAPSE-526) Add server connector to make use of existing MBeans
[ https://issues.apache.org/jira/browse/SYNAPSE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated SYNAPSE-526: Attachment: JmxAdapter.patch > Add server connector to make use of existing MBeans > --- > > Key: SYNAPSE-526 > URL: https://issues.apache.org/jira/browse/SYNAPSE-526 > Project: Synapse > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Eric Hubert >Priority: Minor > Fix For: 1.3 > > Attachments: JmxAdapter.patch > > > Hi, > currently Synapse does not create a JMX server connector to enable the user > to make use of the existing MBeans via JConsole or any other JMX-compliant > management solution. The attached patch introduces a small JMXAdapter class > to create an RMI registry using a specified JNDI port in synapse.properties > (synapse.jmx.jndiPort). Only if this port is specified it will create the > registry and start the server connector. If the user additionally specifies a > fixed RMI port in synapse.properties (synapse.jmx.rmiPort) instead of using a > dynamic RMI port Synapse will use the specified port thus allowing a > firewalled setup (you have to open both ports in your firewall). > The Javadoc of the class explains the connect syntax: > service:jmx:rmi:///jndi/rmi://:/synapse or > service:jmx:rmi://:/jndi/rmi://:/synapse > This patch shall just demonstrate the basic idea. I'm of course willing to > contribute further work on this (including documentation). The best place in > the startup and shutdown phase of Synapse should be discussed. I'm going to > start a separate discussion on the order of actions in the Synapse startup > phase anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
