getting trigger state

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: 2 Major 2 Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 2.2
  • Component/s: None
  • Labels:
    None
  • Terracotta Target:
    Vicente_Holding

Description

From a JMX perspective, it looks like the only way to retrieve state information for triggers is thru the getTriggerState(String instanceId, String triggerName, String triggerGroupName) operation.

It would be much more efficient return the state of each trigger when any of the following operations are invoked:

  • getTrigger(String instanceId, String triggerName, String triggerGroupName)
  • getTriggersOfJob(String instanceId, String jobName, String jobGroupName)
  • getAllTriggers(String instanceId)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Gary Keim added a comment -

So, essentially, you're asking that the Trigger have a getState method. I can't think of any reason why that isn't good. Maybe James can think of one. I'm adding him as a Watcher of this issue.

Show
Gary Keim added a comment - So, essentially, you're asking that the Trigger have a getState method. I can't think of any reason why that isn't good. Maybe James can think of one. I'm adding him as a Watcher of this issue.
Hide
Permalink
Ivan Ho added a comment -

Yes, that's right. The expectation is that when any of these methods are invoked. The result should return composite objects (Trigger) that include state as an additional attribute.

Show
Ivan Ho added a comment - Yes, that's right. The expectation is that when any of these methods are invoked. The result should return composite objects (Trigger) that include state as an additional attribute.
Hide
Permalink
Gary Keim added a comment -

I'm not willing to make this call.

Show
Gary Keim added a comment - I'm not willing to make this call.
Hide
Permalink
Ivan Ho added a comment -

At this moment, we're ok with what's there. When and if there are enhancements in this area, then we can take it up.

Show
Ivan Ho added a comment - At this moment, we're ok with what's there. When and if there are enhancements in this area, then we can take it up.
Hide
Permalink
James House added a comment -

IIRC, the reason state wasn't exposed on trigger is to avoid confusion on the part of the end user.

For instance, as soon as it is retrieved it can already be invalid (e.g. the trigger could then be complete, or paused by a different thread, etc.) - it would only be a snapshot from a moment in time.

The user could expect, if they retrieved a trigger, and are re-storing it, that the state on that instance will become the trigger's new state, but it won't.

etc.

Of course these facts could be made clear with javadocs, but it's usually better that the API be clear, of course then we devolve into a subjective discussion of whether it's more or less clear to have the state available on the trigger, rather than a separate API call, even if the one on the trigger is stale...

I understand the reason for the request for change: the desire to avoid separate API calls to get the state.

We could discuss and consider this for a 2.1 release.

Show
James House added a comment - IIRC, the reason state wasn't exposed on trigger is to avoid confusion on the part of the end user. For instance, as soon as it is retrieved it can already be invalid (e.g. the trigger could then be complete, or paused by a different thread, etc.) - it would only be a snapshot from a moment in time. The user could expect, if they retrieved a trigger, and are re-storing it, that the state on that instance will become the trigger's new state, but it won't. etc. Of course these facts could be made clear with javadocs, but it's usually better that the API be clear, of course then we devolve into a subjective discussion of whether it's more or less clear to have the state available on the trigger, rather than a separate API call, even if the one on the trigger is stale... I understand the reason for the request for change: the desire to avoid separate API calls to get the state. We could discuss and consider this for a 2.1 release.

People

  • Assignee:
    James House
    Reporter:
    Ivan Ho
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: