Hi all,
Summary:
--------
I have a peculiar situation, briefly, I want to write a Daemon/Server in Java
which will listen to the Pop port and service Pop requests from clients.
Setup:
------
I have a Redhat Linux 6 system, and I have jdk-1.1.8 on it.
Details:
--------
I want the behaviour of the Pop Server to mimic that of any other daemon
on a Unix machine. In other words it should first disassociate itself from
the terminal on which it started su down to nobody, close default IO
descriptors and then move on to listening for connections. There is an
another problem here. I am not so sure about having the Server run
uninterrupted. Because of memory leaks I should probably restart the
Server after having server n connections.
Implementation:
---------------
I thought of using the Java Native Interface, I don't know much in this area
but here is the plan ...
If possible I will change to a background process and bind to the Pop Socket
all as part of a C Program, and then Invoke a Java Implementation for
accepting client connections.
Alternately, I could just keep the daemon part of the code in C and reserve
the networking for Java. This way I need to su down to nobody and then
load the appropriate Java Class.
The Second scenario looks more feasible, I am able to start the JVM from
a C Program using libjava.so. This way it also looks easier to start and
restart the JVM as proposed.
The Difficulty is in restarting the daemon after n connections without
inserting any noticeable delay in servicing client connections. I want the
time window for which the service is down to be an acceptable minimum.
I need Help:
------------
The Picture is very hazy, has anybody done this before ? Can Annybody suggest
alternatives ? Can somebody help me with advice/resources on this issue ?
Whats more important is what is the most efficient way to carry this out ?
Of course things have gotten rather complicated and I don't know the hazards
I might face further ahead. Already, JNI_GetDefaultJavaVMInitArgs is
returning null in place of the Classpath, although the CLASSPATH variable
has been set for the shell. I don't know if they are related.
Santosh Dawara
