Jini Lookup and Caching

Discussions

News: Jini Lookup and Caching

  1. Jini Lookup and Caching (11 messages)

    Dan Creswell has written "Jini Lookup and Caching," because "people aren't aware of some fundamentals of how Jini lookup behaves and some utilities one might typically use to avoid rather obvious pitfalls."
    When one performs a successful lookup, a proxy is returned. Because the proxy is a serialized Java construct we may need to download some code (if the proxy is a JERI reflective proxy, there's no code to download for example). For the sake of this discussion, let's assume we do need to pull some code down. What happens under the covers, is we check to see if we already have a classloader for the codebase associated with the proxy. If we do, there's no need to download the code, we already have what we need. Otherwise we must instantiate a new PreferredClassLoader and download the necessary bytecode. And for as long as we have a reference to the proxy, the classloader will exist and thus any further code-downloading will be driven by the usual Java rules for classloading. Obviously if we release our references to the proxy, it's classes are no longer referenced and the classloader might well be gc'd as it should be. Potentially, that means that everytime we do a lookup/use proxy/release cycle we could end up having to do code-downloading. Fortunately, there's a utility available which avoids that issue and, as a side benefit keep's it's list of services up-to-date - it's called LookupCache and can be created via ServiceDiscoveryManager. Rather than do a direct lookup, we construct a LookupCache with the details of the kind of service we're interested in and leave it to populate itself appropriately which includes handling the code-downloading aspect. All we then have to do is query the cache. And because the service proxies are now cached we are assured of not needing to repeatedly free and re-instantiate classloaders and incur the overhead of un-necessary code-downloading.
    of course, the problem now becomes... what exactly is JERI? (To wit: it's "Jini Extensible Remote Invocation," and highlights even more Jini jargon for people to be unaware of.)

    Threaded Messages (11)

  2. Does somebody knows how to successfully prevent clashes between development environments? I mean that when we played with Jini at work the first thing that happened is that my colleague's client got connected to the service running on my machine rather than on his own. My guess is that setting TTL to 0 will prevent multicast to spread and therefore discovery can be confined to the localhost, but that is not that good of the answer because we want some services to run on shared machines. So, is there any guidance regarding team development policies, guidances and tricks?
  3. Re: Jini Lookup and Caching[ Go to top ]

    I think the jini-users mailinglist would be a better place for your question, but yes it can be accomplished. In the past I worked for a company that had around 15 developers working in the same subnet, each had 30+ Jini services running and there were some Jini services shared by all the developers. The easiest way to deal with this kind of situation is to deploy a lookup service for each developer and to configure that one to be part of a particular member group. Each developer then must make sure (by configuration of the member group) his services join that lookup service. The shared services however join the lookup services of all the developers. This way clients see the developer specific services as well as the shared services. Most services deployed by the developers ran in one JVM and were upgraded as result of the ongoing development process without bringing the client or server JVMs down, changes (also of mobile code [1]) propagated through the network. This was a huge time-saver for us compared to how we developed distributed systems before using Jini, which most of the times required a complete restart of the system. Last year the Jini Service Container that has been created to make the development and deployment of Jini services easier and more productive has been Open Sourced by this company. [1] there are certainly issues with mobile code, for more information I suggest people to read the paper "Class Loading Issues in Java RMI and Jini Network Technology" by Michael Warres.
  4. Re: Jini Lookup and Caching[ Go to top ]

    Thanks for the answer. But here is my observation:
    I think the jini-users mailinglist would be a better place for your question....
    https://www2.blogger.com/comment.g?blogID=8655567&postID=1748127515840016717 ...Jini code downloading is _not_ RMI code downloading - don't try and use java.rmi.server.codebase - use the starter package in com.sun.jini.start and do it right. And ask for help _before_ you try and do it alone - get your ass onto Jini-Users and ask those dumb "help me" questions so's we can improve installers, write appropriate documentation etc. Dan Creswell
    this kind of suggestions as answers for what appears to be "normal" use of 10+ years old technology makes me nervous and uncomfortable. IMO people should NOT use mailing list for dumb/standard questions like mine, and my expected response for such questions should be RTFM with an appropriate link.
  5. Re: Jini Lookup and Caching[ Go to top ]

    Thanks for the answer.

    But here is my observation:
    I think the jini-users mailinglist would be a better place for your question....


    https://www2.blogger.com/comment.g?blogID=8655567&postID=1748127515840016717

    ...Jini code downloading is _not_ RMI code downloading - don't try and use java.rmi.server.codebase - use the starter package in com.sun.jini.start and do it right. And ask for help _before_ you try and do it alone - get your ass onto Jini-Users and ask those dumb "help me" questions so's we can improve installers, write appropriate documentation etc.

    Dan Creswell


    this kind of suggestions as answers for what appears to be "normal" use of 10+ years old technology makes me nervous and uncomfortable.

    IMO people should NOT use mailing list for dumb/standard questions like mine, and my expected response for such questions should be RTFM with an appropriate link.
    And that would be fair if: (1) We had had enough experience with enough newbies to be able to figure out what the common RTFM/FAQ type questions were. In the case where you cite me below, notice that I say: "ask those dumb "help me" questions so's we can improve installers, write appropriate documentation etc." (2) We had unlimited (and qualified) resources to spend writing all the documentation, books, articles etc that people want/need. (3) If we'd gotten enough leverage to get articles, books etc published. Think about how linux has grown up - when do you think things changed enough that you didn't have to ask newbie questions on a list? It's only relatively recently and even more recently if you were a wannabe kernel developer in which case for the most part you were told "read the code". How long has Ubuntu been around? Notice that, having seen your question and the code-downloading questions, we the community are responding and starting to construct appropriate documentation etc by working with you. Further you got an answer and in good time, does it really matter that it came from an "unusual" direction? I must say I think you are being rather unfair in your assessment - J2EE get's a lot more airtime because the majority have been focused there - not because of it's age. And this leads to all good things like lots of tools, lots of vendors, lots of tradeshows, lots of book etc. Jini is not dis-similar in age but it's had less airtime leading to fewer of the good things you're used to.
  6. Re: Jini Lookup and Caching[ Go to top ]

    I think you are being rather unfair in your assessment - J2EE get's a lot more airtime because the majority have been focused there - not because of it's age. And this leads to all good things like lots of tools, lots of vendors, lots of tradeshows, lots of book etc. Jini is not dis-similar in age but it's had less airtime leading to fewer of the good things you're used to.
    Dan, this isn't directed at you obviously, but in general, as long as JINI is positioned "against" J2EE/Java EE, then it will do poorly. If companies have adopted Java EE, then JINI should find uses in supporting those infrastructures, making them more cost-effective, simpler to deploy and manage, and more effective to use. My $.02 anyway. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  7. Re: Jini Lookup and Caching[ Go to top ]

    I think you are being rather unfair in your assessment - J2EE get's a lot more airtime because the majority have been focused there - not because of it's age. And this leads to all good things like lots of tools, lots of vendors, lots of tradeshows, lots of book etc. Jini is not dis-similar in age but it's had less airtime leading to fewer of the good things you're used to.


    Dan, this isn't directed at you obviously, but in general, as long as JINI is positioned "against" J2EE/Java EE, then it will do poorly. If companies have adopted Java EE, then JINI should find uses in supporting those infrastructures, making them more cost-effective, simpler to deploy and manage, and more effective to use. My $.02 anyway.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
    Hi Cameron, Sorry, I should clarify myself - I'm not pitting Jini against J2EE. Rather I'm giving an example of how one technology can have advantages over another in terms of available training material, sophistication of support etc. Hope that's clearer, Dan.
  8. Re: Jini Lookup and Caching[ Go to top ]

    ..Dan, this isn't directed at you obviously, but in general, as long as JINI is positioned "against" J2EE/Java EE, then it will do poorly. ...
    Yes, it was not aimed at Dan or another particular person at all. I (Jini believer for the records) rather tried to point at general attitude that does not seem to be beneficial to the adoption and promotion of Jini. For example I have incredibly good case for applying Jini to simplify vast maze of J2EE servers and “services”, but promoting Jini solution is not going well because of very obvious knowledge availability and maintenance concerns. And advices to “always ask the user mail-list” do not add confidence at all. Please bear with me I will try to explain: situation with Jini is somewhat absurd: Jini is standard, Jini has books, Jini has online tutorials… and still the general advice is to go to the mail-list. Not to the FAQ, not to the Jini Wiki, not to a section on jini.org site, not to a section of Jini vendor site, but to the mail list itself. That does not make sense in the year 2007 and for a technology which is alive for more than 10 years and has faithful followers. Dan, I am sure that you and others try to do the beast: all I try to say is that the mail-list centered approach is harmful to the Jini marketing and that necessity to go to mail-list is over stated: there are resources available, but somehow (perhaps habitually) the Jini guru’s still point to the list as primary resource. From what I have seen the user-list has already enough material to make a good Wiki based FAQ and Google co-op (http://www.google.com/coop/) makes it possible for Jini advocates to create great resource for newbies. The user mail list will be even more valuable because questions will be filtered through portal of knowledge and answers will become very short for the most part: simply a reference to something external. It benefits requester and person who answers. Just look at the Hibernate forum as example of such strategy working really well (see for example http://forum.hibernate.org/viewtopic.php?t=959529&highlight= ) And let me stress again that it was _I_ was upset to get “ask the list” for a question that _I_ perceived to be “standard” question. I expected to get pointer to material similar to the Cameron’s Coherence tutorial and with tips regarding development environment differences http://wiki.tangosol.com/display/COH32UG/Production+Checklist Sincerely, Konstantin
  9. Re: Jini Lookup and Caching[ Go to top ]

    ..Dan, this isn't directed at you obviously, but in general, as long as JINI is positioned "against" J2EE/Java EE, then it will do poorly. ...

    Yes, it was not aimed at Dan or another particular person at all.

    I (Jini believer for the records) rather tried to point at general attitude that does not seem to be beneficial to the adoption and promotion of Jini.
    Ah, don't worry I didn't take it personally. Much more interested in digging around in the "why" of your reply which we're doing now, and that's all good.

    For example I have incredibly good case for applying Jini to simplify vast maze of J2EE servers and “services”, but promoting Jini solution is not going well because of very obvious knowledge availability and maintenance concerns. And advices to “always ask the user mail-list” do not add confidence at all. Please bear with me I will try to explain: situation with Jini is somewhat absurd: Jini is standard, Jini has books, Jini has online tutorials… and still the general advice is to go to the mail-list. Not to the FAQ, not to the Jini Wiki, not to a section on jini.org site, not to a section of Jini vendor site, but to the mail list itself.
    That does not make sense in the year 2007 and for a technology which is alive for more than 10 years and has faithful followers.
    Dan, I am sure that you and others try to do the beast: all I try to say is that the mail-list centered approach is harmful to the Jini marketing and that necessity to go to mail-list is over stated: there are resources available,
    So which are your favourite resources? Why am I asking this? Surely Jini-guru Dan should already know? Maybe I do but, because I'm a guru (apparently) I'm maybe not the best person to provide pointers to documentation because I know too much! My favourite documentation is the Javadoc and the code! which is definitely not what we want, right? Okay, so what are your (non-guru?) favourite resources?
    but somehow (perhaps habitually) the Jini guru’s still point to the list as primary resource.

    From what I have seen the user-list has already enough material to make a good Wiki based FAQ and Google co-op (http://www.google.com/coop/) makes it possible for Jini advocates to create great resource for newbies. The user mail list will be even more valuable because questions will be filtered through portal of knowledge and answers will become very short for the most part: simply a reference to something external. It benefits requester and person who answers. Just look at the Hibernate forum as example of such strategy working really well (see for example http://forum.hibernate.org/viewtopic.php?t=959529&highlight= )

    And let me stress again that it was _I_ was upset to get “ask the list” for a question that _I_ perceived to be “standard” question. I expected to get pointer to material similar to the Cameron’s Coherence tutorial and with tips regarding development environment differences http://wiki.tangosol.com/display/COH32UG/Production+Checklist

    Sincerely, Konstantin
    Thanks for the pointers and the feedback - I'll check those out. Best, Dan.
  10. Re: Jini Lookup and Caching[ Go to top ]

    ...Okay, so what are your (non-guru?) favourite resources?...
    I have used GigaSpaces site http://www.gigaspaces.com/wiki/dashboard.action and Jini tutorial: http://jan.netcomp.monash.edu.au/java/jini/tutorial/Jini.xml As you can see it is not much of a collection :(
  11. Re: Jini Lookup and Caching[ Go to top ]

    I have used GigaSpaces site and Jini tutorial.. As you can see it is not much of a collection :(
    Well, I'd pay Dan to doc it and I'd provide the Wiki and hosting ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  12. Re: Jini Lookup and Caching[ Go to top ]

    Konstantin
    I have used GigaSpaces site http://www.gigaspaces.com/wiki/dashboard.action
    and Jini tutorial:
    http://jan.netcomp.monash.edu.au/java/jini/tutorial/Jini.xml

    As you can see it is not much of a collection :(
    I'm not sure if you are aware of the following: http://www.gigaspaces.com/wiki/display/GS/About+Jini http://www.gigaspaces.com/docs/JiniApi/index.html http://www.gigaspaces.com/docs/JavaDocSG/rio/index.html Having said that I think that most of what you need to build a jini application is simplified and abstracted significantly through the rio framework which BTW support deployment of Spring based application. It provides light weight SLA driven container for building Services and it includes many useful features ontop and above Jini such as POJO services, Distributed Dependency Injection, SLA driven deployment etc. I would recommend using that framework rather then starting with low level jini development something that you can always choose to do at any point of time. As you would imagine our product contains an enhanced version of that framework that is built-in with our product and is fully documented as well to ensure smooth start with the technology. I would welcome any suggestion for improvements, comments and obviously contribution from anyone in the community. Simply send me a direct email. Nati S. GigaSpaces http://www.gigaspacesblog.com/