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(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel