Controller's execution env

[alesj]

In order to implement concurrent deployments handling (https://jira.jboss.org/jira/browse/JBMICROCONT-265)
we need some sort of execution environment (EE) to be passed to Controller:
- https://jira.jboss.org/jira/browse/JBMICROCONT-323

The question is, what how should this interface look like?

Should we take the run operations from our ThreadPool:

 /**
 * Run a task wrapper
 *
 * @param wrapper the task wrapper
 */
 public void runTaskWrapper(TaskWrapper wrapper);

 /**
 * Run a task
 *
 * @param task the task
 * @throws IllegalArgumentException for a null task
 */
 public void runTask(Task task);

 /**
 * Run a runnable
 *
 * @param runnable the runnable
 * @throws IllegalArgumentException for a null runnable
 */
 public void run(Runnable runnable);

 /**
 *
 * @param runnable
 * @param startTimeout
 * @param completeTimeout
 */
 public void run(Runnable runnable, long startTimeout, long completeTimeout);

Or perhaps just the last two, making EE not depend on JBoss Common-core?
But since we already do depend on Common core, we can probably leave the Task and TaskWrapper there as well.

[adrian.brock]

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.

The default implementation should just be to execute() on the same thread.

The main issue is introducing some kind of security as to who can change
the executor implementation.

[adrian.brock]

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.

I meant controller. ;-)

[alesj]

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.

I meant controller. ;-)

Do we even need a getExecutor method?

public interface Controller extends JBossInterface
{
 ...

 /**
 * Get the executor
 *
 * @return the executor
 */
 Executor getExecutor();

 /**
 * Set the executor
 *
 * @param executor the executor
 */
 void setExecutor(Executor executor);
}

Allowing some other MC code to re-use Controller's execution env?

[adrian.brock]

"alesj" wrote:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.

I meant controller. ;-)

Do we even need a getExecutor method?

public interface Controller extends JBossInterface
{
 ...

 /**
 * Get the executor
 *
 * @return the executor
 */
 Executor getExecutor();

 /**
 * Set the executor
 *
 * @param executor the executor
 */
 void setExecutor(Executor executor);
}

Allowing some other MC code to re-use Controller's execution env?

I'd include the getter, subject to the same security check as invoking the setter.
Otherwise somebody could do:

@Inject(...from the controller...)
public void setExectuor(Executor ex)
{
 // Fill the queue with tasks that don't end, a denial of service attack
 while(true)
 {
 ex.execute(new Runnable()
 {
 public void run()
 {
 // sleep forever
 }
 }
}

[alesj]

@Inject(...from the controller...)
public void setExectuor(Executor ex)

Controller will inject itself with its Executor? :-)

Currently we don't handle MC core objects
as MC's contexts, only as KernelRegistryEntry.

But looking at its impl, BeanKernelRegistryEntry,
looks like we might even inject something into the entry
via some factory.

[adrian.brock]

You just use the kernel as a factory to create a seperate context
that references the controller. Then you change whatever parameters you like
(subject to security).

<bean name="ReferenceToController">
 <constructor>
 <factory bean="jboss.kernel:service=Kernel"
 method="getController"/>
 </constructor>
 <property name="executor"><inject bean="CustomExecutor"/></property>
...
</bean>

That's why I said that it is probably not required to be on the interface,
except that it would make programmatic config easier (e.g. testing)
if you don't have to cast/know the implementation detail.

[alesj]

You just use the kernel as a factory to create a seperate context
that references the controller. Then you change whatever parameters you like
(subject to security).

<bean name="ReferenceToController">
 <constructor>
 <factory bean="jboss.kernel:service=Kernel"
 method="getController"/>
 </constructor>
 <property name="executor"><inject bean="CustomExecutor"/></property>
...
</bean>

That's what I said:

"alesj" wrote:

looks like we might even inject something into the entry
via some factory

;-)

But this wasn't doable until we added BeanKernelRegistryEntry and
actually made it implement InvokeDispatchContext.

That's why I said that it is probably not required to be on the interface,
except that it would make programmatic config easier (e.g. testing)
if you don't have to cast/know the implementation detail.

I'll leave it on the interface - as you said, programmatic usage is much simpler - while it also makes sense as a spi contract.
e.g. Controller has an execution environment ~ executor

[alesj]

"alesj" wrote:

I'll leave it on the interface - as you said, programmatic usage is much simpler - while it also makes sense as a spi contract.
e.g. Controller has an execution environment ~ executor

Or perhaps we could move these

 /**
 * Whether the controller is shutdown
 *
 * @return true when shutdown
 */
 boolean isShutdown();

 /**
 * Shutdown the controller
 */
 void shutdown();

 /**
 * Get the executor
 *
 * @return the executor
 */
 Executor getExecutor();

 /**
 * Set the executor
 *
 * @param executor the executor
 */
 void setExecutor(Executor executor);

methods into sub interface.
As they seem to fit the same way we did with MainDeployer and DeployerClient.

[alesj]

"alesj" wrote:

"alesj" wrote:

I'll leave it on the interface - as you said, programmatic usage is much simpler - while it also makes sense as a spi contract.
e.g. Controller has an execution environment ~ executor

Or perhaps we could move these
methods into sub interface.
As they seem to fit the same way we did with MainDeployer and DeployerClient.

Hmmm, looking it this way.
It now feels more as an impl detail. :-)