[Clustering/JBoss] - Can't get JBoss to use custom loadbalancer
by heineson
Hello,
I need to write a custom loadbalancer or interceptor to route EJB requests to different servers in the cluster. The problem is I can't get JBoss to use my LB. Anyone have an idea? I am thinking maybe jboss can't find my class and therefore doesn't use it. If this is the case, where should I put the LB class?
section of jboss.xml for the clustered (stateless) bean:
| <cluster-config>
| <partition-name>MyPartition</partition-name>
| <bean-load-balance-policy>
| com.acme.MyCustomBalancer
| </bean-load-balance-policy>
| <home-load-balance-policy>
| com.acme.MyCustomBalancer
| </home-load-balance-policy>
| </cluster-config>
|
And the simple LB I try to use for testing
| public class MyCustomBalancer extends FirstAvailable {
|
| @Override
| public Object chooseTarget(FamilyClusterInfo clusterFamily, Invocation routingDecision) {
| System.out.println("AAAAAAAAAAA");
| //List targets = clusterFamily.getTargets();
| return super.chooseTarget(clusterFamily, routingDecision);
| }
|
| }
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236772#4236772
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236772
17 years, 1 month
[Beginners Corner] - Moving JSF 1.1 application to 1.2
by mattc＠landslide.com
We are trying to move our application from a JSF 1.1 based AS to a JSF 1.2 AS. In our current implementation we have the pattern where a XMLHttp browser request is made to a servlet which will try to reference the FacesContext in the service() method. This all worked under 1.1 just fine but when we deploy this to a 1.2 based server we get stack traces like:
java.lang.NullPointerException
at org.apache.catalina.connector.Request.setAttribute(Request.java:1443)
at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
at com.sun.faces.context.RequestMap.put(ExternalContextImpl.java:1087)
at com.sun.faces.util.RequestStateManager.getStateMap(RequestStateManager.java:281)
at com.sun.faces.util.RequestStateManager.set(RequestStateManager.java:223)
at com.sun.faces.el.FacesCompositeELResolver.setChainType(FacesCompositeELResolver.java:159)
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:71)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at com.sun.faces.application.ValueBindingValueExpressionAdapter.getValue(ValueBindingValueExpressionAdapter.java:113)
at com.salesgene.servlets.tree.TreeNavigationServlet.service(TreeNavigationServlet.java:54)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.salesgene.common.filters.UserSessionFilter.doProcessing(UserSessionFilter.java:355)
at com.salesgene.common.filters.UserSessionFilter.doFilter(UserSessionFilter.java:197)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
This happens in every instance where we try to reference managed beans in a servlet. Oh, and we are getting the FacesContext following this approach:
LifecycleFactory lifecycleFactory = (LifecycleFactory)
FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle = lifecycleFactory.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
// Create new FacesContext.
FacesContextFactory contextFactory = (FacesContextFactory)
FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
facesContext = contextFactory.getFacesContext(
request.getSession().getServletContext(), request, response, lifecycle);
// Create new View.
UIViewRoot view = facesContext.getApplication().getViewHandler().createView(
facesContext, "");
facesContext.setViewRoot(view);
// Set current FacesContext.
FacesContextWrapper.setCurrentInstance(facesContext);
Anyhelp or advice would be most appreciated!
-matt
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236762#4236762
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236762
17 years, 1 month
[JBoss Messaging] - Re: Performance Numbers for JBoss Messaging 2.0
by timfox
We haven't produced any scientific results and won't publish any until we can do them properly (hopefully before GA), but we have done some ad-hoc tests, to give you a taste:
Performance very much depends on your hardware. Using a single quad core Xeon server with 16 GiB RAM and SAS hard drives as the messaging server we can currently hit around 50K *persistent* messages per second, each message is around 1100 bytes in size, that's a data persistence rate of around 60MiBytes/sec which is *very* fast.
We hope to push that to around 100MiB/s which is close to saturating the disk's max physical write rate.
For non persistent messages, on a single server I did about 350K small messages per second (empty bodies) and IIRC around 100K 1100 byte messages per sec.
I don't want to be more specific than that right now, since the above results are not very scientific but they should give you an indication of what JBM 2 is capable of.
Why not try it out yourself?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236750#4236750
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236750
17 years, 1 month
[JBoss jBPM] - Enable message size Greater than 4KB
by paul.robinson＠arjuna.com
Hello,
I'm using jBPM 3.2.5.SP5 within SOA-P 4.3.0CP01 with a "BpmProcessor" action. I pass the BODY_CONTENT of my esb message to the jBPM process. My ESB message is 5KB.
When i try to pass a message to the jBPM process action, I get an error stating that:
| ERROR [org.hibernate.util.JDBCExceptionReporter] ERROR: value too long for type character varying(4000)
|
So I'm guessing that due to the DB schema I can only have messages up-to 4KB in size. I retried with a 3.9KB message and the problem did not appear.
I have noticed that I can run the same scenario, with 5KB messages, in "SOA-P 4.3.0CP01.CR2" which uses jBPM 3.2.5.SP1 without seeing the error. So, I assumed that the DB schema has changed between these jBPM versions. I did some searching on this forum and Jira and I can see that there has been quite a few changes to field sizes, in the DB schema, recently. I also notice that people have been having a number of problems that has caused some field sizes to be changed back in subsequent jBPM versions.
Can anyone tell me if there is an elegant way of allowing 5KB messages, without hacking the DB schema directly?
Thanks a lot,
Paul.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236749#4236749
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236749
17 years, 1 month