Alerts: woe is me...

Jay Shaughnessy jshaughn at redhat.com
Wed Aug 17 12:45:44 UTC 2011


Steven,

Overlord sessions expire at 30 seconds.    So, if the [admin] session 
expires it means you started an overlord session and tried to use it for 
an extended period of time.  The intent of an overlord session is a 
quick backend way of calling an SLSB, getting past any permission checks.

On 8/16/2011 5:06 PM, Steven North wrote:
> 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
>
>
> _______________________________________________
> 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