To test whether multicast IP is working properly you can use two small test programs provided in the JGroups package (org.jgroups.tests): McastReceiverTest and McastSenderTest found in <jboss_home>/server/all/lib.

To test whether multicast is setup correctly, start the receiver:

java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.0.0.4 -port 10520

and then start the sender:

java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr 230.0.0.4 -port 10520


If that doesn’t work, you should first establish whether multicast networking is properly enabled for your host.  This can be done via the following network-level tests.  Start tcpdump to listen for traffic:

$ sudo tcpdump -ni en1 host 230.0.0.4

where ‘en1′ is the name of a network interface (see ifconfig -a or ipconfig -a for a list of network interfaces for your host). Then send out some pings on the multicast address:

$ ping -t 1 -c 2 230.0.0.4

In all of these examples I’m using the multicast address of 230.0.0.4.  Yours maybe different but should be in the range: 224.0.0.0 – 239.255.255.255

Here’s how.

(Note. this applies to Eclipse-based GAE projects).  In your Eclipse project the datastore (and datastore related info) is kept in the directory <project>/war/WEB-INF/appengine-generated.  To have each project share the same datastore is to have each project share this same directory.  On a Mac this easy: just create a master directory for this somewhere (preferably outside the scope of the projects) and then in each project create symbolic link to this directory.

Why would you want to do this?

For anything but the most trivial application you’ll likely have the application partitioned into different silos.  For example, I’m developing an application which has a Webservices API, a GWT-based (GUI) interface for the user and a separate GWT-based interface for the administrator.  All three share a common POJO data model (and underlying data) and some business logic but thats about all.  For security, scalability, safety and reliability reasons I wanted all three silos packaged into separate packages (war files) yet still have each independently deployed silo be able to share data with the others.  In other words, they need to share a GAE datasource between them.  But if the silos are deployed to their own applicationID in GAE then they are each assigned their own datasource and they won’t be able to share data.

How is it done?

The trick to allowing separate packages to share the same datasource is to deploy the different packages (wars) under the same applicationID and to assign each package its own version to avoid each deployment overwriting other deployments.  Fortunately in GAE, version labels are not just numeric they can be alphanumeric and thus mnemonics can be assigned that reflect what the ‘version’ corresponds to. For example you could choose applicationID=’myapp’ (which maps to http://myapp.appspot.com) and then for the webservices silo use version=’webservices’ and for the client GUI part use version=’client’.  This would result in the following URL namespace for your app:

http://webservices.myapp.appspot.com for the webservices package, and

http://client.myapp.appspot.com for the client GUI package.

Since all the deployed bundles (wars) share the same applicationID they can all access the same datasource and can thus share persistent data.  And since each deployment bundle has its own version, each can be addressed independently and directly via http.

Just remember that the datastore is much more lenient when it comes to data schemas so you’ll need to ensure that access to the persistent shared datastore is done through the same set of POJOs across each silo in order to preserve the data’s consistency (schema level).  The best way to implement that is to have a common datamodel package that each silo uses.

Camac IT is proud to be officially recognized by OSGi as an Alliance Supporter.  More news to follow later.

Security Audit Report: camacit_audit_report.pdf

The OSS (Operations Support Systems) through Java Initiative is developing a set of standard Java APIs for end-to-end services on next-generation wireless networks, which will facilitate the convergence of telecommunications and Internet-based solutions. Since CORBA is used in much of the existing telecommunications infrastructure that is to be accessed by OSS/J systems, it is important that techniques for interworking the J2EE platform with CORBA-based systems be documented for developers of OSS/J systems.

WhitePaper: com-arch-corbav2-10.pdf

Illustrative code: com-arch-corba-codeexamples.zip

WhitePaper: using_native_messaging.pdf

VisiNotify is Borland’s implementation of the OMG’s CosNotification service for CORBA. This service was designed to provide CORBA applications with asynchronous messaging capabilities which are a very powerful design technique for large-scale applications. (27 pages with code examples. December 2002)

Research Paper: using_ejbs_with_visinotify.pdf

Illustrative code: code_examples.zip