felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Valentin Valchev (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
Date Tue, 09 Dec 2014 15:42:12 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239551#comment-14239551

Valentin Valchev commented on FELIX-4720:

Imagine that you go to the grocery store. Then you have to pay:
- the tomatoes on cashier #1
- cucumbers on cashier #2
- all fruits on cashier #3

Would you visit that grocery store twice?

That's the same with the log storage. If I'm system integrator and had to configure
- log queue of the log service
- log queue of the web console
- log queue of the gogo shell
he/she will be you, in the grocery store. Not use it again!

If I'm developer and create a queue
- i could be blamed if the queue is not configurable
- i could be blamed if there are bugs in the queue
- i could be blamed if it keeps some references to other bundles (through stack trace elements
of the exceptions)
But I have a *standard*, that says - there is a log queue. You bet, I'll use it, instead of
duplicating it.

Carsten, you said, that we can create a common queue, that is independent of log reader. So,
if not using equinox implementation, you will buffer the entries twice and use more memory
than needed? 

And what about code reuse? - one the best features of OSGi is that you can share the code,
and use import-export, instead of copy-paste.
What about reliability and compliance? Can I trust the OSGi standard if we need to change
applications, because some vendor doesn't implement it fully?

P.S: I'm posting some parts of org.osgi.service.log.LogEntry javadoc;
	 * Returns the exception object associated with this {@code LogEntry}
	 * object.
	 * <p>
	 * In some implementations, the returned exception may not be the original
	 * exception. To avoid references to a bundle defined exception class, thus
	 * preventing an uninstalled bundle from being garbage collected, the Log
	 * Service may return an exception object of an implementation defined
	 * Throwable subclass. The returned object will attempt to provide as much
	 * information as possible from the original exception object such as the
	 * message and stack trace.

So, there *is* a way, to prevent pinning objects in memory when implementing the log reader
service. Is equinox, that decided not to implement it that way and instead to return empty
list of log entries. Although that the above solution is simple, I agree, that it's slower
and requires more temporary memory. So it's inefficient. But if we want to correctly implement
web console log plugin, gogo shell log command, that inefficient code is multiplied by 2.
Or by 5, or 6 - depending how many applications do you have to browse the log entries. And
yet, if could be only 1 place - the LogReaderService.

> Web Console and Gogo rely on Log history buffer in the Log Service
> ------------------------------------------------------------------
>                 Key: FELIX-4720
>                 URL: https://issues.apache.org/jira/browse/FELIX-4720
>             Project: Felix
>          Issue Type: Bug
>          Components: Gogo Command, Web Console
>            Reporter: Peter Kriens
> The OSGi Log Reader Service has a command to get the history of the log. However, the
specification states that this history can be empty. The Equinox framework is nowadays registering
a Log Reader Service that has such an empty history to prevent pinning objects in memory.

> Using the history this way was always at odds with the specification since the history
was only intended to hold the start up events. The primary model of the Log Service is a dispatcher.
> I suggest that the Gogo log command and the Web Console maintain their own history buffer
to become independent on this fragile history buffer in the Log Reader service.

This message was sent by Atlassian JIRA

View raw message