[Design of POJO Server] - Re: Controlling deployments via a barrier bean
by adrian＠jboss.org
OFF TOPIC, but on a related issue.
I said a while ago that a real profile service implementation
has a lot in common with JBoss Cache (at least in terms of aspects/technology if
not in implementation :-).
It is a (possibly transacted/distributed) tree like structure with an
abitrary backing store which should be able to scale from standalone to
clustered environments.
Similarly it has requirements to track fine grained changes inside the tree
(changes to the items of metadata - the fields on the managed properties)
and applying them atomically.
Some areas where it differs are that the (sub-)profile is versioned as a whole.
Related to this is that the distribution of the changes has a slightly different
semantic in that changes to the metadata would first be tried locally
or on some staging cluster before distributing the new version across the
production cluster.
There are other parts that are not related to the cache structure, e.g. retrieving statistics
or invoking managed operations like flushing a pool, but these have more
in common with jgroups clustered invocation sematics.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154474#4154474
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154474
15 years, 11 months
[Design of POJO Server] - Re: Controlling deployments via a barrier bean
by adrian＠jboss.org
I think as far as backwards compatibility goes Brian's approach is roughly correct,
but it should NOT be using the MainDeployer directly.
It should be based on a (sub-)profile.
If you look in broad brush terms, the profile service is made up of two components
1) A client side api that lets you define what a profile is
2) A server side that implements that profile at runtime
For the current default profile (hot deployment) that means three pojos that know how
to scan three sets of directories/urls (bootstrap/deployers/deploy)
which are the three sub-profiles that make up the profile.
There should be a way to add extra (sub-)profiles e.g. hasingleton, jbossmq, etc.
that could be based on normal, singleton or farm semantics.
These are just implementation details of how the server side profile is implementated.
In practice, these subprofiles are not implemented in such a flexible way
with the scanners being hardwired along with the subprofiles they represent
and a subprofile is always active.
In terms of where we want to get to in the profile service and metadata in
general, it should be possible using a management console to say
I want this sub-profile, deployment, service, etc. to be a singleton in a given
partition.
I'd say partition is too low level since what you really want is some election policy
which could be generalised beyond the hasingleton notion to some activation policy.
e.g. you activate a deployment based on a timer rather than clustered failover election
By taking a metadata approach, users can also programme this explicitly
without having to use the management console directly.
e.g. I add a META-INF/jboss-activation.xml to describe how/when I want
this deployment starting/stopping
At the service/pojo level this would probably be an annotation
| <bean name="Whatever" ...>
| <annotation>@Singleton policy="DefaultPartitionSingleton"<annotation/>
| ...
|
Which could also be applied via the scoped metadata if you want to
externalise it from the main descriptors in the management console/profile service case.
Short term for now, I'd just go with extending the hot deployment profile service to allow
some kind of barrier service like Brian describes to add/remove a sub-profile dynamically.
I'm not sure it needs to be as complicated as Brian describes though?
i.e. messing around with dependencies
The hasingleton scanner should just respond to the elected/de-elected event
by adding/removing its profile to/from the profile service.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154469#4154469
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154469
15 years, 11 months
[Design of POJO Server] - Re: Controlling deployments via a barrier bean
by scott.stark＠jboss.org
I don't think a dependency is the way this should be handled as its not an optional dependency. Your using a dependency to try to identify the singleton bean in the cluster. Really we don't want the unelected singleton beans to be exposed as available for installation as runtime components.
To properly handle this we would need the ability to expand the states for the component in question to allow for alternate DESCRIBE, DESCRIBE_CLUSTERED, DESCRIBE_SINGLETON states depending on the cluster metadata associated with the bean. Currently the mc state machine does not allow for this choice type of state transition. I have not worked much with the lower level state manipulation so I could also be talking out of my ass, but I think this is the proper way to do it.
Given I don't believe there is proper mc support for this, how to do it? I'm not sure. Any idea I have would mix deployer and kernel bean state management behavior. Need some feedback from Adrian/Ales.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154459#4154459
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154459
15 years, 11 months
[Design of EJB 3.0] - Re: Maven Version Resolution Differences 2.0.8 / 2.0.9
by ALRubinger
Here's my Discussion w/ #maven:
"#maven" wrote : (03:04:49 PM) ALR: Hi, #Maven. I've found a difference in dependency resolution between 2.0.8 and 2.0.9, and was hoping someone could help me nail down an isolated use case to submit as a bug report.
| (03:05:49 PM) Brian: ALR: what's the difference?
| (03:06:04 PM) ALR: Brian: Preparing a Pastebin
| (03:06:08 PM) Brian: the only major change i can think of is that the order in the pom is preserved now making it deterministic
| (03:06:59 PM) ALR: Brian: http://pastebin.com/d7e7a4297
| (03:07:02 PM) Brian: we worked pretty hard to ensure there were no regressions between .8 and .9 so my money's on that
| (03:07:56 PM) Brian: i don't understand what the issue is based on the paste
| (03:07:58 PM) ALR: Brian: In that code snippit are two sections, the first is using 2.0.8, the second is 2.0.9.
| (03:08:32 PM) ALR: Brian: In 2.0.8 "org.jboss.microcontainer:jboss-container" is found as a dependency, in 2.0.9 it is not.
| (03:08:47 PM) ALR: Brian: Same machine.
| (03:09:21 PM) Brian: ALR do you want it to be found?
| (03:09:22 PM) ALR: Brian: And as help:describe shows, same version of the dependency plugin.
| (03:09:33 PM) ALR: Brian: No, I don't want it to be found.
| (03:09:55 PM) Brian: ok, can you paste the full tree output from both? (no -Dincludes)
| (03:10:05 PM) ALR: Brian: Sure, one moment.
| (03:12:18 PM) ALR: Brian: 2.0.8, then 2.0.9, separated by whitespace: http://pastebin.com/d778daed2
| (03:15:36 PM) Brian: ALR, i'm confused. You said you don't want jboss-container to be found and that it's not found in 2.0.9...what's the problem?
| (03:15:51 PM) ALR: Brian: That is *is* found in 2.0.8.
| (03:16:21 PM) ALR: Brian: What I want should be irrelevant; my concern is that the build is dependent upon the version of Maven being used.
| (03:17:08 PM) ALR: Brian: So if I'm using 2.0.9, and someone else on my project is still on 2.0.8, we have incompatible build results.
| (03:17:53 PM) Brian: ALR: i'm sure it's the ordering, if we find the right dependency and change the order in the pom it will be consistent
| (03:18:37 PM) Brian: in <2.0.8 the dependency ordering was dependent on the natural hashset order, which meant it could change if you moved jdks. In 2.0.9+, it's a linkedhashset and the order in the pom is preserved
| (03:19:09 PM) ALR: Brian: I see. You understand why this confuses me for a point release? :)
| (03:19:43 PM) ALR: Brian: This makes 2.0.9 not backward-compatible with 2.0.8.
| (03:20:12 PM) ALR: Brian: Unless you consider 2.0.8 handling a bug ;)
| (03:20:38 PM) Brian: ALR it was a tough call but it was causing far more issues as it was
| (03:20:54 PM) Brian: most of the time it's not an issue, but in edge cases like this it shows up
| (03:21:28 PM) ALR: Brian: Thanks very much again for your help. I'll take a look at the ordering of the transitives.
| (03:21:39 PM) Brian: i'm still comparing the trees here
| (03:21:45 PM) ALR: Brian: Ah, cool
| (03:24:09 PM) Brian: you don't have any exclusions?
| (03:24:28 PM) Brian: i can see in one system, the container comes from the jboss-as-jmx dependency but not in the other
| (03:24:34 PM) ALR: Brian: I'm sure we do :)
| (03:26:18 PM) ALR: Brian: Yes, that's very odd..
| (03:26:34 PM) ALR: Brian: Same version of jboss-as-jmx at that.
| (03:26:38 PM) Brian: yeah
| (03:26:47 PM) Brian: does that have an exclusion in it?
| (03:27:55 PM) Brian: jdcasey: ping
| (03:28:05 PM) jdcasey: ?
| (03:28:19 PM) ALR: Brian: No. http://pastebin.com/d72663242
| (03:28:42 PM) Brian: i'm looking at this output from the jboss build and i think the issue is because we made the order deterministic in 2.0.9 but i haven't put my finger on it yet
| (03:29:09 PM) Brian: jdcasey, here's the output: http://pastebin.com/d778daed2 2.0.8 on top, 2.0.9 on bottom.
| (03:29:21 PM) Brian: 2.0.8 has the jboss-container artifact, 2.0.9 doesn't
| (03:30:38 PM) Brian: jdcasey, it's coming from the jboss-as-jmx dependency but both maven versions have selected the same version of that dependency yet one is missing the container
| (03:31:05 PM) jdcasey: Brian: you may need to run with -X and capture the collection output in the debug logs to see what's happening there...it's possible an exclusion or something is getting triggered that wasn't before
| (03:31:24 PM) Brian: that's kinda what i was thinking
| (03:32:04 PM) ALR: Brian, jdcasey: I don't see the exclusion: http://pastebin.com/d72663242
| (03:32:33 PM) jdcasey: Brian: I didn't think we'd made provided-scope dependencies transitive yet?
| (03:32:41 PM) jdcasey: that provided scope maybe the key
| (03:33:09 PM) jdcasey: in any case, there's not enough information in that output to tell
| (03:33:17 PM) jdcasey: you need the full -X output for each, IMO
| (03:33:23 PM) jdcasey: and it'll be fun to pick out, too
| (03:33:26 PM) jdcasey: count on that
| (03:34:29 PM) ALR: Brian, jdcasey: k
| (03:42:52 PM) ALR: Brian, jdcasey: 2.0.8 http://pastebin.com/d20c5d35d
| (03:43:58 PM) ALR: Brian, jdcasey: 2.0.9 http://pastebin.com/d3143b227
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154456#4154456
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154456
15 years, 11 months
[Design of POJO Server] - Controlling deployments via a barrier bean
by bstansberry＠jboss.com
I've been looking at better ways to do HASingleton deployments vs the current (broken) scanner-based approach (http://jira.jboss.com/jira/browse/JBAS-5563).
I've long thought that a better way to do this would be by adding a deployer that adds a dependency on "barrier" bean to deployments that have appropriate metadata. Similar to the JMX-based jboss.ha:service=HASingletonDeployer,type=BarrierController concept, but with an MC bean.
An example set of deployers would be:
| <!-- For deployments that have HASingletonMetaData attached,
| establishes a dependency on a barrier bean that is only
| satisfied when this node becomes the singleton master
| -->
| <bean name="HASingletonBarrierDependencyDeployer"
| class="org.jboss.ha.singleton.deployer.HASingletonBarrierDependencyDeployer">
|
| <property name="dependencyNamesByPartition">
| <map keyClass="java.lang.String" valueClass="java.lang.String">
| <entry>
| <key>${jboss.partition.name:DefaultPartition}</key>
| <value>HASingletonBarrier</value>
| </entry>
| <!-- Add more entries if you deploy more HAPartitions -->
| </map>
| </property>
|
| </bean>
|
| <!--
| Adds HASingletonMetaData to deployments that come from the specified
| URLs. Provides support for the legacy deploy-hasingleton directory
| concept.
| -->
| <bean name="HASingletonMetadataDeployer"
| class="org.jboss.ha.singleton.deployer.VFSHASingletonMetadataDeployer">
|
| <property name="partitionName">${jboss.partition.name:DefaultPartition}</property>
|
| <property name="URIList">
| <list elementClass="java.net.URI">
| <!-- Standard HASingleton deployment directory -->
| <value>${jboss.server.home.url}deploy-hasingleton/</value>
| </list>
| </property>
| </bean>
In deploy we'd have these beans:
| <!-- Bean on which HASingletons will depend. ControllerMode is MANUAL,
| so will not deploy until HASingletonBarrierInstaller installs it.
| -->
| <bean name="HASingletonBarrier" class="java.lang.Object" mode="MANUAL"/>
|
| <!-- Tracks cluster topology and tells the MainDeployer to bring the
| HASingletonBarrier to INSTALLED when it becomes singleton master, and
| to bring it to NOT_INSTALLED when it is no longer the master.
| -->
| <bean name="HASingletonBarrierInstaller"
| class="org.jboss.ha.singleton.deployer.HASingletonBarrierInstaller">
|
| <property name="barrierBeanName">HASingletonBarrier</property>
| <property name="mainDeployer"><inject bean="MainDeployer"/></property>
| <property name="HAPartition"><inject bean="HAPartition"/></property>
|
| </bean>
That's the concept at least. One issue I see is on the non-singleton-master nodes the MainDeployer.checkComplete() impl is going to report an unsatisfied dependency, which will get logged at ERROR. Not good.
Any comments on this basic approach to controlling deployments? If it seems reasonable, can we add a mechanism (perhaps a flag in DependencyItem) such that certain unresolved dependencies are not logged as an error?
(Note it's possible this will just work w/o the logging. I'm working through other issues and haven't gotten it to work right yet. But looking at the code it seems clear there will be ERROR logging.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154445#4154445
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154445
15 years, 11 months