Menu
▾
▴
jboss-dev-forums
|
From: <ad...@jb...> - 2005-05-02 15:34:02
|
First here's a critique of the farm service. The major concern with the farm service is that It lacks the ability to stage deployments. 1) It just distributes the deployments on a best effort across the cluster with no reconciliation on whether the deployment works on each peer. 2) There is the potential that every node in the cluster could be redeploying the application, making it generally unavailable. 3) There are race conditions where two nodes could deploy things in different orders based on farm deployments to different nodes "at the same time". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876153#3876153 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876153 |
|
From: <ad...@jb...> - 2005-05-02 15:39:48
|
The first direction we will be taking in JBoss5 is to make the notion farm, singleton, replication, federation, etc. an aspect of each deployment rather than have different folders for these notions. This allows the features to be "mixed and matched" more easily. e.g. being able to farm a singleton where you deploy it to one node, it is distributed to all nodes but only activated on one. This is our "aspectized" deployment framework, here's the original requirements docs if you are not familiar with it: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernel These features will be configurable on individual services, not just whole deployments so you can have for example an EAR that has some components as singletons and others doing what farm does today. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876154#3876154 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876154 |
|
From: <ad...@jb...> - 2005-05-02 15:47:43
|
On Atomic Deployments. The aim here is to replace redeploy == undeploy/deploy with something as near atomic and undistruptive as possible. The redeploy will become something like: * See whether the deployment can be constructed * If it works, wait for current requests to complete and hold new requests (this is called the "valve") * Once current requests are done, switch the from old to new deployment, e.g. flip the jndi bindings and other outward facing references - this may also require some handoff of state, e.g. handing over cache/session objects * Remove the old/replaced deployments NOTE: Because of classloading requirements, the cache/session handover will almost certain require some of form serialzation. Either passivation of the sessions to disk or replication from the other cluster nodes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876158#3876158 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876158 |
|
From: <ad...@jb...> - 2005-05-02 15:49:17
|
On Transactional Deployment. This is where you want the deployment to work on all nodes or none at all. In general this will require the atomic deployment described above, but it also needs to take into staging and recovery features, both should be pluggable policy features. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876159#3876159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876159 |
|
From: <ad...@jb...> - 2005-05-02 15:53:25
|
On recovery This is a bit more complicated, but again a simple solution is to use the elected cluster "co-ordinator" as a reference (assuming you don't have a reference node as described above in the version processing). If the co-ordinator can deploy something and another node fails, this will generally mean that it has got out-of-sync or has some other problem. The obvious solution then is for that machine to be automatically restarted so it can recover its deployment state from the correct versioned deployment either from the co-oridinator or the reference node. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876162#3876162 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876162 |
|
From: <ad...@jb...> - 2005-05-02 15:42:22
|
The second direction is versioned deployment which will eventually lead to "atomic deployments". The original aim of this feature is to allow a reference machine (not a production machine) to be configured from a known production configuration (e.g. version 5). When the admin is happy with the new config, he can make it the production config (version 6). At any point, if problems are found, the admin can "rollback" to a known config version. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876155#3876155 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876155 |
|
From: <ad...@jb...> - 2005-05-02 15:55:20
|
Like I said, a lot of this should be subject to policy. e.g. in a cluster you don't need to hold new requests while the switch is taking place, instead you can force them to failover to a machine that is not currently making a switch between deployment versions. e.g. you may not be bothered about some state surviving redeployment View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876164#3876164 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876164 |
|
From: <ad...@jb...> - 2005-05-02 15:59:30
|
Finally, the cross-cutting and deployment versioning must eventually allow for node specific configuration where the nodes heterogenous. In this case, some nodes will need their own local configuration overrides because they are not as capable as other nodes. You can also imagine nodes co-operating more to manage resources. e.g. If you one node has idle db connections while another is running out, the idle connections could be closed in favour of the busier node. But we are getting slightly off the topic of deployment at here. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876167#3876167 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876167 |
|
From: <ad...@jb...> - 2005-05-02 15:30:26
|
This discussion really belongs in the deployment forum, so I will move it there. It also deals with a number of "cross cutting concerns" so I will deal with each individually and give a sort of road-map of our thinking for JBoss5. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876152#3876152 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876152 |
|
From: <ad...@jb...> - 2005-05-02 15:50:51
|
On Staging The most obvious solution is to take each machine to the point where we know the new deployment will work, but then flip each individually in a round robin manner. This means only one node is not serving requests and state can be retrieved from the rest of the cluster. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876161#3876161 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876161 |
|
From: <be...@jb...> - 2005-08-10 21:15:33
|
All of these features are going to be available in JBoss 5. However, we may need something simple(r) for 3.x and 4.x. I'm proposing the following: - On deployment, call _deploy() across the cluster This returns a list of values, if one of them is an exception, showing that the deployment was not successful, we call _undeploy() across the cluster - This is configurable, e.g. through an attribute "atomicDeployments" in the FarmService, which is off by default This solution would be trivial to implement. Do you guys think this adds value to Farming ? Bela View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889341#3889341 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889341 |
|
From: <ben...@jb...> - 2005-08-10 22:19:55
|
Without proper versioning, _deploy can be problematic as well though since there is no guarantee that _undeploy will succeed afterwards if values are not all successful. We will need _rollback instead. Of course, without implementing the full feature, the trade off is deciding where to draw the line? -Ben View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889349#3889349 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889349 |
|
From: ScottMarlowNovell <nu...@jb...> - 2005-08-12 18:11:46
|
Adrian, I would like to help with the "aspectized" deployment framework implementation, can you assign some tasks to me? Thanks, Scott View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889824#3889824 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889824 |
|
From: <ad...@jb...> - 2005-08-12 18:30:03
|
The initial tasks are here: http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310060&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&component=12310154 I know Dimitris/Scott started on the infrastructure but they have been (like me) working on more high prority stuff for JBoss4, so I don't know what state this is in? Probably nonfunctional? I plan to do the cutover to the new MicroKernel in JBoss5 over the next month, so this should start dropping into place. http://jira.jboss.com/jira/browse/JBAS-1841 + others The key part that really needs doing is the VFS - virtual file system VDF - virtual deployment framework to better integrate the classloading and deployment framework. See the discussions in the POJO Server forum, Scott might have some extra thoughts? Or knowing him, an uncommitted prototype lying around on his disk :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889827#3889827 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889827 |
|
From: <ad...@jb...> - 2005-08-12 18:35:27
|
To look at what Scott/Dimitris have committed already, see: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=58337 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889828#3889828 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889828 |
|
From: <ad...@jb...> - 2006-04-18 15:29:07
|
Bump View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3937963#3937963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3937963 |
|
From: <sco...@jb...> - 2006-04-18 17:14:14
|
What are you looking for, VDF/VFS? I am working toward this from the profile service prototype now. I do have the still uncommitted VFS prototype, but no VDF. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3937973#3937973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3937973 |
|
From: <bst...@jb...> - 2006-04-19 00:19:27
|
Adrian bumped this forum topic during our clustering/JBoss5/MC integration call earlier today just to make it easier for call participants to find. Don't think his intent was to push you. But since you asked, I think the clustering team would be more interested in the VDF :). Is the plan that this is going to be on hold for a while until we march through the Bataan of svn/maven issues? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3938038#3938038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3938038 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X