[Design of JBoss Profiler] - Jboss Profiler startup issue
by kompakarpg
Hi, i am having trouble startup the jboss.
In run.bat I added:
set JAVA_OPTS=%JAVA_OPTS% -server -Xmn154m -Xms768m -Xmx768m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=384m -XX:MaxPermSize=384m -Xss512k
set JAVA_OPTS=%JAVA_OPTS% -agentlib:jbossAgent -XrunjbossInspector:C:\Temp\profiler,include=com.unisys,ignore=*,memory=false
When starting JBoss, I get the following error and JBoss does not run.
this is the new DLL
Running process on Windows 5016
FATAL ERROR: JVMPI, an experimental interface, is no longer supported.
Please use the supported interface: the JVM Tool Interface (JVM TI).
For information on temporary workarounds contact: jvmpi_eol(a)sun.com
dpInspector> error in obtaining jvmpi interface pointer
Error occurred during initialization of VM
-Xrun library failed to init: jbossInspector
Press any key to continue . . .
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170688#4170688
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170688
17 years, 7 months
[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking
by prabhat.jha＠jboss.com
Here are few findings:
anonymous wrote :
| I did see few threads waiting on DB connection which Brian also pointed out. This was intentionally left out because caching whatever data that threads are trying to get would result into a huge memory footprint in some use cases. But what I am going to do is turn on caching for those data and see what that results into.
Changing the cache configuration for above results into good scalability. Earlier hibernate config was set to use lazy="extra" and apparently hibernate bypasses second level cache for this lazy loading configuration. This setting is recommended for large collection and hence was made default in portal. Changing it to lazy="true" forces hibernate to use second level cache which helps in scalability.
| #Node #Users
| 1 1400
| 2 2200
| 3 3300
| 4 4100
| 5 5500
|
So although ability to handle more load decreases for (2,3} node cluster, it helps with 4 and 5 nodes. I think this suggests that increasing heap size for each node would result into each node handling more load while keeping the scalability.
I have posted in Hibernate ML asking if there is a way to use cache with lazy="extra" because I think that will be optimal in this use case. Of course I wont know until I run tests.
Since this new jar fixes problem with OL and REPL_SYNC combination, I am going to run tests with this configuration as well.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170656#4170656
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170656
17 years, 7 months
[Design of AOP on JBoss (Aspects/JBoss)] - Optmizing Pointcut matching in instrumentation
by flavia.rainone＠jboss.com
While doing the optimization with the BindingCollection, I thought that it would be a good idea to do the same during instrumentation.
https://jira.jboss.org/jira/browse/JBAOP-603
At that time, my idea was to create a PointcutCollection, that would have methods for retrieval of pointcuts according to their type classification (execution, call, etc). This would be similar to BindingCollection, and I was considering the possibility of replacing this collection with a parameterized ClassifiedCollection for using with both binding and pointcuts.
Now, I'm not as sure this optimization is worthy to do at this point, so close to the release. I see that Kabir has added a few checks that call the isCall, isWithin, etc, methods in AspectManager, avoiding the trigger of a transformation step when possible. Maybe those checks are enough and we don't need to retrieve classified pointcuts for transformation.
What do you think, Kabir?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170650#4170650
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170650
17 years, 7 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Dynamic AOP API
by flavia.rainone＠jboss.com
I've been thinking about this API, and I realized that, if I was going to use it, I would rather do this:
String pointcut = "execution(*->new(..))";
| Object handle = DynamicAOP.bind(pointcut, MyAspect.class, "adviceName");
|
Than this:
String pointcut = "execution(*->new(..))";
| DynamicBindingOperation dbo = new DynamicBindingOperation();
| dbo.setPointcut(pontcut);
| AdviceInfo advice = new AdviceInfo(MyAspect.class, "adviceName");
| dbo.setAdviceInfo(advice);
| DynamicAOP.execute(dbo);
|
I mean, for simple operations we should try to keep it simple, making it possible to execute the whole thing in a couple of lines?
In this case, I think we could maintain the dbo, using it with more complex bindings.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170633#4170633
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170633
17 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Management removing all messages on shutdown
by clebert.suconic＠jboss.com
I just found a bug recently introduced. Looking at the SVN Logs it was introduced by the recent work on management.
If you cleanly shutdown the server, Shutdown hooks are undeploying the queues, and all the messages are being be deleted on a regular shutdown.
I have locally changed the journal to throw an exception if delete was called, and this is the place it is happening:
java.lang.Exception: trace
| at org.jboss.messaging.core.journal.impl.JournalImpl.appendDeleteRecordTransactional(JournalImpl.java:611)
| at org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager.storeDeleteTransactional(JournalStorageManager.java:231)
| at org.jboss.messaging.core.transaction.impl.TransactionImpl.addAcknowledgement(TransactionImpl.java:149)
| at org.jboss.messaging.core.server.impl.QueueImpl.deleteAllReferences(QueueImpl.java:481)
| at org.jboss.messaging.core.management.impl.MessagingServerControl.destroyQueue(MessagingServerControl.java:362)
| at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.destroyQueue(JMSServerManagerImpl.java:164)
| at org.jboss.messaging.jms.server.impl.JMSServerDeployer.undeploy(JMSServerDeployer.java:221)
| at org.jboss.messaging.core.deployers.impl.XmlDeployer.stop(XmlDeployer.java:230)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:56)
| at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:110)
| at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:97)
| at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.uninstallAction(KernelControllerContextAction.java:169)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.uninstallAction(KernelControllerContextAction.java:47)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
| at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:333)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1323)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1009)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:936)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:986)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:936)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:986)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:936)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:986)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:936)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:986)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:936)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:463)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:426)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:384)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:363)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
| at org.jboss.messaging.microcontainer.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:127)
| at org.jboss.messaging.microcontainer.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:199)
| at org.jboss.messaging.microcontainer.JBMBootstrapServer$Shutdown.run(JBMBootstrapServer.java:218)
|
We need to distinguish a real Queue being dropped to a shutdown event. On the latest you're not supposed to delete messages.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170624#4170624
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170624
17 years, 7 months
[Design of JMX on JBoss (JBoss/JMX)] - Re: my first JMX
by dikar
There is a simple example for you (in windows OS)
By the way ,you must add the jboss-system-x.x.x.jar and jboss-jmx-x.x.x.jar in your lib path(or eclipse build path),these jar in JBoss lib dir.
|
| ##############################################
| package JMX;
|
| import org.jboss.system.ServiceMBean;
|
| public interface HelloWorldServiceMBean extends ServiceMBean {
|
| public String getMessage();
| public void setMessage(String message);
|
| }
| /***********************************************************/
| package JMX;
|
|
|
| import org.jboss.system.ServiceMBeanSupport;
| public class HelloWorldService extends ServiceMBeanSupport implements HelloWorldServiceMBean {
| private String message;
|
| public HelloWorldService()
| {
| super();
| // TODO Auto-generated constructor stub
| }
|
| public String getMessage() {
| System.out.println("getMessage()=" + message);
| return message;
| }
|
|
|
| public void setMessage(String message) {
| System.out.println("setMessage(" + message + ")");
| this.message = message;
|
|
| }
|
|
| }/***********************************************************/
| jboss-service.xml
| -----------------------------------------------------------------------------------
| <?xml version="1.0" encoding="UTF-8"?>
| <server>
| <mbean code="JMX.HelloWorldService" name="JBoss:service=HelloWorldService">
| <attribute name="Message">Hello World</attribute>
| </mbean>
| </server>----------------------------------------------------------
|
|
In your JBOSS deploy dir ,for example:"jboss-4.2.2.GA\server\default\deploy" ,you create a dir named "Hello.sar" and new create 2 files in "Hello.sar" ,one named "JMX" and other named "META-INF".Then put the HelloWorldService.class and HelloWorldServiceMBean.class in your "JMX" dir. and new a XML file named jboss-service.xml write the content like above red XML.
ok you can run your JBOSS and access the http://127.0.0.1:8080/jmx-console/
find the "service=HelloWorldService " in JBoss domain.
Note: I'm very sorry that my English not well.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170615#4170615
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170615
17 years, 7 months
[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5
by kabir.khan＠jboss.com
I have worked through the issues above, but have reached the final hurdle with my new scope tests. I am deploying the following in a deployment using classloader scoping
| <?xml version="1.0" encoding="UTF-8"?>
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <interceptor xmlns="urn:jboss:aop-beans:1.0"
| name="ScopedInterceptor"
| class="org.jboss.test.aop.scopeddependency.ScopedInterceptor">
| </interceptor>
|
| <bind xmlns="urn:jboss:aop-beans:1.0"
| pointcut="execution(* org.jboss.test.aop.scopeddependency.ScopedTester->*(..))">
| <interceptor-ref name="ScopedInterceptor"/>
| </bind>
|
| <bean name="ScopedTester" class="org.jboss.test.aop.scopeddependency.ScopedTester"/>
|
| </deployment>
|
The aop beans from interceptor and bind get deployed into a scoped controller. The ScopedTester gets deployed into the main controller, and gets a dependency on Factory$ScopedInterceptor from the binding. However, ScopedTester is deployed in the main controller and cannot see Factory$ScopedInterceptor since that is deployed in the scoped controller, which gives this exception:
| org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
|
| ScopedTester
| -> Factory$ScopedInterceptor{Instantiated:** NOT FOUND Depends on 'Factory$ScopedInterceptor' **}
|
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| Factory$ScopedInterceptor -> ** NOT FOUND Depends on 'Factory$ScopedInterceptor' **
|
As mentioned I am deploying all the aop beans myself and ripping them out of the deployment. A solution would be to handle all beans in a deployment myself if it is scoped and contains some aop beans, but that feels a bit hacky to me? Alternatively, would it be possible to place the annotation causing a scoped controller on all the beans in the deployment if it is scoped and contains some aop beans? I don't know how I would determine that the deployment is scoped and contains some aop beans though if the aop stuff is in an -aop.xml and the other beans in a -beans.xml?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170606#4170606
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170606
17 years, 7 months