Ticket #775 (closed enhancement: fixed)

Opened 1 year ago

Last modified 3 months ago

mulgara connects to pub-app on random high port for ehcache, should use specified port 8111

Reported by: russ Assigned to: pag
Priority: high Milestone: 0.9.1
Component: topaz-mulgara Version: 0.8.3-SNAPSHOT
Keywords: ehcache Cc:
Blocking: Blocked By:

Description

ronald says:

That sounds about right: mulgara needs to send updates (invalidations) to the pubapp caches. The port that ehcache allows you to configure is the RMI-registry port; unfortunately it doesn't allow you to configure the listener port used for the actual communications. I think I was going to file a bug and patch for this, but I don't think I ever got around to it - nope, just checked, I never filed a bug or patch.

Dependency Graph

Change History

01/30/08 08:59:35 changed by amit

  • version changed from 0.8.2.1-SNAPSHOT to 0.8.3-SNAPSHOT.
  • milestone set to 0.9.0.

01/30/08 09:38:21 changed by pradeep

Additional details from Russ: 

my recollection is that, even with port 8111 opened on the pubapps,
mulgara was initiating a connection to a high port on the pub-apps as
well for ehcache related stuff.

[root@plostopaz01 plos]# netstat -n | grep 192.168.66.20
tcp        0      0 192.168.66.17:33992         192.168.66.20:9091
ESTABLISHED
tcp        0      0 192.168.66.17:53962         192.168.66.20:39259
ESTABLISHED

[root@plostopaz01 plos]# /etc/init.d/plosone status
plosone (30744) is running from /usr/local/topaz/plosone
  PID USER      RSS %MEM     ELAPSED     TIME %CPU COMMAND
30744 topaz    2045952 25.0 05:37:53 00:32:10  9.5 java
java    30744 topaz   17u  IPv4 1182790       TCP *:8111 (LISTEN)
java    30744 topaz   19u  IPv4 1182793       TCP *:53962 (LISTEN)

i think port 53962 is an ehcache listener on the pub-app that mulgara
has initiated a connection to.

02/06/08 00:28:00 changed by ronald

Bug/feature-request submitted: http://sourceforge.net/tracker/index.php?func=detail&aid=1887683&group_id=93232&atid=603559

04/03/08 14:49:35 changed by amit

  • milestone deleted.

(follow-up: ↓ 6 ) 04/22/08 12:47:29 changed by russ

  • blocking changed.
  • blockedby changed.

odd that this is the case for mulgara->ambra communication, but not for ambra<->ambra communication.

cache synchronization on the ambra servers is all done via multicast. why do we need to go over unicast for mulgara's invalidation?

would we be better off not assigning a port at all?

(in reply to: ↑ 5 ) 04/22/08 16:50:43 changed by ronald

Replying to russ:

odd that this is the case for mulgara->ambra communication, but not for ambra<->ambra communication.

What, the random port? No, that exists for all.

cache synchronization on the ambra servers is all done via multicast. why do we need to go over unicast for mulgara's invalidation?

No, multicast is used only to discover the other caches; cache notifications themselves are sent via normal tcp.

would we be better off not assigning a port at all?

That's up to you?

But just so things are clear: we now have

  • rmi from any ambra to any other ambra (ehcache updates)
  • rmi from mulgara to ambra (ehcache invalidations)
  • rmi from ambra to mulgara (mulgara api calls)

This means that yes, right now, all ports need to be open in both directions between both ambra and ambra, and between ambra and mulgara.

If this is a high enough priority and resources get assigned to it, we can patch both mulgara and ehcache to be able to configure the ports used for the actual rmi calls (as opposed to just those used for the rmi-registry). It'll probably take a couple days for mulgara and a day for ehcache.

05/05/08 16:33:48 changed by ronald

Ehcache 1.5 will have the option to set the listener port too: http://sourceforge.net/tracker/index.php?func=detail&aid=1887683&group_id=93232&atid=603562

07/31/08 23:58:38 changed by amit

  • milestone set to 0.9.1.

1.5 had been released, so we need to upgrade here for the fix.

09/08/08 16:19:34 changed by dragisak

  • owner changed from ronald to amit.

09/09/08 11:28:20 changed by amit

(In [6390]) Updated ehcache to 1.5.0. The new version has a number of fixes and performance improvments. Please see 1.5.0 release announcement at http://ehcache.sourceforge.net/news.html.

This also addresses #775.

09/10/08 17:01:11 changed by amit

  • type changed from task to enhancement.

09/19/08 00:00:03 changed by amit

  • owner changed from amit to pag.
  • priority changed from low to high.

Paul, your first ticket.

09/25/08 13:38:15 changed by pag

  • status changed from new to closed.
  • resolution set to fixed.

Ronald tells me that all Mulgara needs is to configure the client peer port for RMI communications. This can now be done by either of:

  • setting the mulgara.rmi.peerPort system property to the desired port number.
  • setting the -t switch for the CLI to the desired port number (this overrides the system property).

If Mulgara has been started before the system property can be set, then a call can be made to the static method:

org.mulgara.util.Rmi.setDefaultPort(int)

09/26/08 01:15:36 changed by ronald

  • status changed from closed to reopened.
  • resolution deleted.

I think we need to wait with closing this until we've tied up the loose ends:

  1. a new mulgara has been released and we've upgraded to it
  2. we've updated our Mulgara startup scripts (packages/topaz-mulgara/...) to specify -t
  3. We've updated the Ehcache configs to set the remoteListenerPort appropriately

09/26/08 23:42:36 changed by amit

  • status changed from reopened to new.

Agreed. Paul, this is still on your plate to get rest of the pieces in place to close this.

10/22/08 23:04:46 changed by pag

  • status changed from new to closed.
  • resolution set to fixed.

(In [6563]) Added in the option to use RMI objects on port 8111. This is the final part to close #775