Alerts: woe is me...

Ian Springer ian.springer at redhat.com
Tue Aug 16 16:13:50 UTC 2011


This is just a guess but perhaps jobId or one of the other history 
criteria filters is excluding the history you're trying to lookup for 
some reason. I'd try commenting out some of the filters one by one and 
see if the query returns any histories. This will allow you to determine 
if any history at all is getting created for the schedule request. If 
one is, then you can try to figure out why your criteria is not matching it.

On 08/12/2011 01:15 PM, Steven North wrote:
> Heiko,
>
> Here is the relevant code to schedule the operation:
>
>               private static final int DEFAULT_OPERATION_TIMEOUT = 240;
>
>               ResourceOperationSchedule schedule =
>                  operationManager.scheduleResourceOperation(
>                        overlord,
>                        collectorId,
>                        "setBtmOption",
>                        0,
>                        0,
>                        0,
>                        DEFAULT_OPERATION_TIMEOUT,
>                        cfg,
>                        "RTI Alert trace until " + interval);
>
>               //TODO fix this....
>               ResourceOperationHistory hist = waitForOperation(schedule);
>
> and to wait for completion:
>
>      private ResourceOperationHistory
> waitForOperation(ResourceOperationSchedule schedule) throws Exception
>      {
>         final int NUM_INTERVALS = 240;
>         final int INTERVAL_DURATION = 1000;
>
>         OperationManagerLocal operationManager =
> LookupUtil.getOperationManager();
>         SubjectManagerLocal subjectManager = LookupUtil.getSubjectManager();
>
>         ResourceOperationHistoryCriteria criteria = new
> ResourceOperationHistoryCriteria();
>         criteria.addFilterJobId(schedule.getJobId());
>         criteria.addFilterResourceIds(schedule.getResource().getId());
>         criteria.addSortStartTime(PageOrdering.DESC);
>         criteria.setPaging(0, 1);
>         criteria.fetchOperationDefinition(true);
>         criteria.fetchParameters(true);
>         criteria.fetchResults(true);
>
>         ResourceOperationHistory history = null;
>
>         int i = 0;
>
>         while (history == null&&  i<  NUM_INTERVALS)
>         {
>            try
>            {
>               Thread.sleep(INTERVAL_DURATION);
>
>               List<ResourceOperationHistory>  histories =
>
> operationManager.findResourceOperationHistoriesByCriteria(subjectManager.getOverlord(),
> criteria);
>
>               if (histories != null&&  histories.size()>  0)
>               {
>                  log.info("RTI Alert:  hist = " +
> histories.get(0).toString());
>               }
>
>               if (histories != null&&
>                     histories.size()>  0&&
>                     histories.get(0).getStatus() !=
> OperationRequestStatus.INPROGRESS)
>               {
>                  history = histories.get(0);
>               }
>            }
>            catch (InterruptedException ie)
>            {
>               log.info("RTI Alert: operation interrupted...");
>               break;
>            }
>            ++i;
>         }
>
>         if (history == null)
>         {
>            log.info("RTI Alert: operation timed out...");
>            throw new Exception("Operation timed out.");
>         }
>         else if (history.getStatus() != OperationRequestStatus.SUCCESS)
>         {
>            log.info("RTI Alert: error..." + history.getErrorMessage());
>            throw new Exception("JON Server error: " +
> history.getErrorMessage());
>         }
>
>         return history;
>      }
>
> Last night I tried just ignoring the waitForOperation() call since my
> logic waits for a set period afterwards, and things seemed to work, but
> this is not ideal since I won't know about any errors performing the
> first operation.

Is
>
> Thanks.
>
> Steve
>
> On 8/12/2011 3:19 AM, Heiko W.Rupp wrote:
>> Steve,
>>
>> Am 12.08.2011 um 07:19 schrieb Steven North:
>>
>>> I was looking through the RHQ code and I found the OperationSender
>>> alert.  It looks like this example did exactly what I was trying to do,
>>> but apparently the wait code was commented out for some unspecified
>>> reason.  This doesn't seem too promising...
>> Can't tell at the moment.
>> When setting up an operation in general, we can supply a timeout
>> in seconds/minutes etc that we wait for before we consider the
>> operation as timed out. This is set to 0 in the OperationsSender,
>> which means "no timeout".
>>
>> Could you post a code-snippet, so that we may get a better idea
>> of what you are doing and what may go wrong?
>>
>>     Heiko
>>
>>
>>



More information about the rhq-devel mailing list