November 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Singleton consumer support native in JBM

by timfox

As we all know, JBoss MQ HA is based around the idea of a HASingleton - only one node in the cluster is active at any one time, With JBM on the other hand, each node is active concurrently. While this is an advantage in most use cases, there is one use case where the HASingleton approach is useful - this is when you want to ensure that messages are processed from a queue sequentially by a single consumer. This is trivial in JBoss MQ since there is only one node, but with JBM is not so simple. We could deploy the MDB as a ha singleton - this would ensure it only gets deployed on one node - however producer connections would be distributed across the cluster giving unnecessary network trips - we would really want all connections to be made to the node where the consumer is. We could then deploy a connection factory with loadbalancing=false also in deploy-hasingleton - this would ensure the connections are on the same node. If failure occurs the queue would failover onto another node - all well and good. If the system is then stopped and restarted, the ha singleton node would be chosen to be the first node started, but the node with the messages would be another node, so messages would be sucked from that node as new ones are arriving on the new singleton node. This would message processing would go out order. If we want to support this use case, a simple solution for now for people who want JBoss MQ style functionality is just to deploy the whole of JBM in the deploy-hasingleton directory, and we could then think about implementing native singleton functionality in JBM 2. Comments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104715#4104715 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104715

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Checking DeploymentContext for failures

by adrian＠jboss.org

We're having this discussion in two places, let's keep it here. ;-) You already know the context name of the deployment controller context and how to retrieve it (assuming it has got as far as creating it :-) It's an implementation detail of the class you are changing. The ones you don't know about are those created by the deployers, i.e. the [Kernel|Service]ControllerContext You just need those deployers that create them to record them somewhere for you to check. Looking at the attachments can even be misleading, because the attachment may exist (created by the parsing deployer) but it never got as far as actually registering them in the controller. Or maybe the deployer tried to register it, but found it was a duplicate (already registered). So you'd actually be looking at the wrong context! Besides it's over engineered for the purpose. You just want a set of names that were definitely registered in the controller for that deployment. Once you have those, you also need to recurse through the DependencyInfo looking to find the possible root cause for failed contexts. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104693#4104693 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104693

18 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: [sim] problems with hibernate queries and dates

by camunda

Hi Ronald. I know, but thanks for creating an issue for it. I commented a possible fix there. Compatibility seems to be a big problem when it comes down to realy advanced queries :-/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104689#4104689 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104689

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Checking DeploymentContext for failures

by alesj

How does this take care of DeploymentControllerContext? Since it's not a part of Deployers. Or just treating this ControllerContext lookup differently? Via AttachmentCreator this was transparent. :-) | public class ControllerContextAttachmentChecker extends AbstractAttachmentChecker<ControllerContext> | { | public ControllerContextAttachmentChecker() | { | super(ControllerContext.class); | } | | protected ControllerContext getControllerContext(Controller controller, ControllerContext attachment) | { | return attachment; | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104685#4104685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104685

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Weird issue with interceptors

by adrian＠jboss.org

