Hi Brian,

I wouldn't describe this as Basic JMX :-)

If you start a timer on each node then the
notification will happen on each machine.

There is no spec defined mechanism for
dealing with this sort of problem.
This will have to considered when
we write the EJB2.1 timer service.

There are a number of ways of dealing
with this, it depends on what you are
trying to achieve.

1) Hold some distributed state saying when
the last run was (this could be in the
database), only do the entity bean call
if the run was not within a certain period.

2) Elect a master node.
Javagroups has the notion of a controller
which is the oldest node in the cluster.
Only do the entity bean call if you are
the master.

3) Write a distributed timer service.
The timer service has the notion of a
"notification sequence".
The distributed timer would
only fire events if the sequence
had not been triggered on some
other node.
And perform some sort of wait while one node
is notifying in case it fails during the
notification.
Slow nodes and new nodes would have to
keep in step with the latest sequence.

Regards,
Adrian

From: "Brian McSweeney" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
Subject: Re: [JBoss-user] Basic JMX question
Date: Mon, 24 Feb 2003 10:33:59 -0000

Hi Adrian,
thanks very much for your answers. I have a few little questions
about the clustering answers that perhaps you can give me
advice on.

> You will find many adaptors/connectors already implemented,
> jboss has rmi/ejb/html and jboss.net versions.
> The html and ejb versions should work with clustering if
> suitably configured, but the MBean state is not
> replicated across the cluster.
>
> JBoss4/jbossmx standalone already has what will become our
> implementation of jsr160 - JBoss Remoting

I have an MBean which I want to receive timed notifications from
the Timer service. When it is notified I want the MBean to change
the state of an Entity bean. This is fine on a single jboss version, but
what I'd like some advice on, is how clustering will affect this. If I
cluster and have one MBean for every box that does the same thing,
will the Entity beans state get changed several times? Will each MBean
get notified by a separate timer service each of which may become out
of sync?

what would your advice be?

thanks very much again,
Brian

----- Original Message -----
From: "Adrian Brock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 19, 2003 6:16 PM
Subject: Re: [JBoss-user] Basic JMX question


> Hi Brian,
>
> Answers in line.
>
> >From: "Brian McSweeney" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: <[EMAIL PROTECTED]>
> >Subject: [JBoss-user] Basic JMX question
> >Date: Wed, 19 Feb 2003 16:03:24 -0000
> >
> >Hi all,
> >yet again in my quest to write container independent code, I'm stuck. :-)
> >
> >I want to use the Timer service in a container independent manner. The
> >sheduler services for example isn't container independent :-(.
> >
> >So, the first problem I have here is, I need to get a reference to the
> >MBeanServer
> >object. Now I know that JMX isn't standard in J2EE until version 1.4 but
> >does the code
> >
> >MBeanServerFactory.findMBeanServer(null);
>
> Yes, the other method is for your MBean to
> implement javax.management.MBeanRegistration
> This is how jboss's ServiceMBeanSupport provides
> the getServer() method.
>
> >
> >work in JBoss? If so, at least I'll be writing forward compatable code
:-)
> >Also,
> >I think Weblogic uses JMX already too so this might work too.
> >
> >also, is an MBeanServer per jvm? What happens when you cluster?
>
> The MBeanServer is a purely local concept (same jvm)
> The standard for remote access to an MBeanServer (jsr160)
> has has not been released for public review yet.
>
> You will find many adaptors/connectors already implemented,
> jboss has rmi/ejb/html and jboss.net versions.
> The html and ejb versions should work with clustering if
> suitably configured, but the MBean state is not
> replicated across the cluster.
>
> JBoss4/jbossmx standalone already has what will become our
> implementation of jsr160 - JBoss Remoting
>
> >
> >thanks,
> >Brian
>
>
> _________________________________________________________________
> Overloaded with spam? With MSN 8, you can filter it out
>
http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
>





------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user


_________________________________________________________________
Overloaded with spam? With MSN 8, you can filter it out http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to