Bug 6131 – 4.2 rc2 GRAM4 server doesn't send usage packets

Bug 6131 - 4.2 rc2 GRAM4 server doesn't send usage packets

Summary:

4.2 rc2 GRAM4 server doesn't send usage packets

Status:	RESOLVED FIXED

Product:	GRAM
Component:	wsrf managed execution job service
Version:	unspecified
Platform:	Macintosh All

Importance:	P3 blocker
Target Milestone:	4.2
Assigned To:	Martin Feller

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2008-06-05 17:21 by Joe Bester
Modified:	2008-06-06 14:44 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Joe Bester 2008-06-05 17:21:07

While testing some usage report code, I noticed that the GRAM4 services aren't
sending usage packets. From Martin: I get null from
org.globus.wsrf.container.UsageConfig.getUsageConfig(). If it's null gram does
not send anything
and
From Rachana: it only works if you have a MessageContext

This is probably a 4.2.0 blocker.

------- Comment #1 From Martin Feller 2008-06-05 18:14:08 -------

I tested a bit with 4.0 branch, because i wondered how it had worked
there at all. It seems that there is a MessageContext around in 4.0 branch,
when Core/Axis initializes the services during startup. That's why it works
in 4.0 branch for Gram.

In 4.2 there's no MessageContext attached to the thread that initializes
the services, at least not for the thread that initializes Grams services.
No MessageContext -> no UsageConfig -> no usage report messages for jobs.
I assume that other services could be effected by that change too.

Gram could create the UsageConfig with the first job that comes in, but
this would mean that all jobs, that may be loaded from disk and may finish
before the first job comes in, are not reported.

What is the best way to do this?
Would it be possible for Core to attach a MessageContext to the thread
that starts up the services, as it is in 4.0 branch?
Or would it be possible to get a proper UsageConfig without a MessageContext
being attached to the executing thread?

------- Comment #2 From Rachana Ananthakrishnan 2008-06-05 21:19:15 -------

"From Rachana: it only works if you have a MessageContext"

I haven't looked at this code, so not sure who ascertained that a message
context is needed, but not me. From Martin's note here, it seems like he has
confirmed that as the issue. I am going to defer this to Mike, since he
recently worked on core usage packets.

------- Comment #3 From Rachana Ananthakrishnan 2008-06-06 14:39:09 -------

Committed fix to trunk. 

The issue was not with message context - all services at intialization,
irrespective of whether they are loaded on start up or not, are configured to
have message context. The UsageConfig intialization was moved to service
post-initialization. No reason for the change, since data on deployed services
does not depend on initialization code and is constructed on the fly when a
core packet is sent. Reverted to UsageConfig intialization to be done before
service intialization.

All core tests work and usage packets were sent. Martin has confirmed that
patch worked with GRAM.

------- Comment #4 From Martin Feller 2008-06-06 14:44:29 -------

Sorry for the misleading MessageContext information. I should have
looked with more than one blind eye ...
Marking fixed.