Bugzilla – Bug 6131
4.2 rc2 GRAM4 server doesn't send usage packets
Last modified: 2008-06-06 14:44:29
You need to
before you can comment on or make changes to this bug.
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
From Rachana: it only works if you have a MessageContext
This is probably a 4.2.0 blocker.
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?
"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.
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
All core tests work and usage packets were sent. Martin has confirmed that
patch worked with GRAM.
Sorry for the misleading MessageContext information. I should have
looked with more than one blind eye ...