[Design of Messaging on JBoss (Messaging/JBoss)] - Progressing On Ording Group Impl
by gaohoward
Progressing On Ording Group Impl
I created a OrderingGroupMonitor class. This class acts as a repository of ordering groups and go with each MessagingQueue. It simply answers one question: Is a message deliverable with respect to ordering group rule?
to enable this class to function properly, we need the following steps:
i) A messages is registered with the OrderingGroupMonitor whenever it is suitable for handling ( as in ChannelSupport.handle() )
ii) When a message sending is finished, it will tell the OrderingGroupMonitor to release it. ( as in acknowledge time, commit time, etc)
iii) When a message is peeked from the priority list for sending, it will first ask the OrderingGroupMonitor if the message is deliverable wrt ordering. If not (as in wrong order), we have to put the message back and let the queue to iterate to next message (when putting back, we need to lower its priority in order to let other messages get chance to deliver). If it is deliverable, the message will be sent the usually way.
iv) In tx case, ordering group can't be possible if the messages in a tx are acked in batch mode. We have to make some changes, for example let some internal acknowledge happen, to avoid such a dead lock.
public class OrderingGroupMonitor
{
HashMap<String, OrderingGroup> orderingGroups = new HashMap<String, OrderingGroup>();
/**
* Check the message is it is a member of an ordering group, if so,
* put it in; if not, do nothing.
* if message is dropped due to maxSize being reached, it won't be
* get registered. (dont' know if the tx is needed or not yet, just put here for now)
*/
public void registerMessage(MessageReference ref, Transaction tx)
{
String grpName = null;
try
{
grpName = ((JBossMessage)ref.getMessage()).getStringProperty(JBossMessage.JBOSS_MESSAGING_ORDERING_GROUP_ID);
}
catch (JMSException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
if ( grpName == null )
{
return;
}
synchronized(orderingGroups)
{
OrderingGroup group = orderingGroups.get(grpName);
if (group == null)
{
group = new OrderingGroup();
}
group.add(ref);
}
}
/**
* If ref is not in our registry, just return true.
* If in our registry, check if the ref is the first of the group.
* return true if it at the first place. return false other wise.
*/
public boolean isDeliverable(MessageReference ref)
{
// TODO Auto-generated method stub
return false;
}
/**
* This method indicates a messgae is completed.
* it is called when a message is acked, commited or rollback
* once the message is completed, the next one in a ordering
* group becomes deliverable.
*/
public void messageCompleted(MessageReference message)
{
//remove reference from the repository
}
}
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181733#4181733
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181733
16 years, 3 months
[Design of POJO Server] - Re: java.beans.XMLEncoder Useless?
by scott.stark＠jboss.org
Since we should be using jaxb for metadata that is annotated with it, and I see that you can use jaxb even when its not annotated, I'm looking at that instead. For metadata like the datasource which does have jaxb annotations:
| public void testJaxbMCFXml()
| throws Exception
| {
| ManagedConnectionFactoryDeploymentGroup mcfs = initMCFDG();
|
| JAXBContext ctx = JAXBContext.newInstance(ManagedConnectionFactoryDeploymentGroup.class);
| Marshaller marshaller = ctx.createMarshaller();
| marshaller.setProperty("jaxb.formatted.output", Boolean.TRUE);
| QName mcfsName = new QName("datasources");
| JAXBElement<ManagedConnectionFactoryDeploymentGroup> root = new
| JAXBElement<ManagedConnectionFactoryDeploymentGroup>(mcfsName,
| ManagedConnectionFactoryDeploymentGroup.class, mcfs);
| marshaller.marshal(root, System.out);
| }
|
with initMCFDG() populating the mcfs similar to that shown above, jaxb output produces:
| <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
| <datasources>
| <local-tx-datasource>
| <rar-name>jboss-local-jdbc.rar</rar-name>
| <use-java-context>true</use-java-context>
| <connection-definition>conn def</connection-definition>
| <jmx-invoker-name>jboss:service=invoker,type=jrmp</jmx-invoker-name>
| <min-pool-size>1</min-pool-size>
| <max-pool-size>100</max-pool-size>
| <blocking-timeout-millis>5000</blocking-timeout-millis>
| <idle-timeout-minutes>15</idle-timeout-minutes>
| <prefill>true</prefill>
| <background-validation>true</background-validation>
| <background-validation-millis>5000</background-validation-millis>
| <validate-on-match>true</validate-on-match>
| <statistics-formatter>org.jboss.resource.statistic.pool.JBossDefaultSubPoolStatisticFormatter</statistics-formatter>
| <isSameRM-override-value>false</isSameRM-override-value>
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=Hypersonic,database=localDB</depends>
| <metadata>
| <type-mapping>Hypersonic SQL</type-mapping>
| </metadata>
| <local-transaction/>
| <user-name>user</user-name>
| <password>password</password>
| <new-connection-sql>run this on a new conn</new-connection-sql>
| <check-valid-connection-sql>select something from somewhere</check-valid-connection-sql>
| <exception-sorter-class-name>org.jboss.jdbc.SomeExceptionSorter</exception-sorter-class-name>
| <prepared-statement-cache-size>50</prepared-statement-cache-size>
| <share-prepared-statements>false</share-prepared-statements>
| <set-tx-query-timeout>false</set-tx-query-timeout>
| <query-timeout>30000</query-timeout>
| <use-try-lock>0</use-try-lock>
| <driver-class>org.jboss.jdbc.SomeDriver</driver-class>
| <connection-url>jdbc:xyz:a=b</connection-url>
| <connection-property name="cp1-name">cp1-value</connection-property>
| <connection-property name="cp2-name">cp2-value</connection-property>
| </local-tx-datasource>
| </datasources>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181724#4181724
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181724
16 years, 3 months
[Design of JBossCache] - JBCACHE-1423 Fix
by bstansberry＠jboss.com
Discussion of https://jira.jboss.org/jira/browse/JBCACHE-1423 -- see JIRA description for background.
The "simple fix" I discuss on the JIRA solves the out-of-date state problem, but breaks a number of other unit tests:
o.j.c.loader.UnnecessaryLoadingTest.testDontLoadWhenKeyInMemory()
o.j.c.loader.UnnecessaryLoadingTest.testUnnecessaryMultipleLoading()
o.j.c.mgmt.CacheLoaderTest.testCacheLoaderMgmt()
o.j.c.mgmt.PassivationTest.testPassivationMgmt()
In the first two there are specific assertions that a put(Fqn, Map) call doesn't result in a cache loader load. The latter two fail because the test setup does a bunch of put(Fqn, Map) calls and the tests assert that this didn't result in any cache loader misses; w/ my fix it does.
Bottom line, my simple fix results in cache loader get() calls that weren't there before. So, hopefully you guys have a better solution. ;) One possibility is what I mentioned on the JIRA -- change CLI.loadNode so it doesn't overwrite existing in-memory key/value pairs with those from the persistent store.
I'll check in the unit test for this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181715#4181715
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181715
16 years, 3 months
[Design of JBoss Build System] - Re: [JBASMP-2] Create an Undeploy Mojo
by ALRubinger
I see you've found my dirty laundry. :D
Making our hack CL static isn't muddying the waters any further, though; I should have had the forethought to do that in the first place.
"guignome" wrote : Ideally, jbossall-client should be defined as a maven dependency
No, the Plugin here needs to work with whatever version of jbossall-client is present in the user's installation, and the dependency would bind the Mojo to a particular AS version.
The genesis of that hack is to address a configuration property in the POM of the control-example:
<!-- Include jbossall-client.jar on the CP -->
| <additionalClasspathElements>
| <additionalClasspathElement>${JBOSS_HOME}/client/jbossall-client.jar</additionalClasspathElement>
| </additionalClasspathElements>
...which doesn't seem to be getting picked up. If that worked as advertised we could ditch the whole TCL replacement BS.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181667#4181667
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181667
16 years, 3 months
[Design of JBoss Build System] - Re: [JBASMP-2] Create an Undeploy Mojo
by guignome
This is a classloader problem. In java, an object created in a classloader cannot be cast to its superclass in another classloader. This is simply because two classes loaded using the same class name from the same jar from two different class loader are different (see Java Language Specification third edition-chapter 4.3.4).
In our case the deploy mojo creates a temporary classloader that contains jbossall-client.jar each time it does a jmx call. That's the source of the problem. I changed a bit the behaviour and store the temporary classloader as a static field. This way, classes from jbossall-client.jar are loaded only once per jvm.
That's a hack to fix a hack and I wouldn't be surprise if that was creating some other issues. Ideally, jbossall-client should be defined as a maven dependency (as described in the comments of the classloader hack).
Note that doing
$ export MAVEN_OPTS=-verbose
and using java6 instead of java5 helps a lot to debug classloader issues.
I'll clean up my patch and send it soon.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181665#4181665
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181665
16 years, 3 months
[Design of POJO Server] - [jboss-metadata] Validation on completely merged view
by ALRubinger
@see https://jira.jboss.org/jira/browse/JBMETA-117
The defining issue is to prohibit an invalid construct:
@Stateless
| @RemoteBinding(jndiBinding="Something")
| @Local(SomeLocalBusinessInterface.class)
| class MyBean implements SomeLocalBusinessInterface{...}
Here I've defined an explicit remote binding on a SLSB w/ no remote view.
Makes sense to put this in the RemoteBindingProcessor:
public void process(JBossSessionBeanMetaData metaData, Class<?> type, RemoteBinding annotation)
| {
| /*
| * JBMETA-117
| *
| * No @RemoteBindings are allowed if there are no business remote interfaces
| */
|
| BusinessRemotesMetaData businessRemotes = metaData.getBusinessRemotes();
| if (businessRemotes == null || businessRemotes.size() == 0)
| {
| throw new RuntimeException("A @" + RemoteBinding.class.getName() + " was defined on EJB " + metaData.getName()
| + ", but this bean has no remote business interfaces defined. [" + ErrorCodes.ERROR_CODE_JBMETA117 + "]");
| }
...but if the @Remote annotation is on the business interface type, not on the implementation class, this will provide for false errors as the fully merged metadata of the EJB is not available until after this processor is called.
Is there a mechanism to validate metadata after all the processing/merging is completed? I'm envisioning something in the form of a chain of validators run by by JBoss50Creator.create() after everything is merged.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181661#4181661
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181661
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"camunda" wrote : One additional point: Is there time to discuss maybe about jPDL 4? There I remembered Tom's idea to somehow specifiy input variables in start-states or states, so interfaces to call back a process can be "automatically" exposed (like the Web-Service receive in BPEL), this would be interessting...
|
| But maybe this is a sub-topic of variable management in jPDL at all...
Variable management in general is a great proposal for a topic.
On the one hand, we should explore all options that we have in mind for jBPM 4, but on the other hand, we should decide on the (limited) scope for jBPM 4.0.0 and the next release in particular.
Deciding on the crucial features that we target in the next release and that should go in the scope of jBPM 4.0.0 is most important. We (mostly I) should refrain from spending a lot of time in the meeting on nice and cool ideas that are not inside of that initial scope. Let's try to find a good balance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181638#4181638
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181638
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"camunda" wrote : anonymous wrote : 1) Service API
|
| This brings to a question I already had in mind: will Commands play a role in future? That could be one form of the API, currently this is the one if you need Remote or Async communication. Some discussions in the past gave me the expressions that a typed API is more preferred from some corners...
|
| On the other hand I like the Commands very much for especially RichClients, and it is a crucial information if Commands will survive or not (for maintainability of existing informations). So this should maybe also thrown in the pot of discussion points around the API?
|
| Or is there already an oppinion we can agree on upfront?
|
| My idea would go in this direction: The Service API's are there as typed interfaces (especially for WebServices). In the implementation for every Method a Command is used, which could be also sent directly without using the API...
The services method implementations is based on commands. In other words, the Services are just typed methods that translate into commands.
Commands are then executed by a CommandService. A chain of command services can put interceptors around the command execution. Take a look at the environment.cfg.xml in jbpm4.
So it is an extension of what we were building towards in jBPM 3.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181637#4181637
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181637
16 years, 3 months