Re: Parfait and UoM (java) RPM packages

Hi Marko,

----- Original Message -----
> Hi,
> 
> On 2016-10-20 04:17, Nathan Scott wrote:
> > 
> > (I think we should install some sample/demo programs, too, so people
> > don't have to write their own like you have here just to try it out -
> 
> Yeah, that'd be a good to give anyone interested an opportunity to quick
> get a feeling how it works and what kind of results to expect.
> 
> > We may be able to do better too - it looks like at least half of
> > that is coming from dependencies that we don't need to install for
> > the part of Parfait being used here...
> > 
> > But parfait-agent is standalone - we can make a parfait-agent sub-package
> > without those dependencies which will get us to a single package install,
> > with only deps on the jvm itself I think - should get us to approx 10MB.
> 
> That would be very neat.
> 

(added in the -2 build, which I think then caused this next issue ...)

> >> X. Fix parfait-agent.jar, can be skipped when the fix is in the next RPM
> >> build: unzip the jar, remove the top-most MANIFEST.MF, add the following
> >> line to META-INF/MANIFEST.MF, and re-create the jar:
> >>
> >> Premain-Class: io.pcp.parfait.ParfaitAgent
> > 
> > As mentioned on IRC, I think this is a packaging botch re the specific
> > parfait-agent.jar file that ends up in the rpm - multiple jars are built
> > but we don't use the correct one.  Will fix up on the next build.
> 
> I'm still seeing the same issue with the -2 build:
> 
> Failed to find Premain-Class manifest attribute in
> /usr/share/java/parfait/parfait-agent.jar
> Error occurred during initialization of VM
> agent library failed to init: instrument
> 

Sorry, we've passed each other like ships in the night.  The parfait-agent
RPM was implemented in the -2 RPMs and that is the jar you'll need to use.
Just to mix things up further, I named the standalone jar as "parfait.jar"
now as in the Parfait README.md file, and forgot to tell you.  :P

So there is still a parfait-agent.jar in the parfait RPM, as you found -
this is the jar that other applications could use if they want access to
the parfait-agent code/resources (incl. JVM metric definition mbeans)
directly.  But its not the standalone variety (its also smaller now).

All a bit confusing really, but good to get these things sorted out early
on in the parfait-agent project lifecycle I suppose.

I'll be doing more testing & work on those example programs today, I'll
make sure this more basic case at least is working well (if its not now
with the correct jar).

I also put the proxying code in the -2 build if you want to try that out?
But I forgot to put /usr/bin/parfait in... ho-hum... just to making life
difficult - there'll be a -3 soon.

> You mean we'd need to wait for a possible future GSoC project to have
> [...]

Oh, no - those are "nice to have" features really, to help people with
adding new metrics.  If there are more JVM metrics you have classified
(in terms of correct PCP metric metadata) they can be added directly to
the mbeans file now - no need to wait.

> projects, like WildFly, do they all need a separate project to be
> supported as well?

Shouldn't have to - have a look at the parfait code, in the resources
directory for parfait-agent (and the current mbeans definitions there) -
we can certainly add more mbeans there.

Over time we want to be able to add those definitions externally to the
parfait-agent jar, but it's not there yet.

> I tried this with the -1 build, didn't help, same sort of errors still
> seen, not sure what to try next.

I'll take a closer look - could you paste the full command line (or, just
send it to me privately) & instructions to reproduce?

> Yes, this sounds nice as well, but to be honest I was perhaps expecting
> a bit more complete implementation right from the start before starting
> to wait for possible GSoC projects to deliver additional features,

Well no need to wait - dive right in, the code is all there and for people
with our background & core PCP knowledge, its easy to add metrics already
at this early stage.

> something like JVM metrics should at the very least be offered before
> concluding the core functionality is complete (that would probably be a
> helpful exercise for future GSoC participants as well, they'd have much
> complete reference how classify and handle different types of metrics in
> this scheme).

There's a long way to go yet until its polished, for sure - not claiming
its core functionality is complete.  At this stage its about quality (of
metric metadata, sampling cost, build system) more than quantity (of new
metrics being exported).

It is at the point that people can hack on it & see immediate results,
however.  And its at the point where the architecture can be seen and
incrementally improved.  We can see a modular maven-based approach will
allow sharing of metric definitions between programs that need 'em & is
definitely the long-term viable way of handling java code for PCP.  So,
we're learning and its slowly progressing but I certainly agree its far
from "done" at this stage.

cheers.

--
Nathan

-=-=-=-=-=-=-=-=-=-=-=-
pcp mailing list
[email protected]
https://groups.io/g/pcp/messages
-=-=-
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#14565): https://groups.io/g/pcp/message/14565
View All Messages In Topic (20): https://groups.io/g/pcp/topic/2895998
Mute This Topic: https://groups.io/mt/2895998?uid=174580
New Topic: https://groups.io/g/pcp/post

Change Your Subscription: https://groups.io/g/pcp/editsub?uid=174580

Group Home: https://groups.io/g/pcp
Contact Group Owner: [email protected]

Terms of Service: https://groups.io/static/tos

Unsubscribe: https://groups.io/g/pcp/leave/354243/563757577/xyzzy
-=-=-=-=-=-=-=-=-=-=-=-