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