[Design the new POJO MicroContainer] - Parallel deployments
by kabir.khan＠jboss.com
I've started taking a look at parallel deployments. My initial idea was to wrap the full install process in a separate thread, by modifying the following method in AbstractController
| protected void install(ControllerContext context, boolean trace) throws Throwable
| {
| boolean asynch = false;
| if (context.getMode() == ControllerMode.ASYNCHRONOUS)
| {
| if (executor != null)
| {
| ControllerContextTask task = new InstallControllerContextTask(context, trace);
| executor.execute(task);
| asynch = true;
| }
| else
| {
| log.warn("Uninstalling a context with ControllerMode.ASYNCHRONOUS but no executor in controller: " + context);
| }
| }
|
| if (!asynch)
| {
| internalInstall(context, trace);
| }
| }
|
| private void internalInstall(ControllerContext context, boolean trace) throws Throwable
| {
| //Original contents of install(ControllerContext, boolean)
| }
|
| abstract class ControllerContextTask implements Runnable
| {
| ControllerContext context;
| boolean trace;
|
| public ControllerContextTask(ControllerContext context, boolean trace)
| {
| this.context = context;
| this.trace = trace;
| }
|
| public ControllerContext getControllerContext()
| {
| return context;
| }
| }
|
| class InstallControllerContextTask extends ControllerContextTask
| {
| public InstallControllerContextTask(ControllerContext context, boolean trace)
| {
| super(context, trace);
| }
|
| public void run()
| {
| try
| {
| System.out.println(Thread.currentThread().getName() + " starting " + context.getName() + "==================");
| internalInstall(context, trace);
| System.out.println(Thread.currentThread().getName() + " called internalInstall" + "==================");
| }
| catch (Throwable e)
| {
| log.error("Problem installing context asynchronously " + context);
| }
| }
| }
|
However, this "does not work". In my tests I am deploying two ControllerContexts with ControllerMode.ASYNCHRONOUS, using custom ControllerContext and ControllerContextActions implementations, where I am sleeping for a long time upon entry to the different states, and found that only one thread gets access to this at one time. My initial thoughts were that there must be something wrong with the read/write locks, but they are fine.
I also added some output to this method which I use below
| protected boolean resolveContexts(ControllerState fromState, ControllerState toState, boolean trace)
| {
| ...
| if (resolved.isEmpty() == false)
| {
| for (ControllerContext context : resolved)
| {
| ...
| else if (installing.add(context) == false)
| {
| System.out.println(Thread.currentThread().getName() + " already installed " + context.getName() + "!!!!!!!!!!!!!!!!!");
| if (trace)
| log.trace("Already installing " + name + " for " + toState.getStateString());
| }
| else
| {
| System.out.println(Thread.currentThread().getName() + " adding to installing " + context.getName() + "!!!!!!!!!!!!!!!!!");
| toProcess.add(context);
| }
| }
| try
| {
| if (toProcess.isEmpty() == false)
| {
| for (Iterator<ControllerContext> iter = toProcess.iterator(); iter.hasNext(); )
| {
| try
| {
| ...
| }
| finally
| {
| installing.remove(context);
| System.out.println(Thread.currentThread().getName() + " remove from installing " + context.getName() + "!!!!!!!!!!!!!!!!!");
| }
| }
| }
| }
| finally
| {
| ...
| }
| }
|
What is actually happening is that both threads start up:
| 1 DEBUG [AsynchronousTestCase] ==== setUp org.jboss.test.dependency.controller.test.AsynchronousTestCase ====
| 37 DEBUG [AsynchronousTestCase] ==== Starting testTwoAsynchronousContexts ====
| pool-1-thread-1 starting Bean1==================
| pool-1-thread-2 starting Bean2==================
|
but one of these wins in adding the beans to AbstractController.installing in resolveContexts()
| pool-1-thread-2 adding to installing Bean2!!!!!!!!!!!!!!!!!
| pool-1-thread-2 adding to installing Bean1!!!!!!!!!!!!!!!!!
|
Meaning the other thread has nothing to install, and completes
| pool-1-thread-1 already installed Bean1!!!!!!!!!!!!!!!!!
| pool-1-thread-1 already installed Bean2!!!!!!!!!!!!!!!!!
| pool-1-thread-1 called internalInstall==================
|
The only remaining thread then takes over and installs both beans sequentially:
| pool-1-thread-2 remove from installing Bean2!!!!!!!!!!!!!!!!!
| pool-1-thread-2 remove from installing Bean1!!!!!!!!!!!!!!!!!
| pool-1-thread-2 adding to installing Bean2!!!!!!!!!!!!!!!!!
| pool-1-thread-2 adding to installing Bean1!!!!!!!!!!!!!!!!!
| pool-1-thread-2 Bean2 sleeping 4000
| Finished sleeping
| pool-1-thread-2 Bean2 sleeping 100
| pool-1-thread-2 Bean2 sleeping 300
| Bean2 enters DESCRIBE 1
| pool-1-thread-2 remove from installing Bean2!!!!!!!!!!!!!!!!!
| pool-1-thread-2 remove from installing Bean2!!!!!!!!!!!!!!!!!
| pool-1-thread-2 Bean1 sleeping 300
| Bean1 enters DESCRIBE 2
| pool-1-thread-2 remove from installing Bean1!!!!!!!!!!!!!!!!!
| ....
|
Next, rather than trying to parallelize the whole install sequence, I thought it might make more sense to target when the context is due to enter a state. My understanding is that this is for beans that have heavy initialization (e.g. JGroups), so the important part will be invoking the ControllerContextAction which in turn may invoke create(), start(), install() etc., i tried something like:
| protected void install(ControllerContext context, ControllerState fromState, ControllerState toState) throws Throwable
| {
| ...
| //Check ControllerMode and run in executor if ASYNCHRONOUS
| context.install(fromState, toState);
| }
|
|
However, this fails since if for example the DESCRIBE phase takes 20 seconds, the executor will return right away and the controller will enter the next state, meaning that if there are no sleeps in the INSTANTIATE, CONFIGURE, CREATE, START and INSTALLED states, they could complete before the DESCRIBE phase. There is a fair bit of housekeeping stuff going on following the call to context.install() which gets confused when I do it this way.
Finally, I have had some success with a revised version of the first version, where I modify the InstallControllerContextTask to record the contexts being installed against the executor thread being used, and checking in resolveContexts (where it is doing the 'installing' check) to see if the context being installed should be managed by the current thread. I will need to investigate a bit more though, since I think there might be some problems if an asynchronous context is being installed and lacking dependencies that come from another asynchronous context or an automatic context (done in main thread). I'll post some more about that once I see what happens.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238009#4238009
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238009
16 years, 9 months
[Design of Management Features on JBoss] - Re: ManagedObject interface for AS ChannelFactory
by bstansberry＠jboss.com
The protocolStackConfigurations property is a property of the ChannelFactory itself. Simple way to think about it is it represents the data structure that is created when a -stacks.xml is parsed. By writing to that property, a tool can update the configs that will be used for *future* channel creation.
The protocolStackConfiguration property is a piece of read-only information about a running Channel, gotten to indirectly via the openChannels property of the ChannelFactory. It shows actual configuration of the channel.
Stack name isn't a property of a protocol stack configuration because
1) A minor reason is a protocol stack configuration doesn't necessarily have an associated stack_name, since the ChannelFactory exposes an API to create channels from other config resources besides the configs parsed from -stacks.xml. I.e. you can pass in the config directly to createChannel(Object).
2) the type that represents the protocol stack configuration is CollectionMetaValue. It represents org.jgroups.conf.ProtocolData[]. The data structure is essentially an array and has no place for a stack_name field.
I didn't add a coordinator field to the view because the JGroups View class didn't have one. But, the class javadoc says the first member in the member list is the coordinator, so that's enough of a contract for me to add it. ;) So I will.
Thanks for the link on the JBossHA page!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237970#4237970
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237970
16 years, 9 months
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by tfennelly
Implementation....
Do we want to replicate what was done for EBWS? After all, it's basically the same type of thing! Do we want to consider merging the EBWS and Http Gateway solutions?
The EBWS implementation has EBWS specific code inside the JBoss ESB deployer. I think that's not so great and it hurts me to replicate something like that. Personally I would prefer to see us come up with a better long term solution that doesn't involve implementation specific code inside the deployer class. Kev's ultimate goal is to have all of http related features (EBWS, http listener, webservice proxy etc) build off the same basic solution and have all related http artifacts for a single deployment bundled in a single war sub deployment. Hope my wording makes sense - not Kev's exact words, but I think that's basically what he's after :)
I think this is possible, but not without a new approach. I think trying to do this with the current EBWS impl would just lead to more hacks, which I don't think we're after, right?
So how would we structure the code such that we can keep the deployer clean? I had thinkered with the idea of having a "Bus Deployment Factory" that the main deployer picks up on for creating sub-deployments at deploytime. We can go into that more later if we want to, but what do others think? Do we move the EBWS implementation to use a possible new/refactored approach for 4.6, or do we leave it for now and look to evolve it later, using the new/refactored approach only for the http listener and webservice proxy for now?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237962#4237962
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237962
16 years, 9 months