Alerts: woe is me...
Steven North
swn at ocsystems.com
Wed Aug 17 18:57:37 UTC 2011
Yes, I saw that problem too. I think we may have to resort to asking
for a subject id/password when defining the alert and run operations
using that subject.
Steve
On 8/17/2011 11:30 AM, Ian Springer wrote:
> 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
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20110817/c1e5a4f3/attachment-0001.html
More information about the rhq-devel
mailing list