[
https://issues.apache.org/jira/browse/SLIDER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151722#comment-14151722
]
Sumit Mohanty commented on SLIDER-463:
--------------------------------------
Agreed, so far Slider does not have a mechanism for containers to influence
AM's AppState. For now, we could investigate if AgentProviderService can issue
ids and if it does, it can be updated when Agents register after restart.
Another aspect that could be an issue is flex-up and flex-down where it can't
be guaranteed that ids assigned are still continuos. Of course, the simple
solution is to ensure that component instance count remains constant.
> Have each container instance for a role be assigned with a unique integer id
> starting at 1 up to maximum requested instances
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: SLIDER-463
> URL: https://issues.apache.org/jira/browse/SLIDER-463
> Project: Slider
> Issue Type: Bug
> Components: agent-provider
> Affects Versions: Slider 0.50
> Reporter: Sumit Mohanty
> Assignee: Sumit Mohanty
> Labels: feedback
>
> Apps can request a number of instances and the id associated with a container
> is the container id. However, container ids are not a reliable way to load
> balance a work load across several instances. This is because container id is
> not guaranteed to be well-distributed for specific role instances.
> A good example of application requiring a id is memcached where clients need
> to know which memcached daemon instance to connect for specific keys (e..g
> hash a key to obtain an integer and access the daemon associated with that
> integer). Alternatively, another example will be an application of peers that
> select workload based on their id. Say, an application processes 100 data
> points and component instances can select which sub-range to process based on
> their id.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
