[Design of JBoss/Tomcat Integration] - Re: JBossWeb-based load metrics for mod_cluster
by bstansberry＠jboss.com
Just an FYI on clustered webapps:
JBossCacheManagerMBean exposes two different attributes re: the session count:
| /**
| * Gets the number of sessions active on this node. This includes
| * replicated sessions that have not been accessed on this node.
| */
| long getActiveSessionCount();
|
| /**
| * Gets the count of sessions known to this manager, excluding those
| * in the distributed stored that have not been accessed on this node.
| */
| long getLocalActiveSessionCount();
|
I'll have to check if it also exposes via some JMX magic the standard "ActiveSessions" metric you are looking for. If not, I'll make sure it does. It will return the same value as getActiveSessionCount().
Re: using these in a load balance metric, if the intent of a session count metric is to function as a semi-proxy for memory usage, getting the ActiveSessionCount value does that best, as it includes sessions in the distributed cache, which are using ~ the same memory as a locally active session.
If the intent of the metric is to somehow use a session count as a representation of some other kind of system load, then LocalActiveSessionCount is probably better.
Perhaps a flag on the metric bean could control this? With logic built in to handle the non-clustered webapps that don't support LocalActiveSessionCount?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171819#4171819
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171819
17 years, 7 months
[Design of EJB 3.0] - Classloading problem in proxy factories
by bstansberry＠jboss.com
I'm testing proxy-clustered and am seeing a failure that looks like a problem in the core proxy module.
Test is doing a lookup of an SLSB; call to ProxyFactory to create the proxy fails:
| javax.naming.NamingException: Could not dereference object [Root exception is java.lang.RuntimeException: Could not create the EJB3 Business Proxy implementing "org.jboss.ejb3.test.clusteredsession.ClusteredStatelessRemote" for clusteredStateless]
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1340)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:765)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| at org.jboss.ejb3.test.clusteredsession.unit.StatelessUnitTestCase.testLoadbalance(StatelessUnitTestCase.java:72)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
| at junit.extensions.TestSetup.run(TestSetup.java:27)
| Caused by: java.lang.RuntimeException: Could not create the EJB3 Business Proxy implementing "org.jboss.ejb3.test.clusteredsession.ClusteredStatelessRemote" for clusteredStateless
| at org.jboss.ejb3.proxy.factory.session.SessionProxyFactoryBase.createProxyBusiness(SessionProxyFactoryBase.java:234)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
| at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
| Caused by: java.lang.LinkageError: loader constraints violated when linking org/jboss/ejb3/test/clusteredsession/NodeAnswer class
| at java.lang.Class.getDeclaredConstructors0(Native Method)
| at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
| at java.lang.Class.getConstructor0(Class.java:2671)
| at java.lang.Class.getConstructor(Class.java:1629)
| at org.jboss.ejb3.proxy.factory.ProxyFactoryBase.createProxyConstructor(ProxyFactoryBase.java:124)
| at org.jboss.ejb3.proxy.factory.session.SessionProxyFactoryBase.createProxyBusiness(SessionProxyFactoryBase.java:212)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
| at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:206)
| at org.jboss.remoting.Client.invoke(Client.java:1708)
| at org.jboss.remoting.Client.invoke(Client.java:612)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:84)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.proxy.remoting.IsLocalProxyFactoryInterceptor.invoke(IsLocalProxyFactoryInterceptor.java:72)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.remoting.ClusteredPojiProxy.invoke(ClusteredPojiProxy.java:79)
| at $Proxy2.createProxyBusiness(Unknown Source)
| at org.jboss.ejb3.proxy.objectfactory.session.SessionProxyObjectFactory.createProxy(SessionProxyObjectFactory.java:129)
| at org.jboss.ejb3.proxy.clustered.objectfactory.session.SessionClusteredProxyObjectFactory.getProxy(SessionClusteredProxyObjectFactory.java:76)
| at org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory.getObjectInstance(ProxyObjectFactory.java:146)
| at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
| at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1315)
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1332)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:765)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| at org.jboss.ejb3.test.clusteredsession.unit.StatelessUnitTestCase.testLoadbalance(StatelessUnitTestCase.java:72)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
| at junit.extensions.TestSetup.run(TestSetup.java:27)
|
Failure is coming in the SessionProxyFactoryBase code that attempts to replace the cached proxy constructor with one created using the TCCL:
| // Obtain the correct business proxy constructor
| Constructor<?> constructor = this.getConstructorsProxySpecificBusinessInterface().get(
| businessInterfaceName.trim());
|
| /*
| * In place for web injection (isolated CL)
| */
| ClassLoader tcl = Thread.currentThread().getContextClassLoader();
| try
| {
| // See if we can get at the bean class from the TCL
| Class<?> businessInterfaceClass = Class.forName(businessInterfaceName, false, tcl);
|
| // If so, use the TCL to generate the Proxy class, not the Container CL
| Set<Class<?>> businessInterfaces = new HashSet<Class<?>>();
| businessInterfaces.add(businessInterfaceClass);
| constructor = this.createProxyConstructor(businessInterfaces, tcl);
|
| }
| catch (ClassNotFoundException cce)
| {
| // Ignore
| }
|
The business interface is simple:
| public interface ClusteredStatelessRemote
| {
| NodeAnswer getNodeState();
| }
|
It's odd to me that Class.forName() is able to load the ClusteredStatelessRemote class using the TCCL, and a nested call to Proxy.getProxyClass(...) passing the classloader and the interface is able to generate a proxy class, yet there is a LinkageError trying to find the constructor.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171810#4171810
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171810
17 years, 7 months
[Design of JBoss Build System] - Improvements
by epbernard
Here is a list of issues we encounter when trying to work with the whole maven enchilada.
1. There is no staging server / level when publishing a version in Maven. On a modular project portfolio (say Hibernate), it means you need to push a version in the wild, give it a try with related bits of the project and potentially fix issues that came up during the release process.
In a pure Maven way, thou shalt not republish the same version. The reason comes from:
- the absence of a staging server
- a rather stupid caching approach
Today, people either have to
a. create a new release (which is very long as you need to update doc and a few other things) => not practical
b. override the broken fresh release. People that decided to go ahead of time and try from maven before the official announcement now have a wrong cache
While this can be worked around somehow when a single person is releasing all the dependent modules, there is no solution today when the release is done by multiple people.
2. There is no (that I am aware of) continuous build integration of JBoss AS using snapshots, so errors come up late in the game when final releases are already in Maven. This makes problem 1. even worse.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171809#4171809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171809
17 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging discussion:
by clebert.suconic＠jboss.com
As we were talking over IRC, transactions on paging are a little bit more complicated.
We could have multiple destinations in page-mode and we need to guarantee a single commit/rollback point for those.
To correctly deal with transactions on those cases, I'm planning to use the journal to control the completeness of the transaction.
This is the current solution I have in mind:
I - When a message is sent transactionally to an address in page-mode, I will aways send it with the TransactionID
II - When (before) the transaction is completed (Prepare/Commit) I will add a new record on the Journal that will contain the number of Messages on Page (I'm calling this PageTransaction). (We will hold the PageTransactions somewhere on the memory).
III - When depaging, I will verify if there is a PageTransaction available,
If not, I will verify if there is a transaction pending. (i.e. transaction has started but committed wasn't called yet).
If pending transaction -> The depaged messages will be on wait mode until the commit is called.
else (no pending transaction) -> The messages will be just discarded as that means the transaction was aborted somehow (rollback or server aborted on another server's execution).
if evertyhing was OK while depaging I will update the PageTransaction on the journal with the numberOfMessages consumed, or delete the PageTransaction if numberOfMessages = 0, so that would release the record for reclaiming.
In summary three is:
During depage:
It has a page-transaction
- update page-transaction NRMessage = NRMessage - NRMessagesOnThePage
(Delete it if 0)
- send the messages to the PostOffice/Journal
It doesn't have a page-transaction
if there is a pending transaction.. put those messages waiting for the transaction complete
else... transaction is aborted
The only downside of this is if the user has 1 transaction for each message, while the user is sending 1 million messages. (1 million transactions on the memory). But that would be an anti-pattern and I don't know how we could guarantee atomicity without the journal at this point.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171804#4171804
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171804
17 years, 7 months
[Design the new POJO MicroContainer] - Re: vfsmemory url problem
by alesj
"alesj" wrote :
| Last deployers commit marked with JBDEPLOY-75
| resolved the issue - I removed the 'classes' path,
| leaving only guid host name.
You need trunk VFS and Deployers-VFS.
And this patch:
| Index: src/main/org/jboss/aop/asintegration/jboss5/JBoss5ClassPoolFactory.java
| ===================================================================
| --- src/main/org/jboss/aop/asintegration/jboss5/JBoss5ClassPoolFactory.java (revision 77280)
| +++ src/main/org/jboss/aop/asintegration/jboss5/JBoss5ClassPoolFactory.java (working copy)
| @@ -21,7 +21,6 @@
| */
| package org.jboss.aop.asintegration.jboss5;
|
| -import java.net.MalformedURLException;
| import java.net.URL;
| import java.util.Map;
|
| @@ -29,7 +28,6 @@
| import javassist.scopedpool.ScopedClassPool;
| import javassist.scopedpool.ScopedClassPoolFactory;
| import javassist.scopedpool.ScopedClassPoolRepository;
| -
| import org.jboss.aop.classpool.AOPClassPool;
| import org.jboss.aop.classpool.AbstractJBossClassPoolFactory;
| import org.jboss.aop.classpool.ExtraClassPoolFactoryParameters;
| @@ -75,16 +73,6 @@
| if (module == null)
| return null;
|
| - try
| - {
| - URL tempUrl = module.getDynamicClassRoot();
| - if (tempUrl == null)
| - return null;
| - return new URL(tempUrl, "/classes");
| - }
| - catch (MalformedURLException e)
| - {
| - throw new RuntimeException(e);
| - }
| + return module.getDynamicClassRoot();
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171803#4171803
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171803
17 years, 7 months