[JBoss JIRA] (WFLY-794) javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reopened WFLY-794:
---------------------------------
Assignee: Stuart Douglas (was: Bartosz Baranowski)
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-794
> URL: https://issues.jboss.org/browse/WFLY-794
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Alex Corvino
> Assignee: Stuart Douglas
> Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown.
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final).
> Note that this behavior is NOT seen when connecting to another JBoss server.
> Full stack trace:
> {code}
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> ... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> ... 37 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2190) Priviledge alignment for scoped resources
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-2190?page=com.atlassian.jira.plugin.... ]
Heiko Braun updated WFLY-2190:
------------------------------
Description:
server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}?
was:
server-groups show different privildges for server-group=* and server-group=<specific instance>. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
wouldit be possible that the operation permissions for server-group=<specific instance>:<add|remove> show the same permissions as server-group=*:<add|remove>?
> Priviledge alignment for scoped resources
> -----------------------------------------
>
> Key: WFLY-2190
> URL: https://issues.jboss.org/browse/WFLY-2190
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Fix For: 8.0.0.CR1
>
>
> server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
> Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2190) Priviledge alignment for scoped resources
by Heiko Braun (JIRA)
Heiko Braun created WFLY-2190:
---------------------------------
Summary: Priviledge alignment for scoped resources
Key: WFLY-2190
URL: https://issues.jboss.org/browse/WFLY-2190
Project: WildFly
Issue Type: Enhancement
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 8.0.0.CR1
server-groups show different privildges for server-group=* and server-group=<specific instance>. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
wouldit be possible that the operation permissions for server-group=<specific instance>:<add|remove> show the same permissions as server-group=*:<add|remove>?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2058) Standalone profile hangs using Java 8 developer preview
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-2058?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-2058:
-------------------------------
Issue Type: Bug (was: Feature Request)
Priority: Major (was: Minor)
> Standalone profile hangs using Java 8 developer preview
> -------------------------------------------------------
>
> Key: WFLY-2058
> URL: https://issues.jboss.org/browse/WFLY-2058
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Alpha4
> Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
> Reporter: Gerard Krupa
> Assignee: Jason Greene
> Labels: hangs, java8, jdk8, standalone.bat
> Attachments: server.log
>
>
> When attempting to run the standalone profile after a clean install, the server hangs after
> 22:23:08,362 INFO [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting
> The log only shows:
> 22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
> ...
> 22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2058) Standalone profile hangs using Java 8 developer preview
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-2058?page=com.atlassian.jira.plugin.... ]
jaikiran pai closed WFLY-2058.
------------------------------
Resolution: Duplicate Issue
Duplicate of WFLY-2057
> Standalone profile hangs using Java 8 developer preview
> -------------------------------------------------------
>
> Key: WFLY-2058
> URL: https://issues.jboss.org/browse/WFLY-2058
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Alpha4
> Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
> Reporter: Gerard Krupa
> Assignee: Jason Greene
> Labels: hangs, java8, jdk8, standalone.bat
> Attachments: server.log
>
>
> When attempting to run the standalone profile after a clean install, the server hangs after
> 22:23:08,362 INFO [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting
> The log only shows:
> 22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
> ...
> 22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1710:
---------------------------
Workaround Description: Place *FRAG* just above the transport. FRAG (in contrary to FRAG2) uses {{Message.size()}} to determine whether a message needs to be fragmented, and therefore takes headers into account, too.
Workaround: Workaround Exists
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1710:
--------------------------------
As a quickfix, we could place a *second* FRAG2 just above the transport: if VIEW and INSTALL_MERGE_VIEW etc carry their payload in the message's body instead of the header, then that second FRAG2 would fragment the message again.
As a long term solution we should investigate whether FRAG2 cannot be *moved* (instead of duplicated) just above the transport.
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JASSIST-207) Inconsistent Stack Map when inserting throw Expression with Java 7
by Aftab Khan (JIRA)
[ https://issues.jboss.org/browse/JASSIST-207?page=com.atlassian.jira.plugi... ]
Aftab Khan commented on JASSIST-207:
------------------------------------
The issue has been resolved and working in javassist-3.18.1-GA.
Thanks,
Aftab
> Inconsistent Stack Map when inserting throw Expression with Java 7
> ------------------------------------------------------------------
>
> Key: JASSIST-207
> URL: https://issues.jboss.org/browse/JASSIST-207
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Reporter: Ben Romberg
> Assignee: Shigeru Chiba
> Priority: Critical
> Fix For: 3.18.1-GA, 3.19.0-GA
>
> Attachments: afterInsertThrowExpression.txt, AGDelegateImpl.class, beforeInsertThrowExpression.txt, conditionalThrowExceptionInserted.txt
>
>
> I wrote a unit-test for javassist, reproducing the issue:
> {code}
> public class ThrowExpressionCorruptsStackMapTableTest extends JvstTestRoot {
> public ThrowExpressionCorruptsStackMapTableTest(String name) {
> super(name);
> }
> public void testInsertLocalVars() throws Exception {
> CtClass cc = sloader.get("test4.LocalVars");
> CtMethod m1 = cc.getDeclaredMethod("run");
> m1.insertBefore("throw new AssertionError((Object) \"assertion error\");");
> cc.writeFile();
> Object obj = make(cc.getName());
> assertEquals(10, invoke(obj, "run"));
> }
> }
> {code}
> Throws:
> java.lang.VerifyError: Expecting a stack map frame in method test4.LocalVars.run()I at offset 45
> My use-case is almost the same, inserting a "throw AssertionError(...)" expression with insertBefore. However, I get a slightly different error message:
> Stack map does not match the one at exception handler 37 in method timeofday.TimeOfDay.getSecond()I at offset 27
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months