It sounds like your thread synchronization mutexing is not correct.
Furthermore this entire approach is suspect becuase it assumes there is only
one JVM running for your server. Rather limiting I think, unless this is
what you want.
In GemStone/J we provide a goodie EventLogger this is implemented using a
CORBA event service. Each event channel is a system singleton (not JVM
singleton) so the issue above is mitigated. The nice thing about using the
CORBA event model here, is that consumers (loggers) and event suppliers are
totally decoupled. This means different loggers can be attached to the event
channel in a plug and play manner. For example you core logger could be
writing to JDBC storage, but if you wanted a dynamic view, you could hook up
a Console based logger and see the events in "real-time".
Interestingly, when I implemented this goodie, I used exactly the technique
that Joel suggests in the clients of the EventLogger. I didn't want clients
to block when logging events. So events are written to a singleton per JVM
queue, and an asynch thread turns around and sends them to the system
singleton where events are actually dispersed.
-Chris.
> -----Original Message-----
> From: Sanjay Nambiar [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, November 24, 1999 11:34 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Java implementation Query:Urgent
> Importance: High
>
> Hi Joel,
> I have tried to use a queue and implement a solution where Clients threads
> that write to the queue use inter thread communication to notify a thread
> which would then pick up the data and write to a file.
> Here the getting from the queue and putting to the file methods are
> synchronized.
> The log class(helper class) is implemented as a Singleton.
> However I still lose messages along the way when the number of hits to
> writing to the queue increase in comparison to
> writing to the File.
> Joel I have not clearly understood your solution.
> Could you elaborate with my example in mind.
> Regards,
> SANJAY
>
> > -----Original Message-----
> > From: Joel Crisp [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 24, 1999 4:50 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Java implementation Query:Urgent
> >
> > Hi Peter
> >
> > I can't give you code samples - I'm a consultant so I'd have to
> > ask you to pay ;-(
> >
> > I can go into a bit more detail:
> >
> > The main issue is the impact on performance of forcing all threads
> > to synchronize on one global object. If you have a per-thread
> > circular log queue, each thread can post log messages to the front of
> the
> > queue without synchronizing, as the operation of bumping the queue
> pointer
> > is atomic (this is a well known feature of circular queues dating back
> > to the old days of assembler). A global log manager thread can then spin
> > round the queues, pulling off log objects and printing them. This
> ensures
> > that all writes to the log file are serialized appropriately. Even if
> you
> > want to do a bit more work and need to synchronize, you are only
> blocking
> > the local thread (on its queue), and the log thread - not the other
> > worker threads so you are not going to impact performace.
> >
> > Hope this clarifies the situation.
> >
> > Joel
> >
> > Peter Michael wrote:
> > >
> > > > Hi
> > > >
> > > > Both of these solutions are BAD !
> > > >
> > > > You should implement a queue which can take multiple threads
> > > > writing log objects
> > > > to the queue. You can do this without synchronization using
> > > > the atomic features
> > > > of the java language calculations and volatile variables.
> > >
> > > Could you please give a code example?
> > >
> > > > Then use one thread
> > > > to pull the log objects of the queue and write them to the file.
> > > >
> > > > Locking on a shared object will bottleneck your performance,
> > > > and JNI is discouraged
> > > > in EJBs.
> > > >
> > > > Joel Crisp, Senior Java Architect, SUN PS Java Center (UK)
> > > >
> > > > Srinivasan VS wrote:
> > > > >
> > >
> > >
> >
> ==========================================================================
> > =
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff EJB-INTEREST". For general help, send email
> to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
> ==========================================================================
> > =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
