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@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
--
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer@redhat.com
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel