Status Report: jini (6-3-2001)
- Got POP3 server up and running
- Helped integrate storage and POP3 server with Sherif and Boris'
- Began work on SMTP server
- Added Remote Events, as soon as an account is added or updated
the responsible thread is either started, or stopped SAFELY then
restarted with the new data.
- Added Task Manager, Service Discovery is handled by a seperate thread
to avoid blocking of the one.box core components
- Much more reliable system (Exception handling)
- Did a little testing.
- Changing services to activatable.
- My files are javadoc compatible.
- Changed the router to support some of the recent storage changes.
- SMTP server working
- Make TSpaces store things persistently (it's only storing stuff in
memory right now)
- Begin work on Fridge
- Finalize the system, start writing the paper.
- Take a look at Activation
- Finish leftover implementation.
- Do testing of the entire system.
- Evaluate one.box.
- Work on the final report.
Deliverables for next tuesdaySummary:
- SMTP server working
- TSpaces storing persistently
- Fridge beginnings
- Work on fixing any bugs.
- Testing the whole system
- Finished report (group effort)
- Finished essential one.box stuff
IanPlease go to my time tracker, click on
"Universal Inbox", and log in as "guest" (no password). (I'll work put
this page on this site in the future.)
SherifIan's time tracker contains my information as well.
BorisIan's time tracker contains my information as
- Running out of memory has been a problem. We get a OutOfMemoryError from
the JVM every once in a while. I think this is because of a documented bug
where remote objects always have strong references. This bug is fixed in the
- Remote Events adds a little bit of asynchronous activity to Jini.
- We discovered that TaskManager and ReliableLog classes do exist!!!They're
not documented and there's no refernce to them in the docs!!!Thats because they're
not part of the Jini Specification.All I have to say is "Late better then Never" :))
- OutOfMemory apparently is something to be expected if we try to run all the services
on 1 machine, at least thats what some resources I've looked into said, and I quote
"It is often more practical to run the services on different machines due to the
memory requirements of Sun's present implementation of these services".
- I seem to be going through a stage of total lack of inspiration. I
spend plenty of time in the lab, don't sleep, yet I produce nothing.
This could some unusual end-of-quarter temporary insanity, but I'm finding
myself being pretty sick of even thinking about work. Given that, it's
pretty obvious that I can't have many new things to say this week.
- First, here's an update on that RMID problem I've encountered. I've
posted the question on 3 java (including 1 RMI) forums -- not a single
response. I've emailed the Jini-users list about my problem and had a couple
of people ask me for additional detail. After I have supplied the
requested details, I've had no further replies. Unless a miracle
happens and I find an answer or at least a reason to doubt my current
conclusion, I intend to label this as an RMID bug and show pass off our
services as working perfectly whereas RMID is buggy.
- Since I don't have many comments this time AND it turns out that I never
finished my jini "evaluation", I will try to do it now. It
will include the last week's stuff. Note: my evaluation from
last week had far more "pros" than "cons"; the
reason for that is that I started with "pros" and thus had time to
write more of them.
-- It's incredibly
easy to create a basic Jini service.
-- It's easy to
convert some existing code into a simple Jini service.
-- In a lot of ways,
once a Jini service wrapper is created for a class, it can then scale to
enormous proportions without requiring much more jini-specific coding.
-- Leasing provides
the basis for recovery from disconnects and crashes.
-- Multicasting lookup
discovery makes it possible to locate the lookup services without prior
knowledge of the network structure.
-- Jini is built with
the thought that it would have as its basis many already developed tools.
Since Jini is based on such tested APIs that have already infiltrated the
industry, it should have less trouble establishing itself in the industry.
-- Most of the ideas
used in jini are either very simple or are natural extensions of the
-- Though one can convert
some existing code into a Jini service, more demanding requirements will force one
to look for optimizations that will require additional modifications to
an existing service.
-- Multicast lookup
discovery can be a source of problems as its effectiveness is highly dependent
on network topology (as was mentioned and demonstrated previously).
-- Jini is built using
synchronous communication. Though RPC is a well understood form of
communication and is suitable for some tasks, it seems to go against Jini's
purpose as a framework for highly dynamic distributed systems. As we
discovered, in some cases even a small network is likely to have services whose
robustness is questionable. In these cases, synchronous communication
endangers other network components. Though it may seem that Jini also
supports events, these only simulated using callback functions, and are,
therefore, not asynchronous.
-- Jini lacks administration
mechanisms. The only thing it provides in that respect is a few
administrative interfaces. These are really nothing more than suggestions
and involve absolutely no security considerations.
-- In my opinion, Jini could
benefit greatly from checkpointing. Having manual log is a poor substitute