August 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [JBoss AS7 Development] - types of deployment errors and their handling

by Alexey Loubyansky

Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] replied to the discussion "types of deployment errors and their handling" To view the discussion, visit: http://community.jboss.org/message/559582#559582 -------------------------------------------------------------- Yes, that makes sense. Not only a subsystem failure will lead to failed deployments but in general it'd make sense to keep a server running if it could recover from the error which in this case means to restart the subsystem which I don't think we even considered? Actually my point starting this thread was clarify the current deployment mechanism and (more importantly) how it's actually supposed to work and how it is supposed to fail. But what effects errors from different kinds of "startable" pieces (subsystems, applications, etc) have has to be clearly defined as well. I'll have a look and start a new thread for that. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559582#559582] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - History details

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "History details" To view the discussion, visit: http://community.jboss.org/message/559581#559581 -------------------------------------------------------------- I would rather like to keep it in consistent way, in other words either do it with one record with comma separated transition/activity names or many records. But having many records will be kind of wrong in design manner, since that part refers to history activity, if we put more than record it will look like we have many forks/joins. I am not sure what is the best way to do it, need to think about it a bit more... BTW, history stuff is now committed to trunk, tomorrow will check in query stuff to be done with it and start work on other issues. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559581#559581] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss AS7 Development] - types of deployment errors and their handling

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "types of deployment errors and their handling" To view the discussion, visit: http://community.jboss.org/message/559572#559572 -------------------------------------------------------------- Agreed on subsystems/extensions being handled differently from deployments. I can't see how we're doing our users a favor by leaving a server running with partially broken subsystems. If a subsystem finds a problem that it can live with, it should log an ERROR/WARN and not throw an exception. If an exception is thrown, that's an indication that the subsystem and thus the entire server is in an invalid state. The draft deployment API that I'll start a thread on next includes ways for the user to specify how they want things to work if failure occurs during deployment. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559572#559572] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss AS7 Development] - model updates and references

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "model updates and references" To view the discussion, visit: http://community.jboss.org/message/559569#559569 -------------------------------------------------------------- I see us having a separate layer, not doing modifications directly on the core model. But we need to start actually fleshing this out to see how it works. I want to start with deployments; perhaps you can identify one or two more types of modifications that are fairly representative of different types of problems we need to handle? David might want to comment further, but I think we should look at the AbstractModelElement.appendDifferences() method as an initial idea on how to deal with updates, something we can supplement or even move away from completely. It's based on the idea that we have another instance of the model and we then calculate differences and based on those create update actions. It's not clear where that other instance of the model comes from. One of the nice aspects of the appendDifferences idea is only update classes have access to the package-protected modifier methods on the model objects. But then how is the other instance of the model created? Re: validation -- forgive me for a bit of a tangent: even with the more limited task we've done up to now of creating model objects by parsing, I think we're missing an explicit validation phase. For one thing, it's needed to give model elements a chance to resolve any references to other model elements. I've done a bit of that with RefResolver being passed into model element constructors, but there are cases where it's not valid to try and resolve the reference in the constructor (since the referent may not have been parsed yet). Now we're not resolving until the element is activated, which is too late. When we talked a week or so ago about a proper reference notion, I was thinking mostly in terms of the rename use case. So if socket-binding "foo" gets renamed "bar", any referring elements are aware of that and change their config to read "bar". But I think a richer reference notion can apply to other problems as well. For example, ServerGroupElement has a fully fleshed out "reference object" linking it to a ProfileElement. So if the ProfileElement is changed (either directly or via a change to a child subsystem) the ServerGroupElement is aware of that. We then use that information to figure out what to push out to the ServerManagers (and on to the Servers). -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559569#559569] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss AS7 Development] - types of deployment errors and their handling

by John Bailey

John Bailey [http://community.jboss.org/people/johnbailey] replied to the discussion "types of deployment errors and their handling" To view the discussion, visit: http://community.jboss.org/message/559566#559566 -------------------------------------------------------------- As for item #1, I think there are a couple things to think about. I think subsystems/extensions, should be handled differently from deployments. I think if sub-system fails to activate based on some kind of exception thrown during activation (not a service start), I think the server should basically stop progressing, and basically log the information related to the problem. I just to don't think it makes sense for the server to continue if a subsystem failed. Deployments are a different story. I think the server should log the problem info, but continue to boot with other deployments. This is basically what is happening now. What is still needed is some ability to rollback any deployment specific services that may have been added to the batch prior to the failure occurring. The deployment already use MSC sub-batches, but the API does not have any options to rollback. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559566#559566] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - History details

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion "History details" To view the discussion, visit: http://community.jboss.org/message/559540#559540 -------------------------------------------------------------- Hi Maciej, At first glance of it. I think the comma separation is enough for fork and forkeach, because these outgoing transitions will be created at the same time. But for the JoinActivity, if we want to record full information about when each of transition arriaved on it. We have to record each record per transition. What do you think about it? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559540#559540] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - History details

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "History details" To view the discussion, visit: http://community.jboss.org/message/559531#559531 -------------------------------------------------------------- I completely agree that we shall record these activities. Only question is how/what shall be saved. The issue is that we have multiple transition names to be saved for both fork and for each and multiple transition names reaching join. So there are few options: 1. we save one record for the activity saying when it happened and number of transitions taken 2. we save one record for the activity saying when it happened and names of the transitions as comma separated values 3. we save one record per transition taken for fork and for each, for join we save one record for each incoming transition 4. introduce new table for transition names that will be joined with history for activities Comments, ideas? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559531#559531] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - History details

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion "History details" To view the discussion, visit: http://community.jboss.org/message/559529#559529 -------------------------------------------------------------- Hi Maciej, In my opinion, it would be better to save all of informations about fork and join, whatever which branches are chosen to contien or which branches reached it or complete join to continue. Because we want to use history records to display the route of the proces instance as video or annimation or something just like these. Now we have to guest when the fork or join reached. It is really hard to guest these information without history records. I think it is maybe a little hard to achieve these features on current PVM. Just after we support dynamic fork with foreach and M of N fork, and join with multiplicity attribute. What are you thinking about it? Regards. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559529#559529] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - History details

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "History details" To view the discussion, visit: http://community.jboss.org/message/559526#559526 -------------------------------------------------------------- Hi HuiSheng, thanks for pointing it out. What would you like to save when executing such activities? Another question about join, when shall we save it? When any patch reaches it or when join is completed? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559526#559526] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - History details

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion "History details" To view the discussion, visit: http://community.jboss.org/message/559505#559505 -------------------------------------------------------------- Hi Maciej, There is no history record for ForkActivity, ForeachActivity and JoinActivity. We should also save them in jPDL. Regards. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559505#559505] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2010