Alerts: woe is me...

Steven North swn at ocsystems.com
Tue Aug 16 21:06:32 UTC 2011


A little more information...

If I remove the "wait 2 minutes" then the getSnapshotReport() call 
works.  So the session must be timing out or something.  Is there any 
way I can control this?

This doesn't seem to be related to the waitForOperation() problem, does it?

Steve

On 8/16/2011 1: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.String) 
> 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.String) 
> throws java.lang.Exception,context-data={}
> 2011-08-16 15:53:41,557 ERROR [STDERR]     at 
> org.rhq.enterprise.server.authz.RequiredPermissionsInterceptor.buildPermissionException(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(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
>>>>
>>>>
>>>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20110816/3eeba2fd/attachment-0001.html 


More information about the rhq-devel mailing list