[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI
by Will Tatam (JIRA)
[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ]
Will Tatam commented on WFLY-3636:
----------------------------------
As there is a pull request for EAP, does this mean we might see merged in as part of 7.x ?
> Improve monitoring of JMS pooled connection in JBoss CLI
> --------------------------------------------------------
>
> Key: WFLY-3636
> URL: https://issues.jboss.org/browse/WFLY-3636
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.1.0.Final
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
> Fix For: 11.0.0.Alpha1
>
>
> At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools:
> {noformat}
> "pool" => {
> "ActiveCount" => "0",
> "AvailableCount" => "0",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "0",
> "CreatedCount" => "0",
> "DestroyedCount" => "0",
> "InUseCount" => "0",
> "MaxCreationTime" => "0",
> "MaxUsedCount" => "0",
> "MaxWaitCount" => "0",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "0",
> "statistics-enabled" => false
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1840) patch rollback should suggest installed patch ids
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1840?page=com.atlassian.jira.plugi... ]
Bartosz Spyrko-Śmietanko moved JBEAP-6249 to WFCORE-1840:
---------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1840 (was: JBEAP-6249)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Target Release: (was: 7.1.0.GA)
Affects Version/s: 3.0.0.Alpha8
(was: 7.1.0.DR5)
Fix Version/s: (was: 7.0.4.GA)
> patch rollback should suggest installed patch ids
> -------------------------------------------------
>
> Key: WFCORE-1840
> URL: https://issues.jboss.org/browse/WFCORE-1840
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 3.0.0.Alpha8
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Labels: downstream_dependency
>
> patch rollback <TAB> currently suggests named parameters, but it doesn't give user a clue that a patch id is needed. eg:
> {noformat}
> [disconnected /] patch rollback --
> --override-all --override-modules --override= --preserve= --reset-configuration= --rollback-to
> {noformat}
> A list of installed patches should be added to the suggestions. If there are no patches installed on the system, 'rollback' action should not be suggested on patch <TAB>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow edited comment on JASSIST-261 at 9/29/16 9:30 AM:
---------------------------------------------------------------
[~chiba] I think it is too early to merge the java9-only branch to master. After thinking more about your questions, I would like to release a javassist for Java9 EA, so that other projects like Hibernate can consume that. It would be good if this javassist release is marked CR1 or something like that, to reflect that its for JDK9 EA (e.g. not certain to work with JDK9 final).
If we also release 3.21.0 for the master branch soon, that also sounds good to me.
was (Author: smarlow):
[~chiba] I think it is too early to merge the java9-only branch to master. After thinking more about your questions, I would like to release a javassist for Java9 EA, so that other projects like Hibernate can consume that. It would be good if this javassist release is marked marked CR1 or something like that, to reflect that its for JDK9 EA (e.g. not certain to work with JDK9 final).
If we also release 3.21.0 for the master branch soon, that also sounds good to me.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-261:
--------------------------------------
[~chiba] I think it is too early to merge the java9-only branch to master. After thinking more about your questions, I would like to release a javassist for Java9 EA, so that other projects like Hibernate can consume that. It would be good if this javassist release is marked marked CR1 or something like that, to reflect that its for JDK9 EA (e.g. not certain to work with JDK9 final).
If we also release 3.21.0 for the master branch soon, that also sounds good to me.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-3636:
-----------------------------------
JBCA-1330 prevents the XA stats to be updated (but the pool stats work as expected).
> Improve monitoring of JMS pooled connection in JBoss CLI
> --------------------------------------------------------
>
> Key: WFLY-3636
> URL: https://issues.jboss.org/browse/WFLY-3636
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.1.0.Final
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
> Fix For: 11.0.0.Alpha1
>
>
> At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools:
> {noformat}
> "pool" => {
> "ActiveCount" => "0",
> "AvailableCount" => "0",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "0",
> "CreatedCount" => "0",
> "DestroyedCount" => "0",
> "InUseCount" => "0",
> "MaxCreationTime" => "0",
> "MaxUsedCount" => "0",
> "MaxWaitCount" => "0",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "0",
> "statistics-enabled" => false
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-7240:
---------------------------------
Summary: CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split (was: CacheRegistry is missing entries (e.g. client mappings) following a merge)
> CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7240
> URL: https://issues.jboss.org/browse/WFLY-7240
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> One of the manifestation of the issue:
> # start 2 nodes with SLSB with TUNNEL transport
> # start both nodes creating 2 clusters (or partitions)
> # start ejb client
> # start GossipRouter and wait for merge
> # ejb client keeps talking only to known node; never receives a topology update
> This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-7240:
---------------------------------
Description:
One of the manifestation of the issue:
# start 2 nodes with SLSB with TUNNEL transport
# start both nodes creating 2 clusters (or partitions)
# start ejb client
# start GossipRouter and wait for merge
# ejb client keeps talking only to known node; never receives a topology update
This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges.
was:
One of the manifestation of the issue:
# start 2 nodes with SLSB with TUNNEL transport
# start both nodes creating 2 partitie
# start ejb client
# start GossipRouter and wait for merge
# ejb client keeps talking only to 1st node, never receives a topology update
This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges.
> CacheRegistry is missing entries (e.g. client mappings) following a merge
> -------------------------------------------------------------------------
>
> Key: WFLY-7240
> URL: https://issues.jboss.org/browse/WFLY-7240
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> One of the manifestation of the issue:
> # start 2 nodes with SLSB with TUNNEL transport
> # start both nodes creating 2 clusters (or partitions)
> # start ejb client
> # start GossipRouter and wait for merge
> # ejb client keeps talking only to known node; never receives a topology update
> This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-7240:
------------------------------------
Summary: CacheRegistry is missing entries (e.g. client mappings) following a merge
Key: WFLY-7240
URL: https://issues.jboss.org/browse/WFLY-7240
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final, 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Priority: Critical
One of the manifestation of the issue:
# start 2 nodes with SLSB with TUNNEL transport
# start both nodes creating 2 partitie
# start ejb client
# start GossipRouter and wait for merge
# ejb client keeps talking only to 1st node, never receives a topology update
This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months