Thank you, yes, that's where I got the idea. ;-)
Steve
On 8/17/2011 12:19 PM, Lukas Krejci wrote:
You can look at the CLI alert sender
(modules/enterprise/server/plugins/alertCli module) that does that kind of
impersonation.
On Wednesday, August 17, 2011 20:57:37 Steven North wrote:
> 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.Strin
>>>>> g) 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.Strin
>>>>> g) throws java.lang.Exception,context-data={}
>>>>> 2011-08-16 15:53:41,557 ERROR [STDERR] at
>>>>>
org.rhq.enterprise.server.authz.RequiredPermissionsInterceptor.buildPe
>>>>> rmissionException(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(subjectMan
>>>>>>> ager.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
>>> _______________________________________________
>>> 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