There's something wrong with the hotdeployment of interceptors. If I run the bank ejb3 test from a fresh boot then the interceptor test works. However if I rerun the test it fails. Looks like the interceptors are not getting re-initialised when you redeploy the jar? I'll take a quick look to see if it is easy to figure out rather than embedded somewhere deep in aop. ;-) NOTE: These are interceptors from the deployment descriptor (which doesn't change), so I doubt this is a classloading issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104682#4104682 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104682

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Checking DeploymentContext for failures

by adrian＠jboss.org

I answered this on the dev-list since the forums were down, copied to here: You don't need to do anything so complicated. You just need the relevant deployers to record the context names in some well defined place, e.g. the Deployment{Unit|Context} It's probably important enough to use a special method rather than an attachment. e.g. | public class BeanMetaDataDeployer extends | AbstractSimpleRealDeployer<BeanMetaData> | { | /** The kernel controller */ | private final KernelController controller; | | /** | * Create a new BeanDeployer. | * | * @param kernel the kernel | * @throws IllegalArgumentException for a null kernel | */ | public BeanMetaDataDeployer(Kernel kernel) | { | super(BeanMetaData.class); | if (kernel == null) | throw new IllegalArgumentException("Null kernel"); | controller = kernel.getController(); | setComponentsOnly(true); | } | | @Override | public void deploy(DeploymentUnit unit, BeanMetaData deployment) | throws DeploymentException | { | KernelControllerContext context = new | AbstractKernelControllerContext(null, deployment, null); | try | { | controller.install(context); | + unit.addControllerContextName(deployment.getName()); | } | catch (Throwable t) | { | throw DeploymentException.rethrowAsDeploymentException("Error | deploying: " + deployment.getName(), t); | } | } | | @Override | public void undeploy(DeploymentUnit unit, BeanMetaData deployment) | { | + unit.removeControllerContextName(deployment.getName()); | controller.uninstall(deployment.getName()); | } | } | In practice, the component deployment unit name should be the context name. This is at least true for the POJO and Service deployers. So you could just add it as some kind of easy declaration in the constructor: | public BeanMetaDataDeployer(Kernel kernel) | { | super(BeanMetaData.class); | if (kernel == null) | throw new IllegalArgumentException("Null kernel"); | controller = kernel.getController(); | setComponentsOnly(true); | // obviously some shorter property name ;-) | setComponentDeploymentNameIsControllerContextName(true); | } | and handle it in the abstract classes: | deploy(...); // will throw an error if not registered in the | controller | if (unit.isComponent() && | isComponentDeploymentNameControllerContextName()) | addComponentContextName(unit.getSimpleName()); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104680#4104680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104680

18 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Leaking annotation API

by anil.saldhana＠jboss.com

The metadata project has a failing test. | Failed tests: | test1(org.jboss.test.metadata.annotation.ejb3.AnnotationEjb3UnitTestCase) | | Tests run: 99, Failures: 1, Errors: 0, Skipped: 0 | The error is: | <failure type="junit.framework.AssertionFailedError" message="no assembly de | scriptor defined">junit.framework.AssertionFailedError: no assembly descriptor d | efined^M | at junit.framework.Assert.fail(Assert.java:47)^M | at junit.framework.Assert.assertTrue(Assert.java:20)^M | at junit.framework.Assert.assertNotNull(Assert.java:220)^M | at org.jboss.test.metadata.annotation.ejb3.AnnotationEjb3UnitTestCase.te | st1(AnnotationEjb3UnitTestCase.java:164)^M | at org.jboss.test.metadata.annotation.ejb3.AnnotationEjb3UnitTestCase.te | st1(AnnotationEjb3UnitTestCase.java:164)^M | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104659#4104659 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104659

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Checking DeploymentContext for failures

by alesj

Regarding http://jira.jboss.com/jira/browse/JBMICROCONT-187. What's the best way to get failing ControllerContexts that belong to DeploymentContext param? This is what I came up currently: | protected final void checkComplete( | DeploymentContext context, | Map<String, Throwable> contextsInError, | Map<String, Set<MissingDependency>> contextsMissingDependencies, | Set<ControllerContext> notInstalled, | List<ControllerState> states) | { | Attachments attachments = context.getDeploymentUnit(); | if (attachments != null && checkers != null) | { | for (AttachmentChecker checker : checkers) | { | ControllerContext cc = checker.getControllerContext(controller, attachments); | if (cc != null) | { | if (cc.getState().equals(cc.getRequiredState()) == false && notInstalled.contains(cc)) | { | checkControllerContext(cc, contextsInError, contextsMissingDependencies, states); | } | } | } | } | List<DeploymentContext> children = context.getChildren(); | if (children != null && children.isEmpty() == false) | { | for(DeploymentContext child : children) | checkComplete(child, contextsInError, contextsMissingDependencies, notInstalled, states); | } | } | where AttachmentChecker looks like this, e.g. Bean checker: | public abstract class AbstractAttachmentChecker<T> implements AttachmentChecker | { | private Class<T> type; | | protected AbstractAttachmentChecker(Class<T> type) | { | if (type == null) | throw new IllegalArgumentException("Null type."); | this.type = type; | } | | public ControllerContext getControllerContext(Controller controller, Attachments attachments) | { | T attachment = attachments.getAttachment(type); | if (attachment != null) | return getControllerContext(controller, attachment); | | return null; | } | | protected abstract ControllerContext getControllerContext(Controller controller, T attachment); | } | | public class BeanAttachmentChecker extends AbstractAttachmentChecker<BeanMetaData> | { | public BeanAttachmentChecker() | { | super(BeanMetaData.class); | } | | protected ControllerContext getControllerContext(Controller controller, BeanMetaData attachment) | { | return controller.getContext(attachment.getName(), null); | } | } | Another checker implementations would include ServiceAC (mbeans) and ControllerContextAC (OSGi deployments). Any others? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104658#4104658 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104658

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by bstansberry＠jboss.com

Re: @Clustered: 1) When moved to cluster module, it was repackaged into org.jboss.annotation.ha. I want to put it back in org.jboss.annotation.ejb. Leaving it in cluster module is fine with me. Reason is newly discovered EJBTHREE-1109 and EJBTHREE-1110 imply that this annotation should have a homeLoadBalancePolicy attribute. That makes the annotation ejb-specific. So, if its ejb specific, might as well keep the old package name and not cause issues for pre-existing applications. 2) Please take back ClusteredImpl. That class is an internal ejb3 implementation detail of how you guys consume xml metadata by turning it into a class annotation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104649#4104649 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104649

18 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Missing BasicInvocationContext class

by mark.little＠jboss.com

This shows the version was 1.2.1, so we're safe, i.e., no issue with EAP. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104647#4104647 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104647

18 years, 4 months

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 November 2007