[JBoss JIRA] (WFLY-2703) Undertow Broken pipe with JSFs f:ajax and h:inputText
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2703?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2703.
----------------------------------
Resolution: Out of Date
I don't see any issues with the provided sample, except for the javascipt alert mentioned previously that appears to be caused by an issue with the app.
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
> Key: WFLY-2703
> URL: https://issues.jboss.org/browse/WFLY-2703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: Linux, JDK 7
> Reporter: Andre Pankraz
> Assignee: Stuart Douglas
> Attachments: test.war
>
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> value="#{contentList.content.searchTerms}">
> <f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> ... 9 more
--
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, 4 months
[JBoss JIRA] (WFLY-2261) standalone.sh --debug without port number not working
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-2261:
------------------------------
Fix Version/s: 8.0.1.Final
> standalone.sh --debug without port number not working
> ------------------------------------------------------
>
> Key: WFLY-2261
> URL: https://issues.jboss.org/browse/WFLY-2261
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Jeff Mesnil
> Fix For: 8.0.1.Final
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO [stdout] (main)
> 12:19:36,893 INFO [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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, 4 months
[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-2859:
---------------------------------------
Yes, this should not be a problem. We'll probably have to move the resteasy-cdi module over to WF to do that but I wanted to do the move before anyway.
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
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, 4 months
[JBoss JIRA] (WFLY-2261) standalone.sh --debug without port number not working
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-2261:
---------------------------------
Assignee: Jeff Mesnil (was: Brian Stansberry)
> standalone.sh --debug without port number not working
> ------------------------------------------------------
>
> Key: WFLY-2261
> URL: https://issues.jboss.org/browse/WFLY-2261
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Jeff Mesnil
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO [stdout] (main)
> 12:19:36,893 INFO [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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, 4 months
[JBoss JIRA] (JGRP-1796) Fix flush problem with integration of commons-logging output
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1796?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1796.
----------------------------
Resolution: Done
Applied your PR to master, too.
> Fix flush problem with integration of commons-logging output
> ------------------------------------------------------------
>
> Key: JGRP-1796
> URL: https://issues.jboss.org/browse/JGRP-1796
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13, 3.3.6, 3.5
>
>
> The commons-logging output which appears in test case output files does not have line termination processed correctly. We end up with text like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member120666 [DEBUG] GMS: - A: installing view [A|0] [A]120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> This makes reading the logging output hard to read.
> We want it to look like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member
> 120666 [DEBUG] GMS: - A: installing view [A|0] [A]
> 120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> Th solution is to implement flush() as a method which simply appends a null string with CR/LF applied as well to the current collected sysout and syserr.
--
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, 4 months
[JBoss JIRA] (JGRP-1798) loopback=false is not working in 3.3.5 version
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1798?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1798.
----------------------------
Resolution: Rejected
This is not what loopback is supposed to do [1]. Please check the manual before opening a ticket. You need to use JChannel.setDiscardOwnMessages().
[1] http://www.jgroups.org/manual/html/protlist.html#Transport
[2] http://www.jgroups.org/manual/html/user-channel.html#SendingMessages
> loopback=false is not working in 3.3.5 version
> ----------------------------------------------
>
> Key: JGRP-1798
> URL: https://issues.jboss.org/browse/JGRP-1798
> Project: JGroups
> Issue Type: Bug
> Environment: Fedora 17
> Reporter: Sreenivasa Reddy Boreddy
> Assignee: Bela Ban
> Labels: loopback
> Attachments: jgroupsmanager.xml
>
>
> Recently I upgraded by JGroups version from 2.12.1 to 3.3.5 and observed that JGroups messages are received to self node even though I configured loopback=false in my jgroupsmanager.xml.
> I am using TCP/IP as protocol stack.
> 24.02.2014 12.00.13:191 109357 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.13:593 109365 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REPLICATE_COUNTER_V2][elements: 2] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.14:327 109366 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.14:476 109370 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REPLICATE_COUNTER_V2][elements: 2] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.14:635 109379 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
--
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, 4 months
[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1797:
---------------------------
Fix Version/s: 3.5
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
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, 4 months
[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1795:
---------------------------
Fix Version/s: 3.5
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
> Key: JGRP-1795
> URL: https://issues.jboss.org/browse/JGRP-1795
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {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, 4 months
[JBoss JIRA] (JGRP-1798) loopback=false is not working in 3.3.5 version
by Sreenivasa Reddy Boreddy (JIRA)
[ https://issues.jboss.org/browse/JGRP-1798?page=com.atlassian.jira.plugin.... ]
Sreenivasa Reddy Boreddy updated JGRP-1798:
-------------------------------------------
Attachment: jgroupsmanager.xml
Jgroups configurations I used.
> loopback=false is not working in 3.3.5 version
> ----------------------------------------------
>
> Key: JGRP-1798
> URL: https://issues.jboss.org/browse/JGRP-1798
> Project: JGroups
> Issue Type: Bug
> Environment: Fedora 17
> Reporter: Sreenivasa Reddy Boreddy
> Assignee: Bela Ban
> Labels: loopback
> Attachments: jgroupsmanager.xml
>
>
> Recently I upgraded by JGroups version from 2.12.1 to 3.3.5 and observed that JGroups messages are received to self node even though I configured loopback=false in my jgroupsmanager.xml.
> I am using TCP/IP as protocol stack.
> 24.02.2014 12.00.13:191 109357 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.13:593 109365 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REPLICATE_COUNTER_V2][elements: 2] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.14:327 109366 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.14:476 109370 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REPLICATE_COUNTER_V2][elements: 2] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
> 24.02.2014 12.00.14:635 109379 DEBUG {Incoming-10,ag,10.10.64.188-smsrouter}JGROUPSMANAGER Received multicast message: [type: REQUEST_QUOTA][elements: 3] from 10.10.64.188-smsrouter, passing to 1 registered handlers.
--
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, 4 months