About the synchronization about monitor info

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

About the synchronization about monitor info

Mavlarn

Hi all,


In ngrinder, we will monitor the target server and save data into DB.

In current version(3.0, standalone), I created a map to save whether a target server is in monitoring. And if only there is not monitoring job on one target, I will remove the agent from the map. This will avoid to add monitor info into DB duplicatedly.


But, now, in cluster mode, I need to make sure this map can work in all controller node. I saved this map in ehcache and make it synchronized in all controllers.


But, after some tests, I found that the ehcache can not make sure the synchronization correctlly.  When the system is starting, the cache should be loaded from cache cluster. But some time it can be loaded, but sometime it will not.  And the empty cache may aslo overwrite the original cache.

Besides this, sometime, the synchronization will not affect on time.


So, I think the kind of cacheing machenism is not proper for this important data synchronization.


Then I think it is better to save the current monitor job info into DB and use it to control whether to start/stop monitoing.

Reply | Threaded
Open this post in threaded view
|

Re: About the synchronization about monitor info

junoyoon
Administrator
I have the different idea. Please hold dev on this. I'll tell you tomorrow

나의 iPhone에서 보냄

2012. 11. 12. 오후 6:31 "Mavlarn [via ngrinder]" <[hidden email]> 작성:

Hi all,


In ngrinder, we will monitor the target server and save data into DB.

In current version(3.0, standalone), I created a map to save whether a target server is in monitoring. And if only there is not monitoring job on one target, I will remove the agent from the map. This will avoid to add monitor info into DB duplicatedly.


But, now, in cluster mode, I need to make sure this map can work in all controller node. I saved this map in ehcache and make it synchronized in all controllers.


But, after some tests, I found that the ehcache can not make sure the synchronization correctlly.  When the system is starting, the cache should be loaded from cache cluster. But some time it can be loaded, but sometime it will not.  And the empty cache may aslo overwrite the original cache.

Besides this, sometime, the synchronization will not affect on time.


So, I think the kind of cacheing machenism is not proper for this important data synchronization.


Then I think it is better to save the current monitor job info into DB and use it to control whether to start/stop monitoing.




If you reply to this email, your message will be added to the discussion below:
http://ngrinder.642.n7.nabble.com/About-the-synchronization-about-monitor-info-tp61.html
To start a new topic under ngrinder_dev, email [hidden email]
To unsubscribe from ngrinder_dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

RE: About the synchronization about monitor info

junoyoon
Administrator
In reply to this post by Mavlarn

I understand this concern.

We don't have to sync important cache item.

However for the monitor data... we need the different approach.

Actually I don't understand why we need such a complex implementation.

We don't need to save them into DB actually.

If we save them in the perftest/report folder per perftest respectively just like perftest infos, we don't need to keep the count and cache as well.


How we can save them into file..

We can serialize sequences of SystemDataModel into file and recover it when it needs.

Just like..


ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(new File(perftestService.getPerfTestReportFolder(perftest));


then..


oos.writeObject(dataModel)..


Then you can read them by calling readObject method multiple times.


.. One thing we should concern is... how we can handle SystemDataModel evolution.. version 1, 2, 3, 4.

You can find the solution in the following article.


http://www.javablogging.com/what-are-writeobject-and-readobject-customizing-the-serialization-process/



If we choose this approach, we don't need anymore refcounter and cache for it.

Please implement this way.


JunHo Yoon
Global Platform Development Lab
/ Senior Engineer

13th FL., Bundang First Tower, 266-1, Seohyeon-dong, Bundang-gu, Seongnam-si, Gyeonggi-do, 463-824, KOREA
Tel 031-600-9071   Fax --   Mobile 010-6255-0559
Email  [hidden email]

NHN Business & Platform NAVER HANGAME 쥬니어네이버 해피빈 미투데이


-----Original Message-----
From: "Mavlarn [via ngrinder]"<[hidden email]>
To: "junoyoon"<[hidden email]>;
Cc:
Sent: 2012-11-12 (월) 18:31:31
Subject: About the synchronization about monitor info

Hi all,


In ngrinder, we will monitor the target server and save data into DB.

In current version(3.0, standalone), I created a map to save whether a target server is in monitoring. And if only there is not monitoring job on one target, I will remove the agent from the map. This will avoid to add monitor info into DB duplicatedly.


But, now, in cluster mode, I need to make sure this map can work in all controller node. I saved this map in ehcache and make it synchronized in all controllers.


But, after some tests, I found that the ehcache can not make sure the synchronization correctlly.  When the system is starting, the cache should be loaded from cache cluster. But some time it can be loaded, but sometime it will not.  And the empty cache may aslo overwrite the original cache.

Besides this, sometime, the synchronization will not affect on time.


So, I think the kind of cacheing machenism is not proper for this important data synchronization.


Then I think it is better to save the current monitor job info into DB and use it to control whether to start/stop monitoing.




If you reply to this email, your message will be added to the discussion below:
http://ngrinder.642.n7.nabble.com/About-the-synchronization-about-monitor-info-tp61.html
To start a new topic under ngrinder_dev, email [hidden email]
To unsubscribe from ngrinder_dev, click here.
NAML