[JBoss JIRA] (WFLY-2703) Undertow Broken pipe with JSFs f:ajax and h:inputText
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2703?page=com.atlassian.jira.plugin.... ]
Andre Pankraz commented on WFLY-2703:
-------------------------------------
sry didn't see this feature, thanks.
have applied file.
i see this broken pipe now also at other places, i think we had this problem with tomcat too some years ago and then the broken pipe exceptions have been removed at some time, didn't work.
for instance I get also this for conversations, if a page needs to long, especially with Ajax.
12:03:02,410 WARN [org.jboss.weld.Conversation] (default task-14) WELD-000315: Failed to acquire conversation lock in 1,000 ms for Conversation with id: 2
12:03:02,643 ERROR [io.undertow.request] (default task-13) Blocking request failed HttpServerExchange{ POST /xrepository/Inhaltverwaltung/Suche/XoevVorhaben.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)
No javax.enterprise.context.BusyConversationException is triggered in the global JSF exception handler - another different bug :/
> 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, 6 months
[JBoss JIRA] (WFLY-2703) Undertow Broken pipe with JSFs f:ajax and h:inputText
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2703?page=com.atlassian.jira.plugin.... ]
Andre Pankraz updated WFLY-2703:
--------------------------------
Attachment: test.war
deploy this war.
call http://localhost:8080/test/test.xhtml
enter some text and press return -> javascript alert appears shortly, broken pipe exception
enter some text and press tab for focus lost - works without problems.
here you can also see the difference with using umlauts...ajax OK, return not. (i know, applay the filter trick with CDI Filter as last)
> 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, 6 months
[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up
by Rajeev kumar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ]
Rajeev kumar commented on WFLY-1547:
------------------------------------
Hi,
As this issue is working fine in WildFly CR8.0.0 CR1. Can we get fix for Jboss AS 7.1.3 version fix.
Thanks
> deploy directories not cleaned up
> ---------------------------------
>
> Key: WFLY-1547
> URL: https://issues.jboss.org/browse/WFLY-1547
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Shaun Appleton
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
> Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
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, 6 months
[JBoss JIRA] (SECURITY-722) SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-722?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-722:
--------------------------------------
Fix Version/s: Negotiation_2_2_7
> SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available
> -------------------------------------------------------------------------------------------------
>
> Key: SECURITY-722
> URL: https://issues.jboss.org/browse/SECURITY-722
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_1
> Environment: RHEL6, JBoss EAP 6
> Reporter: flame liu
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_2_7
>
>
> I configured SPNEGO in EAP6. It works well both with EAP only and EAP6 + Apache httpd(mod_proxy). Users just run kinit and will be able to be successfully authenticated.
> After that, I added the fallback-to-form files/configurations both in the web app and standalone-full.xml. The fallback-to-form works only if httpd stops. If httpd starts, 401 error will always be thrown out.
--
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, 6 months
[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1732:
--------------------------------
Picked solution 2
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1732
> URL: https://issues.jboss.org/browse/JGRP-1732
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns
--
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, 6 months
[JBoss JIRA] (DROOLS-320) Drools plugin Rete Tree viewer does not work with timer and || operator.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-320?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-320:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1027120|https://bugzilla.redhat.com/show_bug.cgi?id=1027120] from ASSIGNED to MODIFIED
> Drools plugin Rete Tree viewer does not work with timer and || operator.
> ------------------------------------------------------------------------
>
> Key: DROOLS-320
> URL: https://issues.jboss.org/browse/DROOLS-320
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45, Drools-jBPM Eclipse plugin 6.0.0.CR5
> Reporter: Duncan Doyle
> Assignee: Mark Proctor
> Labels: drools, eclipse, plugin, rete, tree, view
>
> See this example project: https://github.com/DuncanDoyle/DroolsReteViewer , which is based on the Drools Eclipse sample project.
> The 'src/main/resources/rules/Sample.drl' is a valid DRL file, but it cannot be opened in the Rete Tree because of:
> - the 'timer (int: 10s)' definition in rule "GoodBye-Timer". This gives the error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException: [Rete(0)]
> - the '||' operator in the rule "Hello World-Or". This gives the error:
> Rete Tree Build Error!
> Reason:
> java.lang.NullPointerException: null
> This forces us to change our rule definition files to be able to inspect the Rete Tree (which we require to analyse the tree for possible optimizations).
--
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, 6 months