Alerts: woe is me...

Steven North swn at ocsystems.com
Wed Aug 17 20:26:17 UTC 2011


Thank you, yes, that's where I got the idea.  ;-)

Steve

On 8/17/2011 12:19 PM, Lukas Krejci wrote:
> You can look at the CLI alert sender
> (modules/enterprise/server/plugins/alertCli module) that does that kind of
> impersonation.
>
> On Wednesday, August 17, 2011 20:57:37 Steven North wrote:
>> Yes, I saw that problem too.  I think we may have to resort to asking
>> for a subject id/password when defining the alert and run operations
>> using that subject.
>>
>> Steve
>>
>> On 8/17/2011 11:30 AM, Ian Springer wrote:
>>> Possibly.
>>>
>>> I think the workaround for the overlord session timing out is to just
>>> make a new call to subjectManager.getOverlord() every time you need to
>>> make an EJB call as overlord, rather than storing the overlord Subject
>>> in a variable and reusing it for multiple EJB calls. But it looks like
>>> you were already doing that where you call
>>> findResourceOperationHistoriesByCriteria()...
>>>
>>> On 08/17/2011 02:23 PM, Steven North wrote:
>>>> Ian,
>>>>
>>>> Yes, I don't see any errors in the server log.  I am in the process
>>>> of trying to enable debug in the server (but my first try failed).  I
>>>> do see the operation being successfully completing in the agent log
>>>> in a few seconds.  I just can't seem to wait for the history.
>>>>
>>>> I wonder now if this is related to the overlord issue?
>>>>
>>>> Steve
>>>>
>>>> On 8/17/2011 11:20 AM, Ian Springer wrote:
>>>>> Hmm, so a schedule is returned by scheduleResourceOperation, which
>>>>> suggests that the operation was scheduled, but no operation history
>>>>> ever gets created... Did you check the Server log for errors? Can
>>>>> you tell if the operation is getting executed in the corresponding
>>>>> Agent?
>>>>>
>>>>> On 08/16/2011 04:55 PM, Steven North wrote:
>>>>>> Ian,
>>>>>>
>>>>>> Thanks for the suggestion.  I tried removing the criteria (there is
>>>>>> really only resource id and job id) but neither worked.  I went
>>>>>> ahead and commented out my waitForOpertion() call and proceeded to
>>>>>> wait and then try the getSnapshotReport() call and started having a
>>>>>> problem, which surprised me because that code was working before.
>>>>>> I am now wondering if that error might shed some light on why the
>>>>>> waitForOperation() call is failing.
>>>>>>
>>>>>> The new failure is:
>>>>>>
>>>>>> 2011-08-16 15:53:41,508 INFO
>>>>>> [com.ocsystems.rtiplugin.RtiAlertSender] RTI Alert: get snapshot
>>>>>> 2011-08-16T20:51:41..2011-08-16T20:53:41 in 12702
>>>>>> 2011-08-16 15:53:41,555 ERROR
>>>>>> [com.ocsystems.rtiplugin.RtiAlertSender] RTI Alert: notification
>>>>>> failed: org.rhq.enterprise.server.authz.PermissionException: The
>>>>>> session ID for user [admin] is invalid!: invocation: method=public
>>>>>> java.net.URL
>>>>>> org.rhq.enterprise.server.support.SupportManagerBean.getSnapshotReport
>>>>>> (org.rhq.core.domain.auth.Subject,int,java.lang.String,java.lang.Strin
>>>>>> g) throws java.lang.Exception,context-data={}
>>>>>> 2011-08-16 15:53:41,555 ERROR [STDERR]
>>>>>> org.rhq.enterprise.server.authz.PermissionException: The session ID
>>>>>> for user [admin] is invalid!: invocation: method=public
>>>>>> java.net.URL
>>>>>> org.rhq.enterprise.server.support.SupportManagerBean.getSnapshotReport
>>>>>> (org.rhq.core.domain.auth.Subject,int,java.lang.String,java.lang.Strin
>>>>>> g) throws java.lang.Exception,context-data={}
>>>>>> 2011-08-16 15:53:41,557 ERROR [STDERR]     at
>>>>>> org.rhq.enterprise.server.authz.RequiredPermissionsInterceptor.buildPe
>>>>>> rmissionException(RequiredPermissionsInterceptor.java:164)
>>>>>>
>>>>>> {snip]
>>>>>>
>>>>>> Again, the sequence of events is:
>>>>>>
>>>>>> - invoke operation to turn on diagnostics
>>>>>> - wait for operation to complete (commented out now)
>>>>>> - delay for 2 minutes
>>>>>> - invoke getSnapshotReport()
>>>>>>
>>>>>> The first invoke and the wait seem to complete normally (I see the
>>>>>> operation being performed by the agent) then the traceback starts
>>>>>> at the getSnapshotReport() call.
>>>>>>
>>>>>> I have attached the full traceback if it's useful.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 8/16/2011 9:13 AM, Ian Springer wrote:
>>>>>>> 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(subjectMan
>>>>>>>> ager.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
>>>>>>> _______________________________________________
>>>>>>> rhq-devel mailing list
>>>>>>> rhq-devel at lists.fedorahosted.org
>>>>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>>> _______________________________________________
>>>>>> rhq-devel mailing list
>>>>>> rhq-devel at lists.fedorahosted.org
>>>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>> _______________________________________________
>>>>> rhq-devel mailing list
>>>>> rhq-devel at lists.fedorahosted.org
>>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>> _______________________________________________
>>>> rhq-devel mailing list
>>>> rhq-devel at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list