Roadmap...

[gouldina]

There are a few different types of threading issues I need to look at (please note I'm not a thread programming guru):

<snip>

Thoughts anyone?

I agree with Karthicks post earlier re. threading (<my summary>: that synchronisation issues should be the responsibility of the user of the library and that it will introduce unnecessary complexity).
I also agree with nikster's comments about not having designed it in from the start. Trying to make code thread-safe after the event is (in my experience at least) about 10 times harder than doing it up front because in the latter case, you create your design with threading in mind.
Example (3) does sound like the hardest but as you say, invokeLater() sounds like the answer.

For server side development I don't know - leave the developers to work it out?

I'm not sure I understand this question. What would server side code be doing with charts? Surely they are inherently client-side.

[nikster]

What would server side code be doing with charts? Surely they are inherently client-side.

the server generates pngs and jpegs which are then served to a website. instead of drawing charts client-side, you generate them as images server side. instead of drawing them on the screen, they are drawn into an image. that's the only case (... i can think of...) where you would want multi-threaded drawing....

-nik

[gouldina]

What would server side code be doing with charts? Surely they are inherently client-side.

the server generates pngs and jpegs which are then served to a website. instead of drawing charts client-side, you generate them as images server side. instead of drawing them on the screen, they are drawn into an image. that's the only case (... i can think of...) where you would want multi-threaded drawing....

-nik

OK thanks. As you can probably tell, I'm not very clued up about using JFC in a web environment
btw I like your threadsafe wrapper idea in your previous post. This is a little like the approach taken in java.util in (e.g.) the
Collections.synchronizedCollection() (etc) methods and as you point out, doesn't impose any overheads and/or risk of deadlocks and bugs on applications that don't require synchronization. Extension is most definitely better than modification.

[Karthicks]

david.gilbert wrote:

For server side development I don't know - leave the developers to work it out?

I have already posted regarding thread handling in java client(swing client).
In regard web client , server will process tha page submitted in single thread. Let us say with in the jsp when you instantiate jfreechart and and generate images. There won't be any issue. Since there is no parallel processing. Date can be fetched in the same thread and painted. suppose let us assuem that a chart has four series. Then each series can be fetched in different thread. After fetching the data in each thread . Add the model to Graph model with in a synchronized block of common object

Code: Select all

sychronized(chartObject)
{
//generate dateset from all the model fetched from different threads
chartObject.setModel(dateset);
or
//add  the each series model to existing dataset
//generate Image
}

Then via display chart servlet  access the generated image.


S.Karthick

[Karthicks]

david.gilbert wrote:

For server side development I don't know - leave the developers to work it out?

I have already posted regarding thread handling in java client(swing client).
In regard web client , server will process tha page submitted in single thread. Let us say with in the jsp when you instantiate jfreechart and and generate images. There won't be any issue. Since there is no parallel processing. Date can be fetched in the same thread and painted. So theread is no need to consider threads.

In some business requirement , there will be ned to fetch data in different thread. let us assuem that a chart has four series. Then each series has to be fetched in different thread. After fetching the data in each thread . Add the model to Graph model with in a synchronized block of common object

Code: Select all

sychronized(chartObject)
{
//generate dateset from all the model fetched from different threads
chartObject.setModel(dateset);
or
//add  the each series model to existing dataset
//generate Image
}

Then via display chart servlet access the generated image. so there need to handle thread in above said usecase and the way as said in snippet.

S.Karthick

[nikster]

karthicks,

i think you want multi threaded apps only when you have one application with multiple users. your app
- runs on a server
- multiple users can log in at the same time
- multiple users can look at and modify data

this is when you get multiple threads.

if you just have a web app to look at some data which is fetched from a database, and you start a new one (or a new thread) for every user, you don't need any multi-threaded drawing.

is there somebody here who actually has a multi-threaded app running? if yes, can they post the requirements? it would help to understand the problem, even though it's a little like beating a dead horse since we all already agree that any threading complications should be taken care of by the user of JFC and not the framework....

cheers, nikster

[Tal Kormas]

I have the same application, but for QoS, I would like to have everything run faster. I have a dedicated server, and I'm using threads to make sure the system is consist with database updates. I'm caching charts, and I'm using a thread to check the cache while I'm making the data ready before going to the database. This saves some time.

However, while creating the data for the chart is quite fast by now, the chart drawing itself is the slow part. I've noticed some performance issues on the draw funcations (for example on PlotPie3D you have 4 loops when there should only be 2). I would love it if stuff could run faster, or paralle the work so it will complete faster.

Just to show you what I mean: Since I'm getting into doPost till I end it it takes 1.1 second. JFreeChart for Pie3D takes 1 second... you could see the overhead. I've made some modifications on the files, and was able to reduce time to first chart to 1.1 seconds and the followings to 0.7.... It still is overheading...

Tal

[Gunnar]

Hello,

About the threading issue (updating and painting simultaneously), I do it in my own charting library as follows:

- first thing I do in some paint/draw method I take a snapshot of the data that has to be drawn
- of course the 'snapshot take' and the updating of data must be done mutually exclusive

That's all there is to it in my opinion. Of course when you have more series on a chart then take a snapshot for each individual series.

My source code is (not yet) open source but from the API you should get some ideas. Because I think my charting library focusses on a different audience (real time/stock market) I hope I'm not offending anybody when I give the link where you can see how the snapshotting works out in practice. http://213.93.115.167 .

Regards,
Gunnar

[vinay076]

Hi David
When would subreports become a feature of JFreeReports ?
We need that functionality badly in our project and were looking for that functionality in the next release.
Vinay