You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by AndyG <an...@orprovision.com> on 2012/06/12 17:31:54 UTC
Added new 'multipulse' discovery, and a few fixes.
Added new 'multipulse' discovery, and a few fixes.
Fixes:
ServiceDaemon.java - Must close the server socket even if it does not get a
lock.
ServiceManager.java - Revert 'conf.d' in path. If this is a 'tomee'
requirement then it needs to be checked?
EjbDaemon.java - Ensure streams are closed on failure. Log client induced
errors as warning (Should probably add error filtering).
SocketConnectionFactory.java - Use configured timeout variable. Also added a
configurable default socket connection timeout of 150ms (Which is long
enough to connect to just about any server on the planet over TCP/IP these
days).
MultiPulse:
For use where client and server can 'multicast' and a constant heartbeat is
not required or wanted.
The server listens on a defined multicast channel for a client request (A
single pulse).
A client sends a pulse (packet) on the defined channel.
The server responds with a crafted packet which 'can' contain all known
hosts (for multihomed systems use '0.0.0.0' or '[::]' for the ejbd
'discovery' property), or just the defined value.
The client attempts connections to the server hosts until a valid connection
is made, discarding any bad URIs.
--
View this message in context: http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Looks great, thanks.
Le 13 juin 2012 14:56, "AndyG" <an...@orprovision.com> a écrit :
> Thanks, I think I have it now
>
>
> Romain Manni-Bucau wrote
> >
> > Btw, im interested in a way to know all servers of a cluster in tomee,
> any
> > ideas?
> >
>
> I think 'org.apache.catalina.tribes.membership.McastService' will get you
> what you need?
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565p4655587.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by AndyG <an...@orprovision.com>.
Thanks, I think I have it now
Romain Manni-Bucau wrote
>
> Btw, im interested in a way to know all servers of a cluster in tomee, any
> ideas?
>
I think 'org.apache.catalina.tribes.membership.McastService' will get you
what you need?
--
View this message in context: http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565p4655587.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi, just checkout the site from svn, add your file in md then log on
cms.apache.org (openejb project) and push update button.
Btw, im interested in a way to know all servers of a cluster in tomee, any
ideas?
- Romain
Le 13 juin 2012 10:52, "AndyG" <an...@orprovision.com> a écrit :
>
> David Blevins-2 wrote
> >
> > Don't forget to create the applicable jiras.
> >
>
> Socket timeout:
>
> https://issues.apache.org/jira/browse/OPENEJB-1839
>
> and...
>
> MultiPulse:
>
> https://issues.apache.org/jira/browse/OPENEJB-1838
>
> I know I should be able to work it out myself, but just haven't had the
> time
> to look into the site CMS. Is there a howto? I don't even know where to
> login .
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565p4655584.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
One note about it: do we want to keep tomee and tomcat conf file together
or not?
Le 14 juin 2012 09:09, "AndyG" <an...@orprovision.com> a écrit :
>
> David Blevins-2 wrote
> >
> > No worries. Was more looking for some discussion starting descriptions
> :)
> > It might make for good docs, but we don't need to be that formal that
> > fast.
> >
>
> The jira https://issues.apache.org/jira/browse/OPENEJB-1838 is quite
> extensive, I will try out some docs later.
>
> As far as the config files are concerned. I prefer all files in the same
> directory, and can only suggest a prefix to aid identification / grouping
> if
> that's required - Something like.
>
> conf
> |--resource.bar.xml
> |--service.foo.properties
>
> I just know I hate the way Suse throws tomcat config files all over the
> file
> system (rather than creating links all over the file system) and hope we
> don't ever go that way.
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565p4655612.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by AndyG <an...@orprovision.com>.
David Blevins-2 wrote
>
> No worries. Was more looking for some discussion starting descriptions :)
> It might make for good docs, but we don't need to be that formal that
> fast.
>
The jira https://issues.apache.org/jira/browse/OPENEJB-1838 is quite
extensive, I will try out some docs later.
As far as the config files are concerned. I prefer all files in the same
directory, and can only suggest a prefix to aid identification / grouping if
that's required - Something like.
conf
|--resource.bar.xml
|--service.foo.properties
I just know I hate the way Suse throws tomcat config files all over the file
system (rather than creating links all over the file system) and hope we
don't ever go that way.
--
View this message in context: http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565p4655612.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by David Blevins <da...@gmail.com>.
On Jun 13, 2012, at 1:51 AM, AndyG wrote:
> I know I should be able to work it out myself, but just haven't had the time
> to look into the site CMS. Is there a howto? I don't even know where to
> login .
No worries. Was more looking for some discussion starting descriptions :) It might make for good docs, but we don't need to be that formal that fast.
-David
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by AndyG <an...@orprovision.com>.
David Blevins-2 wrote
>
> Don't forget to create the applicable jiras.
>
Socket timeout:
https://issues.apache.org/jira/browse/OPENEJB-1839
and...
MultiPulse:
https://issues.apache.org/jira/browse/OPENEJB-1838
I know I should be able to work it out myself, but just haven't had the time
to look into the site CMS. Is there a howto? I don't even know where to
login .
--
View this message in context: http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565p4655584.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Added new 'multipulse' discovery, and a few fixes.
Posted by David Blevins <da...@gmail.com>.
Sounds interesting. Will definitely have a look later. Don't forget to
create the applicable jiras.
Curious on some of the background on what lead you down this path. Issues
faced with multipoint and so on. Would be good for docs (recommending which
to use when) and good for discussion.
-David
On Tuesday, June 12, 2012, AndyG wrote:
> Added new 'multipulse' discovery, and a few fixes.
>
> Fixes:
> ServiceDaemon.java - Must close the server socket even if it does not get a
> lock.
> ServiceManager.java - Revert 'conf.d' in path. If this is a 'tomee'
> requirement then it needs to be checked?
> EjbDaemon.java - Ensure streams are closed on failure. Log client induced
> errors as warning (Should probably add error filtering).
> SocketConnectionFactory.java - Use configured timeout variable. Also added
> a
> configurable default socket connection timeout of 150ms (Which is long
> enough to connect to just about any server on the planet over TCP/IP these
> days).
>
> MultiPulse:
> For use where client and server can 'multicast' and a constant heartbeat is
> not required or wanted.
> The server listens on a defined multicast channel for a client request (A
> single pulse).
> A client sends a pulse (packet) on the defined channel.
> The server responds with a crafted packet which 'can' contain all known
> hosts (for multihomed systems use '0.0.0.0' or '[::]' for the ejbd
> 'discovery' property), or just the defined value.
> The client attempts connections to the server hosts until a valid
> connection
> is made, discarding any bad URIs.
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: Config fragments
Posted by AndyG <an...@orprovision.com>.
Yea, that was kind of dumb of me
Now I know what the score is I have put in some guess work.
--
View this message in context: http://openejb.979440.n4.nabble.com/Added-new-multipulse-discovery-and-a-few-fixes-tp4655565p4655651.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Config fragments
Posted by Romain Manni-Bucau <rm...@gmail.com>.
for me there is no more regression so that's fine
just we can talk about our conf.
here the topics i see:
1) where? conf but subfolder or not?
2) what? currently we have properties, "properties-xml" but do we want sthg
else? i think inparticular to jaxrs where we can configure object using
properties an a hierarchy (but please no xml) could be nice: yaml for
instance
- Romain
2012/6/15 Jean-Louis MONTEIRO <je...@gmail.com>
> Just a small note: we activated again the conf.d/ at the hotel cause our
> live demo stopped working :D
> Another note: this directory works with 1.0.x so if we revert it will break
> compatibility. Not a big issue IMHO because no much people uses it, but we
> have to keep it in mind.
>
> Andy review the algorithm after our change and it looks pretty good now
> with both directories.
> Any issue to live that as it is today?
>
> JLouis
>
>
>
> 2012/6/14 Romain Manni-Bucau <rm...@gmail.com>
>
> > i'd like to keep services and resources separated
> >
> > conf
> > -- server.d (current conf.d)
> > -- resource.d
> >
> > etc
> >
> > - Romain
> >
> >
> > 2012/6/14 David Blevins <da...@gmail.com>
> >
> > >
> > > On Jun 12, 2012, at 8:31 AM, AndyG wrote:
> > >
> > > > ServiceManager.java - Revert 'conf.d' in path. If this is a 'tomee'
> > > > requirement then it needs to be checked?
> > >
> > > Fair enough :) That feature was added without much discussion.
> > Something
> > > we should probably improve a bit.
> > >
> > > There is a jira at least:
> > >
> > > https://issues.apache.org/jira/browse/OPENEJB-1791
> > >
> > > The goal is to provide a place where fragments of config can be placed.
> > > Currently it supports the <foo-service>.properties files. In the
> future
> > > it could support a file containing just an "<Resource>" declaration.
> > >
> > > That's the idea.
> > >
> > > Thoughts about such a feature? (question directed at everyone)
> > >
> > >
> > > -David
> > >
> > >
> >
>
Re: Config fragments
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Just a small note: we activated again the conf.d/ at the hotel cause our
live demo stopped working :D
Another note: this directory works with 1.0.x so if we revert it will break
compatibility. Not a big issue IMHO because no much people uses it, but we
have to keep it in mind.
Andy review the algorithm after our change and it looks pretty good now
with both directories.
Any issue to live that as it is today?
JLouis
2012/6/14 Romain Manni-Bucau <rm...@gmail.com>
> i'd like to keep services and resources separated
>
> conf
> -- server.d (current conf.d)
> -- resource.d
>
> etc
>
> - Romain
>
>
> 2012/6/14 David Blevins <da...@gmail.com>
>
> >
> > On Jun 12, 2012, at 8:31 AM, AndyG wrote:
> >
> > > ServiceManager.java - Revert 'conf.d' in path. If this is a 'tomee'
> > > requirement then it needs to be checked?
> >
> > Fair enough :) That feature was added without much discussion.
> Something
> > we should probably improve a bit.
> >
> > There is a jira at least:
> >
> > https://issues.apache.org/jira/browse/OPENEJB-1791
> >
> > The goal is to provide a place where fragments of config can be placed.
> > Currently it supports the <foo-service>.properties files. In the future
> > it could support a file containing just an "<Resource>" declaration.
> >
> > That's the idea.
> >
> > Thoughts about such a feature? (question directed at everyone)
> >
> >
> > -David
> >
> >
>
Re: Config fragments
Posted by Romain Manni-Bucau <rm...@gmail.com>.
i'd like to keep services and resources separated
conf
-- server.d (current conf.d)
-- resource.d
etc
- Romain
2012/6/14 David Blevins <da...@gmail.com>
>
> On Jun 12, 2012, at 8:31 AM, AndyG wrote:
>
> > ServiceManager.java - Revert 'conf.d' in path. If this is a 'tomee'
> > requirement then it needs to be checked?
>
> Fair enough :) That feature was added without much discussion. Something
> we should probably improve a bit.
>
> There is a jira at least:
>
> https://issues.apache.org/jira/browse/OPENEJB-1791
>
> The goal is to provide a place where fragments of config can be placed.
> Currently it supports the <foo-service>.properties files. In the future
> it could support a file containing just an "<Resource>" declaration.
>
> That's the idea.
>
> Thoughts about such a feature? (question directed at everyone)
>
>
> -David
>
>
Config fragments
Posted by David Blevins <da...@gmail.com>.
On Jun 12, 2012, at 8:31 AM, AndyG wrote:
> ServiceManager.java - Revert 'conf.d' in path. If this is a 'tomee'
> requirement then it needs to be checked?
Fair enough :) That feature was added without much discussion. Something we should probably improve a bit.
There is a jira at least:
https://issues.apache.org/jira/browse/OPENEJB-1791
The goal is to provide a place where fragments of config can be placed. Currently it supports the <foo-service>.properties files. In the future it could support a file containing just an "<Resource>" declaration.
That's the idea.
Thoughts about such a feature? (question directed at everyone)
-David