Re: [Shoal-Dev] One GroupManagementService has its own NetworkManager in branches(ABSTRACTING_TRANSPORT), isn't it?

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Bongjae Chang <bongjae.chang_at_gmail.com>
Date: Thu, 29 Apr 2010 18:59:27 +0900

Hi Joe,

Thank you for reviewing it.

So I committed the patch(branches/SHOAL_1_1_ABSTRACTING_TRANSPORT, rev. 913).

Thanks.

Regards,
Bongjae Chang

  ----- Original Message -----
  From: Joseph Fialli
  To: dev_at_shoal.dev.java.net
  Sent: Thursday, April 29, 2010 4:17 AM
  Subject: Re: [Shoal-Dev] One GroupManagementService has its own NetworkManager in branches(ABSTRACTING_TRANSPORT), isn't it?

  Comments inline below.

  On 4/28/10 4:55 AM, Bongjae Chang wrote:
    Hi,

    For now, several GroupManagementService instances in the same JVM share one NetworkManager instance.
  This is definitely a bug. I agree with your assessment. Please commit your proposed change.

  -Joe

    ClusterManager uses AbstractNetworkManager#getInstance(String transport) to get its NetworkManager.

    However, AbstractNetworkManager always returns the same NetworkManager instance in the same JVM, because it has static field, ��networkManager��.

    I think it should not be static because there can be a couple of GroupManagementService instances and each of them must have its own NetworkManager instance in a JVM.

    i.g.
    - When there exist two GMSs which would like to join two different groups in a JVM
    - When someone would like to test different transport layers(Jxta, Grizzly, etc...) in a JVM by UnitTest - this is my case. :-)

    So I attached the simple diff of AbstractNetworkManager.java which does not use static field for NetworkManager.

    What do you think?

    Regards,
    Bongjae Chang