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