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