[Design of Clustering on JBoss (Clusters/JBoss)] - Testsuite changes
by bstansberry＠jboss.com
Just an FYI on some stuff I'm doing that affects the way the clustering tests work.
The following is currently in place in Branch_4_0 and will be moved to HEAD soon.
Previously the clustering tests worked by creating 2 configs "node0" and "node1" and launching 2 jboss instances, one using each.
To execute all the required tests, the build script would tear down and rebuild node0 and node1, altering various aspects of the config (e.g. use REPL_SYNC instead of REPL_ASYNC).
The problem with this is that when a version of node0/1 got torn down and replaced, it's server logs went with it. This makes subsequent debugging of any failures difficult, particularly with cruisecontrol runs that sometimes reveal problems we don't see on our local machines.
This is a real problem right now, as cc is starting to use jrockit, and odd failures are appearing. I don't run jrockit at home, so hard to diagnose w/o logs.
To fix this, I'm no longer using "node0/node1". Rather, each config will be given a name that somewhat describes what it is, e.g.:
cluster-UDP-0 and cluster-UDP-1
cluster-field-UDP-0/1 (configured for FIELD repl)
cluster-UDP-SYNC-0/1 (configured for REPL_SYNC)
cluster-field-UDP-SYNC-0/1
cluster-UDP-BR-0/1 (configured for BuddyReplication)
cluster-field-UDP-BR-0/1
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964222#3964222
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964222
19 years, 8 months
[Design of POJO Server] - Re: VDF deployer update
by dacx
There is an unuasual behaviour on my application running on JBOSS and it itermittently happen like this will automatically invoke shuting down the JVM after a few days of up time.
2006-08-10 09:28:10,216 INFO [org.jboss.system.server.Server] LifeThread.run exits!
2006-08-10 09:28:10,220 INFO [org.jboss.system.server.Server] Shutting down the JVM now!
2006-08-10 09:28:10,223 INFO [org.jboss.system.server.Server] JBoss SHUTDOWN: Undeploying all packages
2006-08-10 09:28:10,247 INFO [org.jboss.web.tomcat.tc5.TomcatDeployer] undeploy, ctxPath=/wap, warUrl=file:/appl/jboss-3.2.7/server/default/deploy/wap.war/
2006-08-10 09:28:10,282 INFO [org.jboss.web.tomcat.tc5.TomcatDeployer] undeploy, ctxPath=/web-console, warUrl=file:/appl/jboss-3.2.7/server/default/deploy/tnemeganam/web-console.war/
2006-08-10 09:28:10,324 INFO [org.jboss.web.tomcat.tc5.TomcatDeployer] undeploy, ctxPath=/myhandygames, warUrl=file:/appl/jboss-3.2.7/server/default/deploy/myhandygames.war/
2006-08-10 09:28:10,379 INFO [org.apache.catalina.core.StandardWrapper] Waiting for 2 instance(s) to be deallocated
2006-08-10 09:28:10,416 INFO [org.jboss.web.localhost.Engine] ApplicationDispatcher[/myhandygames]: Servlet action is currently unavailable
2006-08-10 09:28:10,555 INFO [org.jboss.web.localhost.Engine] ApplicationDispatcher[/myhandygames]: Servlet action is currently unavailable
2006-08-10 09:28:10,600 INFO [org.apache.catalina.core.StandardWrapper] Waiting for 1 instance(s) to be deallocated
2006-08-10 09:28:11,263 INFO [STDOUT] java.lang.IllegalStateException: setAttribute: Session already invalidated
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964218#3964218
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964218
19 years, 8 months
[Design of JBoss jBPM] - Re: jbpm drools integration meeting
by jeffdelong
Tom,
Well I just spent two hours responding in the forum point by point to your comments on my last email, only to have the page go away when I hit Preview. So now I have written this up in a separate doc and copy and paste.d So if the tone of this is too terse, it is the result of having lost that first response.
Short answer is that I believe the use cases that I have described are valid - that is real customers do use BPM products and production rules engines in the manners that I have described (including jBPM and Drools!). They are based on real-life customer engagements, both as a JBoss consultant and my past consulting experience.
For a quick example however, just think of credit scoring within a lending process. Lenders have been using production rules technology to perform credit scoring for years. From a process perspective, it could be modeled as a separate node in the process graph, or as a "decision node" to approve or reject. Either will work and deliver the same result, but one process design may be more expressive to a given customer than the other.
As for task assignment, think of the example I gave before and then add skill level, procedure code, availability, and three or four other constraints and you can understand why an insurance company might want to use a rules engine to determine which user (or set of users) they might want to assign the task to. As opposed to writing some complex, un-manageable SQL query. Clearly the issue with asserting a large organizational model needs to be addressed as part of the design, but that is a rules design issue.
Also, to clarify, that a set of rules might be satisfied by multiple objects is not a detriment to their use; another rule can then determine which of multiple objects should be selected if the business case only requires one. In task assignment, it is legitimate to set multiple users via the setPooledActors interface, if this supports the business model.
>From a practical standpoint, jBPM already supports the integration that I have described through its delegation model. AssignmentHandlers, ActionHandlers, and DecisionHandlers can all invoke rules very easily. And Drools can assert new objects, or set properties on existing objects, making it quite easy to communicate the results of the rule execution to the process instance. So there is really no new jBPM development work needed to support what I have described. I do think providing documented examples would be useful, however.
As for some of the other ideas being discussed, I don't understand the need to persist Rules or RulesBases inside the jBPM database, as long as there is a BRMS to manage these objects.
I also don't agree with the need to manage rules, process definitions, and java all from within CVS either. This works for simple scenarios (like the examples I create) but would not support a production environment very well. I think a BRMS requires a separate "rule repository" to manage rules and rules bases, and process components should go to the BRMS when they need to run some rules.
Users do require rules to be updateable by non-developers to a certain extent without the need to change the process definition or the code, and without having to re-deploy either the ear or the process definition. It is up to rule authors to create rules that allow some flexibility in this regard. An example of this is relaxing the number of years at the same address from three years to two in some credit scoring rules. Since the domain model is not changing (i.e., numberOfYearsAtCurrentResidence is already an attribute of the Applicant object), then this change can be made without re-compiling and re-deploying code. Clearly the BRMS needs to be able to have access to the latest Java from CVS in order to compile the rules, but that is a BRMS function.
Finally, I don't understand the use case for "changing process variables causes the rules to fire", so I would be interested in discussing an business process example that required this in more detail.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964194#3964194
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964194
19 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - JBossMessaging 1.0.1.CR4 Released
by ovidiu.feodorov＠jboss.com
JBoss Messaging 1.0.1.CR4 has been release and it is available for download on jboss.org and sourceforge.
This release incorporates a lot of community feedback, which is reflected in the number of bugs fixed. The complete list of fixes is available in the Release Notes.
CR4 also introduces several notable message delivery improvements. Tim modified core's internals to include message batching (JBMESSAGING-328) and improved SEDA-like concurrency.
While message batching highly improves throughput, it has the side effect of breaking backward compatibility with 1.0.1.CR3. This means that you need to upgrade both the server and the client-side library in order to use CR4. We took this decision based on community poll results. The poll confirmed that most users see backward compatibly as a "nice to have", but not critical feature at this stage. We'll be back to guaranteeing compatibility from 1.2 on. Until then, our compatibility tests will be disabled.
Upgrading to Remoting 2.0.0.CR1 introduced some minor SSL configuration changes: what was previously SSL Connector's "KeyManagementAlgorithm" is now called "KeyStoreAlgorithm". The SSL example that comes with the release has been modified to reflect the change.
Good news is that we finally migrated to a separated SVN repository (you will be prompted for a login, use your jboss.com username and password) and an independent build. This allows us to decouple our development from JBoss AS and integrate through the thirdparty repository. The most visible benefit is that head checkout and full build do not take hours anymore, and we're finally able to ship a complete source tree that can be actually used to generate binaries and run functional tests.
The next step is to branch 1.0, so we can continue to offer bug fixes and stable 1.0 releases while the bulk of the development effort on the head will shift towards clustering. Expect a clustered Alpha release in September. Until then, we should have at least another candidate release on the 1.0 branch and hopefully the 1.0.1.GA.
The JBoss Messaging project roadmap is available here.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964171#3964171
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964171
19 years, 8 months
[Design of JBoss jBPM] - Re: jbpm drools integration meeting
by tom.baeyens＠jboss.com
"woolfel" wrote : Many of the cases I know of use a rule template approach. A rule template defines a given pattern, which users populate. When ever a new rule template is introduced, it goes through a rigorous validation and testing process. If a business analyst creates a new rule using an existing template, the risk is rather low. this reduces the cost of testing and validation.
|
exactly. i agree and come from a different perspective. my perspective is that business users see a projection of the actual software artifacts like rules and processes. if the 'moving parts' are restricted within the projection, business users can just do their thing without a need for a developer.
a decision table spreadsheet is a good example of that. see also Keith Swenson http://kswenson.wordpress.com/2006/07/09/what-bpm-can-learn-from-a-spread... and me http://jboss.org/jbossBlog/blog/tbaeyens/2006/07/26/Clean_handoff_Collabo...
"woolfel" wrote : having said that, using a BRMS (business rule management system) is best suited if the rules use a data driven approach like drools3, jrules, blaze, jess, etc. If the rules couple the data to the rules, then a BRMS approach is more painful and likely not useful. I don't know how jBPM works or whether it uses a data driven approach. If jBPM doesn't use a data driven approach, then I would agree a CVS/SVN approach is better suited.
|
i don't care about CVS/SVN either. but my reasoning is that sources should always be kept in sync by the process in which you develop software. not by software that tries to synchronize CVS with a runtime rules deployment server. in my opinion, in a general case, rules and processes cannot live outside a development environment. and development envs are typically managed by CVS/SVN so that is why i think that our efforts should go to trying to provide the tools so that business users operate on that repository. rather then a seperate repository and then end up with having to keep multiple repo's synchronized.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964156#3964156
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964156
19 years, 8 months
[Design of JBoss jBPM] - Re: jbpm drools integration meeting
by woolfel
Mark as me to comment on this, so here goes my bias 2 cents.
>From first hand experience building applications with JESS, it doesn't match reality. I understand the concerns about the control of the rules and reducing risk, but the main selling point of a rule engine and rule approach is it enables business analysts to write the rules.
take for example EBay. they currently use JRules from iLog. At EBay, the rules are used to route transactions and filter out bogus stuff. If the rules are considered java code, that implies it should go through a full deployment process. This would mean the business analysts couldn't change the rules on the fly during the day to filter out bogus products or bids.
another example. within the securities world, compliance officers are responsible for writing rules and making sure violations against government regulations do not occur. when violations occur, it results in heafty fines ranging in the millions. Many older compliance systems treat rules as code, which means it takes large institutions 8-10 months to write, test and deploy new rules.
the reality is the rules always have to be in sync with the application, so whether CVS or a rule repository is used is not the issue. The issue is how can a rule repository find a good balance between risk control and flexibility. Many of the cases I know of use a rule template approach. A rule template defines a given pattern, which users populate. When ever a new rule template is introduced, it goes through a rigorous validation and testing process. If a business analyst creates a new rule using an existing template, the risk is rather low. this reduces the cost of testing and validation.
having said that, using a BRMS (business rule management system) is best suited if the rules use a data driven approach like drools3, jrules, blaze, jess, etc. If the rules couple the data to the rules, then a BRMS approach is more painful and likely not useful. I don't know how jBPM works or whether it uses a data driven approach. If jBPM doesn't use a data driven approach, then I would agree a CVS/SVN approach is better suited.
whether jBPM should tie the data to the rules is a different issue beyond the scope of this thread.
peter
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964142#3964142
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964142
19 years, 8 months