We have an application running in remote application server (User's Location), and we need the log in our local server in order to get the information about the status of out remote application.
we are planning our Monitor thread shall send logs in the form of delta to our local tomcat server by establishing connection between application source monitor thread and local application server using web services(WS).
The problem here is:
How to collect delta of LOG time to time for webservices to send across?
I thought to write all the log in a file time to time but its becoming critical because there will be lots of I/O operation as we need to open/close it several time.
What is the feasible process to collect delta(piece of information) of log which will be used by WS?
who will do this Job, I mean a single thread or multithread and how it will do? (I mentioed thread because I think thread can do this, but I dnt hav much knowledge )
Please suggest me better solution for this problem.
If I understand the question correctly, then it seems pretty simple. You have some process (could be a thread, could be a scheduled job - anything that can run in the jvm and do stuff) running in the remote server which periodically sends the new log entries to the local server (this can be done via a POST to a web service running in the local server). The remote server process can keep track of what it has sent thus far, and only send what is newer.
There's a Java feature which sounds as if it might apply to your situation, and it's called JMX. The primary use of JMX is to allow a running Java application to be monitored by another application, and that sounds like what you described.
Usually it works the other way around from what you described, though. Usually the application being monitored just collects and stores useful data, and then any JMX client can connect to that application and ask to see that data. You might find that to be a more flexible design than the one you described, anyway.
JMX does have the feature of "notifications", where the JMX server part of the application can send notifications (like logging) to any JMX client who asks for them. The application doesn't have to be written to send notifications to any particular place, only to send them to anybody who has subscribed to them. That way the JMX-enabled application doesn't have to know about potential clients, or worry about whether those potential clients are accessible, or anything like that.
So I would suggest you read up about JMX. It might be more suited to the requirements than the system you just outlined.
Joined: Sep 24, 2012
Yes Emanuel, your understanding is absolutely correct.
But here I m finding the way how "the remote server process can keep track of what it has sent thus far, and only send what is newer". So Please suggest.
Initially there was a discussion about JMX in the team but finally decided to use WebServices.
As I said above, I am trying to take delta of log (getting updated log time to time) and give to WebServices, WS will take care of trasferring the log.
Joined: Mar 24, 2005
The remote server is a jvm correct? Then it can run a Runnable in a thread or a thread pool with some schedule or periodicity. The concrete class implementing the Runnable can keep a timestamp of the last log entry sent over and only send entries newer than the timestamp. This timestamp can also be persisted in the database (if one is available) or in the file system in order to avoid losing it when the jvm shuts down.