Status Report: jini (20-2-2001)
- Finished fridge Gui (can set and view grocery list now)
- Wrote StorageManager (used to maintain leases automatically
- Got fridge to send email of contents and grocery list
- Got fridge to check undelivered mail when it starts up (in case a control message was sent to the fridge when it was down)
- 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)
- Router is activatable.
- Router uses animator to contact services.
- Router has a daemon that makes sure that undelivered mail is
- We're starting a new level of testing.
- Make fridge gui look a little better (maybe)
- Test everything
- Prepare for presentation
- Possibly add some neat features for reliability
- Finalize the system, start writing the paper.
- Take a look at Activation
- Add activation to other services.
- More Testing.
- Clean up router code.
- Write JavaDoc comments in router code.
- Design/implement a solution to the naming/query problem.
- Some more testing
- Start thinking about the final paper.
Deliverables for next tuesdaySummary:
- Have a presentable system
- Work on fixing any bugs.
- Testing the whole system
- Activatable components that handle events (from lookup services.
- Cleaned up router.
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".
- To start, activation is hairy. One particular problem has consumed
most of my time, health and sanity this week. After looking though
activation spec and reading/searching hundreds of activation-related bug
reports and jini/rmi online resources AND posting my question in several
forums, I believe that this is either some kind of weird and unheard of
problem with rmid setup or an unbelievably obvious bug in rmid. I will
add the details of this after the meeting -- don't have time for it now.
- To compensate for this torture, fate has seen it fit to reveal to me that
the TaskManager and the ReliableLog class that I was previously looking for
do exist after all. It's just that Sun apparently thought they'd be of
more use to everyone if they are not documented and maybe even not
used. These two classes made my life a lot easier. I am
particularly pleased with TaskManager which seems to be a straightforward
yet flexible implementation of an animator.
- Before I forget, I agree with Sherif's statement regarding the OutOfMemory
error. Have you ever counted how many virtual machines reggie
starts? Hell, the http server alone creates 6 VMs.
- You might have noticed that I was hoping to have all services be
activatable a week ago and yet it's still a part of my plan for the next
week. I can honestly say that it is all activation's fault. Incidentally,
I must point out that it looks like activation alone is a bigger deal (and
more complex) than everything in Jini put together. I think it's
partially because it ties in so many different areas -- RMI, leasing,
resource management, manipulating VMs, manipulating objects within VMs, the
involved security considerations, anonymity vs authentication in resource
allocation... I don't know if I'm even making sense anymore, but suffice to
say that I was impressed. And yet, it all goes back to my Java
rant. If they could pack all these things in, why didn't they allow
optional eager activation. Granted, it could have caused some
confusion, but as long as they left the default at lazy, I don't think this
would have inconvenienced anyone. I know I'd be grateful.
- Ok, since I promised it, I'll start a quick Jini pros & cons...
-- It's incredibly
easy to create a basic Jini service.
-- It's easy to
convert an existing service 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.
<to be finished after I get
-- Though one can convert an
existing service 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).
<to be finished after I get