Allow strategy for dempsy to configure out how many logical threads it can alloc to output pool

[bill-tuba]

This does not take into account for hyper threading

It would be nice if DEMPSY could grab as many threads as "it should" when started up on a box.

Right now we can override this directly which is nice but can DEMPSY 'respond' itself to what's available?

So we have this ....

<bean id="myParallelizedOutputExecutor" class="com.nokia.dempsy.output.RelativeOutputSchedule">
    <constructor-arg value="${output.frequency}"/>
    <constructor-arg value="MINUTES"/>
    <property name="concurrency" value="10"/>
</bean>

Could we inject a strategy to have the box help us out?

    <bean id="myParallelizedOutputExecutor" class="com.nokia.dempsy.output.RelativeOutputSchedule">
        <constructor-arg value="${output.frequency}"/>
        <constructor-arg value="MINUTES"/>
        <property name="concurrencyStrategy" ref="findMeSomeThreads"/>
    </bean>


<bead id="findMeSomeThreads" class "MachineBasedAllocationStrategy" >
              <property name="machineHint" value="HYPER_THREADED"
                 <!-- helps us NOT eat up the whole box and choke...-->
</bean>


<bead id="findMeSomeThreads" class "WeightedThreadAllocationStrategy" >
              <property name="relativeWeight" value="0.7" />
               <!-- distribute  the # of threads ACROSS pools ...-->
</bean>


# The above is just some observations  -- perhaps the strategies form a compound / decorated kind of configuration.

[bill-tuba]

This is more of an enhancement - not an "issue" per-se

[jimfcarroll]

Ok Bill. I changed it to an "enhancement."

[jimfcarroll]

For now I'm going to leave this since the output loop works in conjunction with the threading model but uses it's own thread pool so there's no good way to do this except to borrow threads from the main threading model.