[JBoss JIRA] (WFLY-3101) CLI: hide stacktraces for exceptions w/o messages when logging errors
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3101?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3101:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 997584|https://bugzilla.redhat.com/show_bug.cgi?id=997584] from POST to MODIFIED
> CLI: hide stacktraces for exceptions w/o messages when logging errors
> ---------------------------------------------------------------------
>
> Key: WFLY-3101
> URL: https://issues.jboss.org/browse/WFLY-3101
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Final
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
>
> CommandContextImpl contains the following logic
> public void handleSafe(String line) {
> exitCode = 0;
> try {
> handle(line);
> } catch(Throwable t) {
> final StringBuilder buf = new StringBuilder();
> buf.append(t.getLocalizedMessage());
> Throwable t1 = t.getCause();
> while(t1 != null) {
> if(t1.getLocalizedMessage() != null) {
> buf.append(": ").append(t1.getLocalizedMessage());
> } else {
> t1.printStackTrace();
> }
> t1 = t1.getCause();
> }
> error(buf.toString());
> }
> }
> When an exception does not contain any message, e.g. in some cases IllegalArgumentException, etc, the full stacktraces are logged that are useful for debugging but not nice from the user interface point of view. It was suggested to hide them.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3478) subnet-match is completely broken
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3478?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3478:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1111575|https://bugzilla.redhat.com/show_bug.cgi?id=1111575] from POST to MODIFIED
> subnet-match is completely broken
> ---------------------------------
>
> Key: WFLY-3478
> URL: https://issues.jboss.org/browse/WFLY-3478
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Reporter: Rich DiCroce
> Assignee: Ivo Studensky
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
>
> subnet-match does not respect the value attribute. Instead, it seems to just pick the first interface it finds. No matter what I specify as a value, even if it's a value that's complete nonsense and doesn't match any IP address on my system, e.g.
> {code:xml}
> <interface name="public">
> <subnet-match value="1.2.3.0/24"/>
> </interface>
> {code}
> the ports end up bound to the only interface that is currently connected
> {noformat}
> 14:45:16,740 INFO [stdout] (ServerService Thread Pool -- 40) -------------------------------------------------------------------
> 14:45:16,740 INFO [stdout] (ServerService Thread Pool -- 40) GMS: address=normandy/GamingPortal, cluster=GamingPortal, physical address=192.168.1.105:3100
> 14:45:16,741 INFO [stdout] (ServerService Thread Pool -- 40) -------------------------------------------------------------------
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-794) javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-794:
----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 958166|https://bugzilla.redhat.com/show_bug.cgi?id=958166] from NEW to MODIFIED
> 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
> Security Level: Public(Everyone can see)
> Components: JMX
> Reporter: Alex Corvino
> Assignee: Eduardo Martins
> Labels: investigation_required
> Fix For: 9.0.0.Beta1
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3472) JBOSS_HOME is not available in domain.conf
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3472?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3472:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1083474|https://bugzilla.redhat.com/show_bug.cgi?id=1083474] from POST to MODIFIED
> JBOSS_HOME is not available in domain.conf
> -------------------------------------------
>
> Key: WFLY-3472
> URL: https://issues.jboss.org/browse/WFLY-3472
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> Description from linked BZ:
> Move the domain.conf call in domain.sh (and also domain.conf.bat in domain.bat) so it's called after the JBOSS_HOME is set. Then it's possible to use it in the configuration file.
> E.g. we use following line to enable security manager:
> JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==/tmp/security.policy -Djboss.home.dir=$JBOSS_HOME -Djboss.modules.policy-permissions=true"
> The order is correct in the scripts for standalone (so the JBOSS_HOME is available in its conf file).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (JBMETA-378) Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
by Jay Kumar SenSharma (JIRA)
Jay Kumar SenSharma created JBMETA-378:
------------------------------------------
Summary: Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
Key: JBMETA-378
URL: https://issues.jboss.org/browse/JBMETA-378
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: web
Affects Versions: 8.0.1.Final
Reporter: Jay Kumar SenSharma
Assignee: Jean-Frederic Clere
- JBoss Metadata APIs do not validate if the <servlet-mapping> tag has valid mappings or not. This should have been handled properly.
*Example:* If following kind of web.xml based application is deployed on WildFly9 then
{code}
<?xml version="1.0"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>servlets.MyServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<!--url-pattern></url-pattern--> <!-- NOTICE url-pattern-tag is missing here -->
</servlet-mapping>
</web-app>
{code}
- With the above kind of web.xml a NullPointerException is encountered during deployment.
{code}
15:50:20,207 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.NullPointerException
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleServletMappings(UndertowDeploymentInfoService.java:910)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:656)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
... 3 more
15:50:20,348 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3714) Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3714?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma commented on WFLY-3714:
-------------------------------------------
- Looks like the validation is needed from jboss-metadata side for the web module.
> Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3714
> URL: https://issues.jboss.org/browse/WFLY-3714
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
>
> - WildFly do not validate if the <servlet-mapping> tag has valid mappings or not. This should have been handled properly.
> *Example:* If following kind of web.xml based application is deployed on WildFly9 then
> {code}
> <?xml version="1.0"?>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0">
> <servlet>
> <servlet-name>MyServlet</servlet-name>
> <servlet-class>servlets.MyServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>MyServlet</servlet-name>
> <!--url-pattern></url-pattern--> <!-- NOTICE url-pattern-tag is missing here -->
> </servlet-mapping>
> </web-app>
> {code}
> - With the above kind of web.xml a NullPointerException is encountered during deployment.
> {code}
> 15:50:20,207 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleServletMappings(UndertowDeploymentInfoService.java:910)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:656)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> 15:50:20,348 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3714) Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
by Jay Kumar SenSharma (JIRA)
Jay Kumar SenSharma created WFLY-3714:
-----------------------------------------
Summary: Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
Key: WFLY-3714
URL: https://issues.jboss.org/browse/WFLY-3714
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 9.0.0.Beta1
Reporter: Jay Kumar SenSharma
Assignee: Stuart Douglas
- WildFly do not validate if the <servlet-mapping> tag has valid mappings or not. This should have been handled properly.
*Example:* If following kind of web.xml based application is deployed on WildFly9 then
{code}
<?xml version="1.0"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>servlets.MyServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<!--url-pattern></url-pattern--> <!-- NOTICE url-pattern-tag is missing here -->
</servlet-mapping>
</web-app>
{code}
- With the above kind of web.xml a NullPointerException is encountered during deployment.
{code}
15:50:20,207 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.NullPointerException
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleServletMappings(UndertowDeploymentInfoService.java:910)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:656)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
... 3 more
15:50:20,348 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (JGRP-1868) Size of XMIT_REQ is not limited
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1868?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1868:
--------------------------------
The stuck threads issue is possibly related to the put-while-holding-the-lock issue (see the ispn-dev mailing list)... I wonder if you could run your test with total-order enabled:
{code:xml}
<transaction transactionMode="TRANSACTIONAL" transactionProtocol="TOTAL_ORDER" lockingMode="OPTIMISTIC"
useEagerLocking="true" eagerLockSingleNode="true">
<recovery enabled="false"/>
</transaction>
{code}
I got a lot of lock acquisition failures with or without TXs, but with TO they went away. Not sure if this is related to your issue though...
> Size of XMIT_REQ is not limited
> -------------------------------
>
> Key: JGRP-1868
> URL: https://issues.jboss.org/browse/JGRP-1868
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4, 3.5
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> When UNICAST3 sends XMIT_REQ, it serializes SeqnoList as payload without any limits upon its size. If there are too many missing messages, the XMIT_REQ grows over TP.max_bundle_size and cannot be sent at all.
> {code}
> JGRP000029: edg-perf03-10774: failed sending message to edg-perf01-63702 (64072 bytes): java.lang.Exception: message size (64072) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: UNICAST3: XMIT_REQ, seqno=0, UDP: [channel_name=default]
> {code}
> It's also undesirable to resend thousands of messages, as the receiver likely cannot process them all at once and only few of them will be actually processed. Therefore only X oldest ones (in order to cleanup the tables) should be resent.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months