You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2008/11/18 22:02:06 UTC
Thread abstraction for Java client
Hi All,
I have been testing the java client on particular RT jvm and have observed a
stubstantial performance drop when compared to stock Java 1.5
After further investigation I changed the Threads in our java client to
Realtime Threads and there was more than 50% improvement in performance.
Using Realtime threads not only improves performance it also allows the
user to fine tune the RT GC and other optimizations to get good determinism.
At some point some of our Qpid users may want to run their applications on a
RT jvm. To get the optimum benifit of such an environment we should provide
a way for them to use RT Threads with a simple thread abstraction. For
licensing reasons we cannot have any RT specific code in Qpid repo.
So if we could provide a simple thread abstraction that defaults to
java.lang.Thread that can be switched javax.realtime.RealtimeThread in an RT
environment that would be great.
I would like to hear your thoughts/suggestions around the best way to handle
this.
Regards,
Rajith
Re: Thread abstraction for Java client
Posted by Rajith Attapattu <ra...@gmail.com>.
I will make the current extends Thread classes to implement Runnable and
then create a thread factory abstraction which will create java.lang.Threads
by default. The thread factory could be configured using a system property.
Regards,
Rajith
On Wed, Nov 19, 2008 at 4:55 PM, Robert Godfrey <ro...@gmail.com>wrote:
> 2008/11/19 Aidan Skinner <ai...@apache.org>:
> > On Wed, Nov 19, 2008 at 3:33 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
> >> On Wed, Nov 19, 2008 at 9:54 AM, Aidan Skinner <ai...@apache.org>
> wrote:
> >
> >>> What strategy did you adopt? It would probably be possible to change
> >>> the things that extend Thread to a composite that accept thread, or
> >>> implement Runnable.
> >>>
> >>
> >> I haven't really decided on a strategy yet and open to suggestions.
> >> Your suggestion also is similar to Gordon which I think is very good.
> >> However looking at the code in IOSender/Receiver as well as the
> Dispatcher I
> >> see they extends the Thread class directly.
> >
> > I think extending Runnable is probably cleaner, it can just be
> > allocated from a threadpool (which could use vanilla, RT or any other
> > flavour of thread it desired). I don't see any reason why they have to
> > extend Thread directly.
> >
>
> I agree - I think having things implement Runnable is cleaner and more
> flexible than extending Thread directly.
>
> Cheers,
> Rob
>
Re: Thread abstraction for Java client
Posted by Robert Godfrey <ro...@gmail.com>.
2008/11/19 Aidan Skinner <ai...@apache.org>:
> On Wed, Nov 19, 2008 at 3:33 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>> On Wed, Nov 19, 2008 at 9:54 AM, Aidan Skinner <ai...@apache.org> wrote:
>
>>> What strategy did you adopt? It would probably be possible to change
>>> the things that extend Thread to a composite that accept thread, or
>>> implement Runnable.
>>>
>>
>> I haven't really decided on a strategy yet and open to suggestions.
>> Your suggestion also is similar to Gordon which I think is very good.
>> However looking at the code in IOSender/Receiver as well as the Dispatcher I
>> see they extends the Thread class directly.
>
> I think extending Runnable is probably cleaner, it can just be
> allocated from a threadpool (which could use vanilla, RT or any other
> flavour of thread it desired). I don't see any reason why they have to
> extend Thread directly.
>
I agree - I think having things implement Runnable is cleaner and more
flexible than extending Thread directly.
Cheers,
Rob
Re: Thread abstraction for Java client
Posted by Aidan Skinner <ai...@apache.org>.
On Wed, Nov 19, 2008 at 3:33 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> On Wed, Nov 19, 2008 at 9:54 AM, Aidan Skinner <ai...@apache.org> wrote:
>> What strategy did you adopt? It would probably be possible to change
>> the things that extend Thread to a composite that accept thread, or
>> implement Runnable.
>>
>
> I haven't really decided on a strategy yet and open to suggestions.
> Your suggestion also is similar to Gordon which I think is very good.
> However looking at the code in IOSender/Receiver as well as the Dispatcher I
> see they extends the Thread class directly.
I think extending Runnable is probably cleaner, it can just be
allocated from a threadpool (which could use vanilla, RT or any other
flavour of thread it desired). I don't see any reason why they have to
extend Thread directly.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt
Re: Thread abstraction for Java client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Nov 19, 2008 at 9:54 AM, Aidan Skinner <ai...@apache.org> wrote:
> On Wed, Nov 19, 2008 at 2:48 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
>
> > Some of our classes directly extends java.lang.Thread. So I believe the
> > above strategy will be a bit difficult.
>
> [..]
>
> >> Do you have a patch that you used for your experiments that would show
> the
> >> scope of the changes required?
> >>
> > Hoping to attach one today for discussion.
>
> What strategy did you adopt? It would probably be possible to change
> the things that extend Thread to a composite that accept thread, or
> implement Runnable.
>
I haven't really decided on a strategy yet and open to suggestions.
Your suggestion also is similar to Gordon which I think is very good.
However looking at the code in IOSender/Receiver as well as the Dispatcher I
see they extends the Thread class directly.
So I was thinking about doing something with minimum change to existing
code.
How about the following idea. Below is a rough sketch.
IoSender extends org.apache.qpid.Thread - which is a wrapper class with the
same methods as java.lang.Thread.
And then define org.apache.qpid.Thread as,
public class Thread
{
private java.lang.Thread delegate;
private static Class delegateClass;
static{
String delegateClassName = System.getProperty("qpid.threadclass",
"java.lang.Thread");
try{
delegateClass = Class.forName(delegateClassName);
}catch(Exception e){
.........
}
}
public Thread() throws Exception
{
delegate = (java.lang.Thread)delegateClass.newInstance();
}
public Thread(String name) throws Exception
{
Constructor constructor = delegateClass.getConstructor(new
Class[]{String.class});
delegate = (java.lang.Thread)constructor.newInstance(new
Object[]{name});
}
public void start()
{
delegate.start();
}
public void join() throws InterruptedException
{
delegate.join();
}
}
We could also delegate the creation of the Threads to a factory class like
Gordon suggested which could also hide setting priorities etc for the
Realtime threads.
> Having something that runs on RT Java is definately interesting.
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://cwiki.apache.org/qpid
> "Nine-tenths of wisdom consists in being wise in time." - Theodore
> Roosevelt
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: Thread abstraction for Java client
Posted by Aidan Skinner <ai...@apache.org>.
On Wed, Nov 19, 2008 at 2:48 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> Some of our classes directly extends java.lang.Thread. So I believe the
> above strategy will be a bit difficult.
[..]
>> Do you have a patch that you used for your experiments that would show the
>> scope of the changes required?
>>
> Hoping to attach one today for discussion.
What strategy did you adopt? It would probably be possible to change
the things that extend Thread to a composite that accept thread, or
implement Runnable.
Having something that runs on RT Java is definately interesting.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt
Re: Thread abstraction for Java client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Nov 19, 2008 at 6:11 AM, Gordon Sim <gs...@redhat.com> wrote:
> Rajith Attapattu wrote:
>
>> Hi All,
>>
>> I have been testing the java client on particular RT jvm and have observed
>> a
>> stubstantial performance drop when compared to stock Java 1.5
>> After further investigation I changed the Threads in our java client to
>> Realtime Threads and there was more than 50% improvement in performance.
>> Using Realtime threads not only improves performance it also allows the
>> user to fine tune the RT GC and other optimizations to get good
>> determinism.
>>
>> At some point some of our Qpid users may want to run their applications on
>> a
>> RT jvm. To get the optimum benifit of such an environment we should
>> provide
>> a way for them to use RT Threads with a simple thread abstraction. For
>> licensing reasons we cannot have any RT specific code in Qpid repo.
>> So if we could provide a simple thread abstraction that defaults to
>> java.lang.Thread that can be switched javax.realtime.RealtimeThread in an
>> RT
>> environment that would be great.
>>
>> I would like to hear your thoughts/suggestions around the best way to
>> handle
>> this.
>>
>
> My first thought, would be to simply have a configurable implementation of
> a ThreadFactory interface with a createThread(Runnable task, String
> name):Thread method. The default would create normal threads, if a user
> wished they could set a system property to indicate their prefered factory.
>
Some of our classes directly extends java.lang.Thread. So I believe the
above strategy will be a bit difficult.
>
> Is there any difference in which threads are swapped to realtime threads?
> I.e. is switching the io threads more effective than switching the
> dispatcher, or do all the threads need to be switched to see any benefit?
>
You need to switch all threads to see a benifit. java.lang.Threads have a
very low priority and is lower than RT GC threads even in the normal mode.
Therefore when GC threads run it will completely preempt the
java.lang.Threads which will cause a big slow down. (Note by default u will
have a GC thread per CPU allocated). Also CPU is alocated based on priority
and most of the time java.lang.Threads gets the short end of the stick and
will cause the most jitter defeating the deterministic goals. So even of you
limit GC threads, when GC runs the remaning CPU will mostly be allocated to
the Realtime threads, and the java.lang.Threads will have very little CPU at
all.
>
> Do you have a patch that you used for your experiments that would show the
> scope of the changes required?
>
Hoping to attach one today for discussion.
--
Regards,
Rajith
Re: Thread abstraction for Java client
Posted by Gordon Sim <gs...@redhat.com>.
Rajith Attapattu wrote:
> Hi All,
>
> I have been testing the java client on particular RT jvm and have observed a
> stubstantial performance drop when compared to stock Java 1.5
> After further investigation I changed the Threads in our java client to
> Realtime Threads and there was more than 50% improvement in performance.
> Using Realtime threads not only improves performance it also allows the
> user to fine tune the RT GC and other optimizations to get good determinism.
>
> At some point some of our Qpid users may want to run their applications on a
> RT jvm. To get the optimum benifit of such an environment we should provide
> a way for them to use RT Threads with a simple thread abstraction. For
> licensing reasons we cannot have any RT specific code in Qpid repo.
> So if we could provide a simple thread abstraction that defaults to
> java.lang.Thread that can be switched javax.realtime.RealtimeThread in an RT
> environment that would be great.
>
> I would like to hear your thoughts/suggestions around the best way to handle
> this.
My first thought, would be to simply have a configurable implementation
of a ThreadFactory interface with a createThread(Runnable task, String
name):Thread method. The default would create normal threads, if a user
wished they could set a system property to indicate their prefered factory.
Is there any difference in which threads are swapped to realtime
threads? I.e. is switching the io threads more effective than switching
the dispatcher, or do all the threads need to be switched to see any
benefit?
Do you have a patch that you used for your experiments that would show
the scope of the changes required?