[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ
by galder.zamarreno＠jboss.com
I've got 1-5 plus .functional package tests running. It still needs some polishing because the set up and tear down execution phases of these tests is a <insert_a_lovely_word_here> mess, so if I run several tests together, they fail. Why? Well, because there's part of the set up code that is only run once per test case execution and other part that is run before each individual test. This is making it hard for me to figure out where on earth I need to put tear down code.
On top of that, things vary between single node and multi node tests, i.e. for multi node tests, one of the node's cache is set up once per unit test case class, whereas for the other is set up before each single test method.
Anyway, as Brian said, I think I have enough now to build a binary, so I'm gonna leave the testing to a side and focus on creating the binary and integrating it with Portal 2.7.x.
I'll commit the code today or tomorrow.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166949#4166949
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166949
17 years, 8 months
[Design of JBoss Transaction Services] - Re: JBAS-5801 - Locking in 2PC
by jhalliday
> What we really want to do is make sure that end() blocks
> at tx timeout until the current user operation has completed.
I'd argue that's exactly what we want to avoid. One use of a tx timeout is to ensure apps don't get stuck due to e.g. slow db queries. If I issue e.g. a SELECT inside a tx and that tx has a timeout, I want it to timeout promptly, not block on the db operation. Likewise for sending or receiving messages. That's part of the reason JBossTS uses a background thread for timeouts. Sure some resource managers have explicit support for configuring timeouts on potentially long running operations, but it's not required.
I'd say it's up to the resource manager's driver code to decide how to handle the situation. If it's got one thread doing a business logic operation in a tx when another thread is trying to terminate that tx, it can either block internally (I've seen the MS SQL driver do that, queuing the end to go over the same TCP/IP connection when the SELECT eventually returns) or e.g. throw an exception on the business logic thread.
That said, one option may be to make this configurable at the JCA level. Allow e.g. -ds.xml files to contain an option for how the JCA should behave - delegate to the driver as I describe, block as you suggest, or even explicitly interrupt the business logic and throw an exception as some users seem to expect. The last one of course is risky, it may mess up the underlying driver.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166934#4166934
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166934
17 years, 8 months
[Design of JBoss Transaction Services] - JBAS-5801 - Locking in 2PC
by adrian＠jboss.org
WRT: https://jira.jboss.org/jira/browse/JBAS-5801
It occurs to me that there might not actually be any need to do the locking
in the resource adapter during 2PC, i.e. prepare/commit/rollback?
What we really want to do is make sure that end() blocks
at tx timeout until the current user operation has completed.
Is that correct?
e.g. The case would be:
User: Connection.createSession(); // allocates and enlists connection
JCA: XAResource.start();
Then later something like a competing
User: sendMessage();
TM: tx timeout => XAResource.end() before XAResource.rollback()
We basically don't want the sendMessage() to occur during or after
the rollback because that could potentially lead to inconsistencies
depending upon how the underlying jms determines what to do.
i.e. All we actually need to do is make sure the end() and sendMessage()
(or other user ops) aren't racing with other.
If true that would make the fix for 5801 a lot simpler since we could just
remove the unnecessary locking in 2PC callbacks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166928#4166928
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166928
17 years, 8 months
[Design of JBoss jBPM] - Re: Defining the API Mission
by koen.aers＠jboss.com
"Ed" wrote : Re use of GPD... I'm pretty unhappy with GPD. The code base is not very extensible, and is highly dependent on the XML editor codebase.
I am sorry to hear that you are unhappy with GPD. But as a matter of fact I know its limitations and I am not that happy with it myself.
The current code is indeed very dependent on the XML editor. The reason for this is a combination of history and the initial goal of providing support for the developers to edit the XML file.
As for extensibility, as Matthew and others have shown, it is doable but there are indeed some quirks that have to be overcome. However, the input that came from users that extend the GPD has been very valuable to make this mechanism somewhat better.
"Ed" wrote : I went to the talk by the Eclipse BPMN editor guys at EclipseCon, and was very sold on GMF. The BPMN editor is really slick, and easily extensible. People kept complimenting them on this or that feature, and they kept saying things like "well, it wasn't really a requirement, but all we had to do to implement it was write these 5 lines of code, so we just threw it in." High praise for the framework!
I have looked at the BPMN editor and it is indeed a very nice piece of work. However, its approach has a number of issues that I haven't been able to solve until now:
- serialization of XML compliant to our jPDL XSD
- graphical info serialized in another file or not
- easily integrate with an XML editor to edit the serialized XML
GMF builds on top of EMF and while I have been able to build small prototypes that come close to what we want, I still haven't been able to walk the final mile. I will open up a different topic with some of the results of my research. Maybe some people are able to help out with closing this final gap.
"Ed" wrote : After spending some time with the code, I am even more sold. I would very strongly suggest that Koen look at GMF et al again - it's probably grown up a lot since he checked it out the first time.
I definitely agree with you that GMF has become better in the meantime. I have checked it out again after the last EclipseCon as well. Maybe I am still missing things, but as I stated before I still have problems in making it do what I want it to do.
So after a discussion with Kris Verlaenen (from the Drools team) around the effort to implement a common base for a 'flow' editor we have decided to not use GMF for this (the high dependency of GMF on the very intrusive EMF framework was a real breakpoint for Kris). As a plus, this new effort will be highly focused on extensibility. Anyway, if we have been looking past important things, we are open to suggestions. As already said, I will open a different topic with the ideas and research results that I obtained earlier.
Regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166915#4166915
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166915
17 years, 8 months
[Design of JBoss jBPM] - Re: Defining the API Mission
by tom.baeyens＠jboss.com
"heiko.braun(a)jboss.com" wrote : So instead of naming it a decision, you could call it exclusive gateway right away. The reason why I prefer BPMN glossary over jBPM terms is that these people did a good job finding terminology and add short, descriptive explanations to the core concepts.
|
First, I think you overrate the BPMN spec as the final thing that concludes the battles in BPM.
Second, API mainly deals mostly with runtime constructs. BPMN deals with process definition constructs.
Third, for the simple constructs like exclusive gateway it is possible. But the more complex you go, the harder it will be to map the analysis constructs to implementation constructs. Only if the direction for BPMN 2.0 would be to add exact executable semantics to BPMN, then it would become a viable option to make sure we cover all the constructs.
Forth, if BPMN becomes executable, then we should do that as a separate language. (maybe as a jPDL variant, depending on how close it is) If we take BPMN as a basis in the API, then we introduce a mismatch between XPDL and BPEL, both of whom are also supported on the PVM and those also have their own naming scheme.
"heiko.braun(a)jboss.com" wrote :
| Whereas in the PVM, we still have 3 or 4 kinds of "Executions".
|
Can you elaborate on this ? Different views on an execution were introduced to provide proper interfaces in each use case. You helped to induce that change. We changed from offering all methods and throw an exception when a user invokes an invalid one, to only offer the appropriote methods in the different use cases of an execution. I don't yet see the relation with this post.
"heiko.braun(a)jboss.com" wrote : If we could manage to become explicit in our jBPM4 terminology the same way, then I wouldn't complain. But currently I see a 200 pages document with very precise terminology (BPMN) and a redundant, hard to understand API (PVM) which is only obvious to it's inventor.
|
| So give me one good reason why we should chose the hard way and try to be superior to the BPMN spec leads and come up with something on our own.
Because BPMN is not doing the same thing as what we're doing. We're defining a framework for building state machines and executable process languages. BPMN defines a process modelling notation.
Some of the languages that can be implemented on PVM even have a more technical background that is not always related to BPM: pageflow, programmatic state machines, naked BPEL. So that is why I think it is better to have a naming scheme that is neutral to all the targetted specs, patterns and languages out there.
The API naming convention is important, but IMHO, there are much more important debates to have:
1) The runtime data structures. Those determine which control flow constructs can be build on it.
2) Do the PVM runtime structures cover the BPMN interpretations. For each possible runtime interpretation of BPMN constructus, can we build executable constructs for it on the PVM. This again boils down to the runtime data structures.
When it comes to the power of a BPM/workflow engine, then mostly, your discussing the capabilities of the runtime datastructures. (In)validating those is more important then the API naming scheme.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166911#4166911
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166911
17 years, 8 months
[Design of EJB 3.0] - @RemoteBindings and clientBindUrl - JNDI binding question
by jaikiran
As part of a test case for EJBTHREE-1423, i am testing that the @RemoteBindings on a bean is being honoured. I am not completely clear about how the clientBindUrl works:
| @Stateless
| @RemoteBindings (
| {
| @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.REMOTE_JNDI_NAME),
| @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.ANOTHER_REMOTE_JNDI_NAME, clientBindUrl=MyStatelessBeanWithMultipleRemoteBindings.CUSTOM_CLIENT_BIND_URL)
| }
|
| )
| @Remote (MyStatelessRemote.class)
| public class MyStatelessBeanWithMultipleRemoteBindings implements MyStatelessRemote
| {
|
| /**
| * Remote jndi name
| */
| public static final String REMOTE_JNDI_NAME = "SomeJndiName";
|
| /**
| * Another remote jndi name
| */
| public static final String ANOTHER_REMOTE_JNDI_NAME = "AnotherJndiName";
|
| /**
| * Client bind url
| */
| public static final String CUSTOM_CLIENT_BIND_URL = "0.0.0.0:3333";
|
| ...
| }
Based on my understanding, i expect the bean to be bound to "SomeJndiName" (communication happens through default port 3873) and also "AnotherJndiName" (communication happens through custom port 3333). Is this correct? Right now, in my test case i see that the bean is never bound to the "AnotherJndiName" and instead its bound only to "SomeJndiName"
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166908#4166908
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166908
17 years, 8 months