[JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
by Bela Ban (JIRA)
Bela Ban created JGRP-1807:
------------------------------
Summary: UNICAST: skipping of seqnos
Key: JGRP-1807
URL: https://issues.jboss.org/browse/JGRP-1807
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.2.13, 3.5
{noformat}
The log starts with:
10-Mar-2014 13:21:47 WARN [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511786 not found in retransmission table of AS_DR_IBE06/web:
[1511785 | 1511785 | 1511857] (53 elements, 19 missing)
The numbers are 1511786-1511804 for "not found in retransmission...."
And end:
10-Mar-2014 14:48:26 WARN [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511804 not found in retransmission table of AS_DR_IBE06/web:
[1511785 | 1511785 | 1514802] (2998 elements, 19 missing)
{noformat}
It seems that 03 is missing messages 1511785-1511804 which it sent to 06. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno:
In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example:
* We get the next seqno 1, add the message to the table and send it
* We get the next seqno 2. However, if {{running}} is false, we don't add the message
* We get the next seqno 3. Now {{running}} is true, and we add 3 to the table
--> Now we have a missing message 2 which will always be null as it hasn't been added to the table
This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false.
In this scenario, the connections are all removed, so seqno is reset to 1.
Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false.
[1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroup...
--
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, 1 month
[JBoss JIRA] (WFLY-3100) ClassCastException in JSPs where spring-web tags and jstl tags are used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3100:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075353
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
> Key: WFLY-3100
> URL: https://issues.jboss.org/browse/WFLY-3100
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE, Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: abhishek vijra
> Assignee: Remy Maucherat
> Labels: jsp, jstl
> Attachments: spring-fun.war
>
>
> Following JSP with spring tags
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
> <head><title>Simple jsp page</title></head>
> <body>
>
> <c:set var="hasError" value="${param.hasError}" />
> <c:set var="msg" value="${param.msg}" />
>
> <c:if test="${param.hasError=='true'}">
> Message: <spring:message text="${param.msg}"/>
> </c:if>
>
> </body>
> </html>
> breaks following error
> ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.
--
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, 1 month
[JBoss JIRA] (AS7-5645) Jboss 7.0.2, 7.1 does not call ServletContextListener.contextDestroyed(ServletContextEvent event) on shutdown.
by San chi (JIRA)
[ https://issues.jboss.org/browse/AS7-5645?page=com.atlassian.jira.plugin.s... ]
San chi edited comment on AS7-5645 at 3/11/14 11:12 PM:
--------------------------------------------------------
I am seeing the same exact issue of contextDestroyed not being called on Windows (64 bit) with JBoss 7.1.1 Final version. Is there a workaround for this issue?
Alexey,
How did you resolve it? Why do you say it is not a Jboss issue?
was (Author: chinivar):
Alex,
I am seeing the same exact issue of contextDestroyed not being called on Windows (64 bit) with JBoss 7.1.1 Final version. Is there a workaround for this issue?
Alexey,
How did you resolve it? Why do you say it is not a Jboss issue?
> Jboss 7.0.2, 7.1 does not call ServletContextListener.contextDestroyed(ServletContextEvent event) on shutdown.
> --------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5645
> URL: https://issues.jboss.org/browse/AS7-5645
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.0.2.Final, 7.1.0.Final, 7.1.1.Final
> Environment: Windows 7 64 bit
> Reporter: Alexey Alexey
> Assignee: Jason Greene
> Labels: ServletContext, Servlet_Context
>
> Jboss 7.0.2, 7.1 (standalone) does not call ServletContextListener .contextDestroyed(ServletContextEvent event) on shutdown. Shutdown was performed with Ctrl^C and also with command
> jboss-admin.bat --connect command=:shutdown
> I had the same result - jboss does not call destroying.
> This listener was successfully initialized on startup with ServletContextListener.contextInitialized(ServletContextEvent event).
> This listener is registered in web.xml in standart way:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app id="WebApp_ID" version="2.4"
> xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
> ....
> <listener>
> <listener-class>Full_classname_of_listener</listener-class>
> </listener>
> </web-app>
--
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, 1 month
[JBoss JIRA] (AS7-5645) Jboss 7.0.2, 7.1 does not call ServletContextListener.contextDestroyed(ServletContextEvent event) on shutdown.
by San chi (JIRA)
[ https://issues.jboss.org/browse/AS7-5645?page=com.atlassian.jira.plugin.s... ]
San chi edited comment on AS7-5645 at 3/11/14 11:12 PM:
--------------------------------------------------------
Alex,
I am seeing the same exact issue of contextDestroyed not being called on Windows (64 bit) with JBoss 7.1.1 Final version. Is there a workaround for this issue?
Alexey,
How did you resolve it? Why do you say it is not a Jboss issue?
was (Author: chinivar):
I am seeing the same exact issue of contextDestroyd not being called on Windows (64 bit) with JBoss 7.1.1 Final version. Is there a workaround for this issue?
> Jboss 7.0.2, 7.1 does not call ServletContextListener.contextDestroyed(ServletContextEvent event) on shutdown.
> --------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5645
> URL: https://issues.jboss.org/browse/AS7-5645
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.0.2.Final, 7.1.0.Final, 7.1.1.Final
> Environment: Windows 7 64 bit
> Reporter: Alexey Alexey
> Assignee: Jason Greene
> Labels: ServletContext, Servlet_Context
>
> Jboss 7.0.2, 7.1 (standalone) does not call ServletContextListener .contextDestroyed(ServletContextEvent event) on shutdown. Shutdown was performed with Ctrl^C and also with command
> jboss-admin.bat --connect command=:shutdown
> I had the same result - jboss does not call destroying.
> This listener was successfully initialized on startup with ServletContextListener.contextInitialized(ServletContextEvent event).
> This listener is registered in web.xml in standart way:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app id="WebApp_ID" version="2.4"
> xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
> ....
> <listener>
> <listener-class>Full_classname_of_listener</listener-class>
> </listener>
> </web-app>
--
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, 1 month
[JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is not found
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2004?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-2004.
-------------------------------
Fix Version/s: (was: 8.0.1.Final)
Resolution: Cannot Reproduce Bug
I can't seem to reproduce this. If it's still an issue, please reopen.
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
> Key: WFLY-2004
> URL: https://issues.jboss.org/browse/WFLY-2004
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Logging
> Reporter: Heiko Braun
> Assignee: James Perkins
> Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1] ("subsystem" => "logging"),
> [Server:stage1] ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}
--
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, 1 month
[JBoss JIRA] (WFLY-3102) EJB in WAR should inherit WAR's security domain
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3102?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3102:
--------------------------------------
The big problem would be that this change would break backwards compatibility, although I am not sure how much of an issue it would be in practice.
>From a technical point of view this is not a difficult change.
> EJB in WAR should inherit WAR's security domain
> -----------------------------------------------
>
> Key: WFLY-3102
> URL: https://issues.jboss.org/browse/WFLY-3102
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Bill Burke
> Assignee: Stuart Douglas
>
> If you define an EJB within WEB-INF/classes it does not inherit the security domain from the WAR file and defaults to "other". Counter-intuitive, IMO. Not sure if it is easily fixable though
--
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, 1 month