• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Rendezvous and WebObjects vs OpenJMS
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rendezvous and WebObjects vs OpenJMS


  • Subject: Re: Rendezvous and WebObjects vs OpenJMS
  • From: David Aspinall <email@hidden>
  • Date: Thu, 20 May 2004 11:24:16 -0400

Jms was and is a great technology. My issues using it for change notification are:

- the HSQLDB database only truncates disk usage when the service is restarted. In a high volume deployment this grows very large over one day (while not a disk issue it does slow things down .. or at least seems to). I could use a SQL database but that seems to defeat the purpose of not having a database fetch involved in the CN. Also, given the volume, do I really want that load on my business system? My answer might be different if the messages were not so ephemeral.

- sending change snapshots is very efficient in small numbers (each interested application can incorporate the changes without having to incur a fetch) However, in high volume with several applications the Jms can really fall behind and be out of date. I did not size the messages, but if the growth of the HSQLDB is an indication it was a problem. Realistically only 2 - 3 instances are interested in the changing values of any particular record. Very little data in our system is public to all users, but there are several collaborative areas where it is important to be in sync.

- so we switch to passing only EOGlobalId's which is more efficient from a messaging side and not that bad on the recipient side. Each recipient (client) checks the database context snapshots. If the object has a current snapshot then the record for that EOGlobalId is forced to refault, but does not fetch until needed. So if the user has gone away or does not navigate to a page needing that record, then it is never refetched.

So that is where we are now, small specific messages over OpenJMS, with cron jobs to force an OpenJMS restart every night. The final issue is with OpenJMS stability in multiple deployments. We use Windows 2000, Mac, RedHat and Debian. The windows service is the one I am least happy with (that may just be my natural aversion to all things M$oft), but the service disappears on all deployments periodically. I could write a guard script that would auto-restart OpenJMS if it dies, but I am thinking UDP Multicast or non-deterministic grid style communications would be better.

Just my $0.02
David
---
email@hidden
(416) 513-9524 x263

Ticoon Technology Inc.
56 The Esplanade, Suite 404, Toronto, ON, M5E 1A7



On 20-May-04, at 3:34 AM, Sam Hart wrote:

David wrote:

For the past year we have been using openJms for change notification,
but we are not 100% happy with the results.  I wont go into the issues
here

thats a shame, I am keen to know what problems you are seeing or what issues it is creating for you.

but I am experimenting with options.

I spent a lot of time trying different options out before I settled on messaging.


I am however looking at some point replacing OpenJMS with another free JMS which appears more stable.

My question is: does anyone have good or bad experiences using
Rendezvous (ZeroConf) with WebObjects applications?

I have used multicast based change notification before, didn't rate it.

It's far too flakey compared to messaging.


S a m
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >Re: Rendezvous and WebObjects (From: Sam Hart <email@hidden>)

  • Prev by Date: Re: Xcode 1.2 generates incorrect web.xml.template
  • Next by Date: Re: Encrypting Credit Card Numbers - Two Way Encryption
  • Previous by thread: Re: Rendezvous and WebObjects
  • Next by thread: Re: Rendezvous and WebObjects
  • Index(es):
    • Date
    • Thread