All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Questions about JUL (was: Re:  lttng-dev Digest, Vol 67, Issue 48)
       [not found] <48CF5AC71E61DB46B70D0F388054EFFD267DE218@VAL-E-02.valcartier.drdc-rddc.gc.ca>
@ 2014-02-04 19:13 ` David Goulet
  0 siblings, 0 replies; 2+ messages in thread
From: David Goulet @ 2014-02-04 19:13 UTC (permalink / raw)
  To: Thibault, Daniel; +Cc: lttng-dev


[-- Attachment #1.1: Type: text/plain, Size: 3507 bytes --]

On 04 Feb (18:59:02), Thibault, Daniel wrote:
> ----------------------------------------------------------------------
> Date: Tue, 4 Feb 2014 12:17:36 -0500
> From: David Goulet <dgoulet@efficios.com>
> To: Jim Dumont <jim.dumont@ericsson.com>
> Cc: "lttng-dev@lists.lttng.org" <lttng-dev@lists.lttng.org>
> 
> >> 3) add-context: does --jul have the same possible context types as --userspace (i.e. ip, pthread_id, procname, vpid, vtid)?
> >
> > Nope.
> 
>    What are the possible context types then?  Or is it just that you can't apply a filter to a jul event?

None, you can't add a context to the JUL domain.

> 
> >> 4) enable-channel:
> >> 4.1) Are the --jul --subbuf-size, --num-subbuf and --read-timer defaults the same as with --userspace?
> >
> > Nope. JUL uses it's internal channel so basically enable channel does NOT support the jul domain thus not having -j in the help/man.
> 
>    So you turn jul events on and off using enable/disable-event --all instead?  This is getting a tad confusing: jul events force you to use only enable/disable-event but kernel syscalls force you to use only enable/disable-channel...

No. For JUL you enable "Logger" names from the JUL API. For instance:

$ lttng enable-event -j MyLogger
or to enable all loggers
$ lttng enable-event -j -a

Using the lttng-ctl API, -a == "*".

For the kernel syscalls, yeah well this is a tracer limitation that we
can't enable/disable specific syscalls but fortunately this year we'll
bring this feature! :)

> 
> >> 4.4) If yes, won't they all degenerate to the virtual machine's user and process IDs?
> >
> > Not sure I understand this one?
> 
>    A Java application is interpreted and runs in a Java virtual machine (JVM).  The userID and processID of any jul events are thus likely to be those of the JVM process.  I would expect Java apps launched by separate users to launch separate JVM instances, but I would also expect two separate Java apps launched by the same user to share a single JVM (the user's) and, therefore, their process IDs.  This could get fun with multi-threaded Java apps.

Hrm, I've not observed that. If a specific Linux user with let say UID =
1000, the Java application registering to the session deamon is set with
UID = 1000. Don't forget that the JUL support uses JNI to link with
lttng-ust and that library registers as a the user.

> 
> > Now after answering all this, I feel like either creating a lttng-jul man page or adding a special section in "lttng.1" for the JUL domain explaining all this. Thoughts?
> 
>    We definitely need an additional section in "lttng.1".

Agreed. I'll be updating lttng.1 before the stable release.

THanks!
David

> 
> Daniel U. Thibault
> Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
> Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
> R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
> 2459 route de la Bravoure
> Québec QC  G3J 1X5
> CANADA
> Vox : (418) 844-4000 x4245
> Fax : (418) 844-4538
> NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
> Gouvernement du Canada | Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 603 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Questions about JUL (was: Re:  lttng-dev Digest, Vol 67, Issue 48)
@ 2014-02-04 18:59 Thibault, Daniel
  0 siblings, 0 replies; 2+ messages in thread
From: Thibault, Daniel @ 2014-02-04 18:59 UTC (permalink / raw)
  To: lttng-dev

----------------------------------------------------------------------
Date: Tue, 4 Feb 2014 12:17:36 -0500
From: David Goulet <dgoulet@efficios.com>
To: Jim Dumont <jim.dumont@ericsson.com>
Cc: "lttng-dev@lists.lttng.org" <lttng-dev@lists.lttng.org>

>> 3) add-context: does --jul have the same possible context types as --userspace (i.e. ip, pthread_id, procname, vpid, vtid)?
>
> Nope.

   What are the possible context types then?  Or is it just that you can't apply a filter to a jul event?

>> 4) enable-channel:
>> 4.1) Are the --jul --subbuf-size, --num-subbuf and --read-timer defaults the same as with --userspace?
>
> Nope. JUL uses it's internal channel so basically enable channel does NOT support the jul domain thus not having -j in the help/man.

   So you turn jul events on and off using enable/disable-event --all instead?  This is getting a tad confusing: jul events force you to use only enable/disable-event but kernel syscalls force you to use only enable/disable-channel...

>> 4.4) If yes, won't they all degenerate to the virtual machine's user and process IDs?
>
> Not sure I understand this one?

   A Java application is interpreted and runs in a Java virtual machine (JVM).  The userID and processID of any jul events are thus likely to be those of the JVM process.  I would expect Java apps launched by separate users to launch separate JVM instances, but I would also expect two separate Java apps launched by the same user to share a single JVM (the user's) and, therefore, their process IDs.  This could get fun with multi-threaded Java apps.

> Now after answering all this, I feel like either creating a lttng-jul man page or adding a special section in "lttng.1" for the JUL domain explaining all this. Thoughts?

   We definitely need an additional section in "lttng.1".

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-02-04 19:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <48CF5AC71E61DB46B70D0F388054EFFD267DE218@VAL-E-02.valcartier.drdc-rddc.gc.ca>
2014-02-04 19:13 ` Questions about JUL (was: Re: lttng-dev Digest, Vol 67, Issue 48) David Goulet
2014-02-04 18:59 Thibault, Daniel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.