July 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1541) UT005013 with RichFaces 5 and the tag <r:push> which uses WebSockets

by Juergen Zimmermann (JIRA)

[ https://issues.jboss.org/browse/WFLY-1541?page=com.atlassian.jira.plugin.... ] Juergen Zimmermann commented on WFLY-1541: ------------------------------------------ Thank you, Stuart. The stacktraces are gone in WF Alpha3. > UT005013 with RichFaces 5 and the tag <r:push> which uses WebSockets > -------------------------------------------------------------------- > > Key: WFLY-1541 > URL: https://issues.jboss.org/browse/WFLY-1541 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Stuart Douglas > > I'm using a WildFly 8.0.0.Alpha2 snapshot with Undertow 1.0.0.Alpha19. The snapshot is configured for Mojarra 2.1.23 instead of 2.2.0 because of the new RichFaces 5.0.0.Alpha1 which still cannot use Mojarra 2.2. During a websocket push via <r:push> I'm getting the stacktrace below. RichFaces itself is using Atmosphere 1.0.13 for WebSockets. > Log messages when Atmosphere is started: > {code} > 09:38:56,670 INFO [org.atmosphere.cpr.AtmosphereFramework] Auto detecting atmosphere handlers /WEB-INF/classes/ > 09:38:56,702 INFO [org.atmosphere.cpr.AtmosphereFramework] Auto detecting WebSocketHandler in /WEB-INF/classes/ > 09:38:56,702 INFO [org.atmosphere.cpr.AtmosphereFramework] Installed WebSocketProtocol org.atmosphere.websocket.protocol.SimpleHttpProtocol > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Atmosphere is using async support: org.atmosphere.container.BlockingIOCometSupport running under container: Undertow - 1.0.0.Alpha19 > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Installed AtmosphereInterceptor Track Message Size Interceptor using |. > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Installed Default AtmosphereInterceptor [Android Interceptor Support, SSE Interceptor Support, JSONP Interceptor Support, Atmosphere JavaScript Protocol, Browser disconnection detection, Track Message Size Interceptor using |]. Set org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults in your xml to disable them. > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using BroadcasterCache: org.atmosphere.cache.HeaderBroadcasterCache > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Shared ExecutorService supported: true > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] HttpSession supported: false > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using BroadcasterFactory: org.atmosphere.cpr.DefaultBroadcasterFactory > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using WebSocketProcessor: org.atmosphere.websocket.DefaultWebSocketProcessor > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using Broadcaster: org.atmosphere.cpr.DefaultBroadcaster > 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Atmosphere Framework 1.0.13 started. > {code} > Stacktrace: > {code} > 09:40:44,640 ERROR [io.undertow.request.io] UT005013: An IOException occurred: java.io.IOException: Eine bestehende Verbindung wurde softwaregesteuert > durch den Hostcomputer abgebrochen > at sun.nio.ch.SocketDispatcher.write0(Native Method) [rt.jar:1.7.0_21] > at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51) [rt.jar:1.7.0_21] > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0_21] > at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_21] > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:450) [rt.jar:1.7.0_21] > at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:148) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3] > at io.undertow.server.HttpResponseConduit.write(HttpResponseConduit.java:476) > at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:184) > at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3] > at io.undertow.server.HttpServerExchange$WriteDispatchChannel.flush(HttpServerExchange.java:1500) > at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1298) > at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1287) > at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:47) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] > {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, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-194) Add support in KIE to register custom Wagons

by Kurt Stam (JIRA)

Kurt Stam created DROOLS-194: -------------------------------- Summary: Add support in KIE to register custom Wagons Key: DROOLS-194 URL: https://issues.jboss.org/browse/DROOLS-194 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kurt Stam Assignee: Mark Proctor The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code: {quote} private static class ManualWagonProvider implements WagonProvider { public Wagon lookup( String roleHint ) throws Exception { if ( "http".equals( roleHint ) ) { return new AhcWagon(); } if ( "sramp".equals( roleHint ) ) { return new SrampWagon(); } return null; } public void release( Wagon wagon ) { } } {quote} -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6072) Automate creating EAP 6.x public API Javadoc

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-6072?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka updated AS7-6072: ------------------------------ Description: Docspace page: https://docspace.corp.redhat.com/docs/DOC-134981 First attempt: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/EAP6-javadoc/ What's needed: * Blacklist of skipped .jar's (cause exceptions when generating) * XSLT to put <include>'s to pom.xml * XSLT to put <groups> to pom.xml See also https://docspace.corp.redhat.com/docs/DOC-105009 (bottom) was: First attempt: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/EAP6-javadoc/ What's needed: * Blacklist of skipped .jar's (cause exceptions when generating) * XSLT to put <include>'s to pom.xml * XSLT to put <groups> to pom.xml See also https://docspace.corp.redhat.com/docs/DOC-105009 (bottom) > Automate creating EAP 6.x public API Javadoc > -------------------------------------------- > > Key: AS7-6072 > URL: https://issues.jboss.org/browse/AS7-6072 > Project: Application Server 7 > Issue Type: Enhancement > Components: Build System, Documentation > Affects Versions: 7.1.3.Final (EAP) > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > Docspace page: https://docspace.corp.redhat.com/docs/DOC-134981 > First attempt: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/EAP6-javadoc/ > What's needed: > * Blacklist of skipped .jar's (cause exceptions when generating) > * XSLT to put <include>'s to pom.xml > * XSLT to put <groups> to pom.xml > See also https://docspace.corp.redhat.com/docs/DOC-105009 (bottom) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-328) Reintroduce the feature to allow EJB invocations over HTTP

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-328?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on WFLY-328: ----------------------------------- You'll have to check with the support team via the support portal to see what the roadmap is for introducing this in EAP 6 series. It however won't be in EAP 6.1 since it's already been released long back. > Reintroduce the feature to allow EJB invocations over HTTP > ---------------------------------------------------------- > > Key: WFLY-328 > URL: https://issues.jboss.org/browse/WFLY-328 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: jaikiran pai > Assignee: Eduardo Martins > Fix For: 8.0.0.Alpha3 > > > There have been requests from users to resurrect the feature from previous JBoss AS versions to allow EJB invocation over HTTP. Most recent discussion about this is here http://lists.jboss.org/pipermail/jboss-as7-dev/2012-April/005808.html -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-233) Move javadoc configuration into a separate module pom

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-233?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka updated WFLY-233: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/4807 > Move javadoc configuration into a separate module pom > ----------------------------------------------------- > > Key: WFLY-233 > URL: https://issues.jboss.org/browse/WFLY-233 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: Paul Gier > Assignee: Ondrej Zizka > Fix For: 8.0.0.Beta1 > > > There is a lot of javadoc configuration information in build/pom.xml. Since this pom is already pretty large even without the javadoc config, it might be good to move the javadoc generation to a separate module and pom. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-233) Move javadoc configuration into a separate module pom

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-233?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka resolved WFLY-233. ------------------------------- Resolution: Done PR #4807 I've removed as per previous comment. > Move javadoc configuration into a separate module pom > ----------------------------------------------------- > > Key: WFLY-233 > URL: https://issues.jboss.org/browse/WFLY-233 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: Paul Gier > Assignee: Ondrej Zizka > Fix For: 8.0.0.Beta1 > > > There is a lot of javadoc configuration information in build/pom.xml. Since this pom is already pretty large even without the javadoc config, it might be good to move the javadoc generation to a separate module and pom. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-328) Reintroduce the feature to allow EJB invocations over HTTP

by Jay Kris (JIRA)

[ https://issues.jboss.org/browse/WFLY-328?page=com.atlassian.jira.plugin.s... ] Jay Kris commented on WFLY-328: ------------------------------- Jaykiran,Excellent news. What is the likelyhood of bakporting this to EAP 6.1 ? many thanks in advance. > Reintroduce the feature to allow EJB invocations over HTTP > ---------------------------------------------------------- > > Key: WFLY-328 > URL: https://issues.jboss.org/browse/WFLY-328 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: jaikiran pai > Assignee: Eduardo Martins > Fix For: 8.0.0.Alpha3 > > > There have been requests from users to resurrect the feature from previous JBoss AS versions to allow EJB invocation over HTTP. Most recent discussion about this is here http://lists.jboss.org/pipermail/jboss-as7-dev/2012-April/005808.html -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1662) Remove flow control and fragmentation if run on TCP transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1662?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1662: -------------------------------- One reason the TCP-based config performs worse lies in the design of the transport: a received message is passed to a thread pool, which might discard it if full, but the TCP receive() never blocks. Therefore, TCP's flow control continues sending full steam ahead and never throttles the sender, leading to overflow at the receiver. Adding MFC back re-establishes flow control and thus throttles the sender. > Remove flow control and fragmentation if run on TCP transport > ------------------------------------------------------------- > > Key: JGRP-1662 > URL: https://issues.jboss.org/browse/JGRP-1662 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3.4, 3.4 > > > When run with a TCP transport, we don't need MFC and FRAG(2). However, if we remove FRAG2, the bundler at the transport will drop a message if it exceeds max_bundle_size. > Let's therefore bypass message bundling when the transport is TCP (TCP has its own batching). > TODO: measure how this change affects performance on a 4 node cluster. If positive, commit it. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-233) Move javadoc configuration into a separate module pom

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-233?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka commented on WFLY-233: ----------------------------------- I could remove most of javadoc related data since it's replaced by a script in the process anyway. Would that work? IMO it's less risky than creating a separated module, and would solve the problem of having a large pom. > Move javadoc configuration into a separate module pom > ----------------------------------------------------- > > Key: WFLY-233 > URL: https://issues.jboss.org/browse/WFLY-233 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: Paul Gier > Assignee: Ondrej Zizka > Fix For: 8.0.0.Beta1 > > > There is a lot of javadoc configuration information in build/pom.xml. Since this pom is already pretty large even without the javadoc config, it might be good to move the javadoc generation to a separate module and pom. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1662) Remove flow control and fragmentation if run on TCP transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1662?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1662: -------------------------------- Changed thread pool config: a high queue size led to a high number of 70k messages getting queued, which was the reason for the OOMEs. Adjusted min_size to 4 and set the queue size to 1000. However, numbers went up to 79MB/sec/node, compared to 87MB/sec/node for the old config (+MFC +FRAG2). > Remove flow control and fragmentation if run on TCP transport > ------------------------------------------------------------- > > Key: JGRP-1662 > URL: https://issues.jboss.org/browse/JGRP-1662 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3.4, 3.4 > > > When run with a TCP transport, we don't need MFC and FRAG(2). However, if we remove FRAG2, the bundler at the transport will drop a message if it exceeds max_bundle_size. > Let's therefore bypass message bundling when the transport is TCP (TCP has its own batching). > TODO: measure how this change affects performance on a 4 node cluster. If positive, commit it. -- 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, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2013