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