Alerts: woe is me...

Ian Springer ian.springer at redhat.com
Wed Aug 17 18:30:02 UTC 2011


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.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
>>
>>
>> -- 
>> Ian Springer
>> Principal Software Developer
>> JBoss Operations Network
>> Red Hat
>> ian.springer at redhat.com
>>
>>
>> _______________________________________________
>> 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


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20110817/721ff6a8/attachment-0001.html 


More information about the rhq-devel mailing list