[JBoss JIRA] (JGRP-1792) "No buffer space available" when sending on Mac OS
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1792?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1792.
----------------------------
Resolution: Done
Doesn't occur anymore with JGRP-1765 in place, probably because we now use the DatagramSocket to send multicasts, not the MulticastSocket.
> "No buffer space available" when sending on Mac OS
> --------------------------------------------------
>
> Key: JGRP-1792
> URL: https://issues.jboss.org/browse/JGRP-1792
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> When sending multicast messages (with MPerf & fast.xml), the following message appears:
> {noformat}
> 8981 [ERROR] UDP: JGRP000029: A: failed sending message to cluster (1053 bytes): java.io.IOException: No buffer space available,
> headers: MPerf: DATA999, NAKACK2: [MSG, seqno=1003], UDP: [cluster_name=mperf]
> {noformat}
> The messages *are* received, but the error message occurs on almost every message (1 sender thread sending 1000 messages).
> With {{UdpPerf}} (also shipped with JGroups), which also multicasts messages, the error doesn't happen.
> With {{UPerf}}, which uses unicasts, the error doesn't occur either.
> Todo: compare UdpPerf to MPerf (UDP protocol) to see what the diff is.
--
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
10 years, 10 months
[JBoss JIRA] (JASSIST-219) Generic signature is lost after using ProxyFactory to enchant another class.
by Elis Edlund (JIRA)
[ https://issues.jboss.org/browse/JASSIST-219?page=com.atlassian.jira.plugi... ]
Elis Edlund updated JASSIST-219:
--------------------------------
Attachment: IssueMissingGenericTypeInfoForEnchantedClassTest.java
really simple class to reproduce the problem.
> Generic signature is lost after using ProxyFactory to enchant another class.
> ----------------------------------------------------------------------------
>
> Key: JASSIST-219
> URL: https://issues.jboss.org/browse/JASSIST-219
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA, 3.17.1-GA, 3.18.0-GA, 3.18.1-GA
> Environment: Windows 7
> java 1.5 1.6 1.7
> Reporter: Elis Edlund
> Assignee: Shigeru Chiba
> Labels: generics, missing
> Attachments: IssueMissingGenericTypeInfoForEnchantedClassTest.java
>
>
> Its not possible to get any generic information out of a class that have been 'enchanted' with ProxyFactory.
> example output before and after an 'enchantment' (produced with method.toGenericString())
> ------Enchant Object------
> stringMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getStringList()
> numberMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getNumberList()
> stringMethod sigature myObject : public java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getStringList()
> numberMethod sigature myObject : public java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getNumberList()
> ------Enchant Interface------
> stringMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getStringList()
> numberMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getNumberList()
> stringMethod sigature myInterface : public abstract java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getStringList()
> numberMethod sigature myInterface : public abstract java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getNumberList()
--
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
10 years, 10 months
[JBoss JIRA] (JASSIST-219) Generic signature is lost after using ProxyFactory to enchant another class.
by Elis Edlund (JIRA)
Elis Edlund created JASSIST-219:
-----------------------------------
Summary: Generic signature is lost after using ProxyFactory to enchant another class.
Key: JASSIST-219
URL: https://issues.jboss.org/browse/JASSIST-219
Project: Javassist
Issue Type: Bug
Affects Versions: 3.18.1-GA, 3.18.0-GA, 3.17.1-GA, 3.16.1-GA
Environment: Windows 7
java 1.5 1.6 1.7
Reporter: Elis Edlund
Assignee: Shigeru Chiba
Its not possible to get any generic information out of a class that have been 'enchanted' with ProxyFactory.
example output before and after an 'enchantment' (produced with method.toGenericString())
------Enchant Object------
stringMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getStringList()
numberMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getNumberList()
stringMethod sigature myObject : public java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getStringList()
numberMethod sigature myObject : public java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getNumberList()
------Enchant Interface------
stringMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getStringList()
numberMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getNumberList()
stringMethod sigature myInterface : public abstract java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getStringList()
numberMethod sigature myInterface : public abstract java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getNumberList()
--
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
10 years, 10 months
[JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1807:
--------------------------------
Same change for NAKACK2
> 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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months