[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1220:
------------------------------------------
I think the immediate thing to do here is to have slave HCs terminate, but to have servers try and close the channel.
The HC is monitored by the ProcessController, so if it exits the PC will respawn it. An HC that can't handle management requests properly has no purpose, so might as well respawn it.
For a server it's questionable whether exiting is the better thing to do, but closing the channel at least helps signal to the outside world that there is a problem. For server->HC channels, leaving the channel open just disrupts other operations in the domain.
> Try closing the channel if java.lang.Error prevents sending error responses to the client
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1220
> URL: https://issues.jboss.org/browse/WFCORE-1220
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue.
> Options:
> 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process.
> If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process.
> 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg updated WFLY-6413:
---------------------------------
Steps to Reproduce:
Enable range header as described here:
https://developer.jboss.org/message/953058#953058
Deploy a simple application to WildFly that serves video content via HTML5, like this: https://github.com/slowtrailrunner/html5-vidtest
Load the page with the video (if using the above example then http://localhost:8880/vidtest/) in various browsers:
* Chrome - *will not* play video
* Safari - *will not* play video
* Firefox - *will* play video
Run this from the CLI, not the results:
{noformat}
$ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
{noformat}
Now deploy the same war to Tomcat 8 and do the above steps again. Notice that the video is playable in all the browsers. Also note the difference in the result from the `curl` test.
was:
Enable range header as described here:
https://developer.jboss.org/message/953058#953058
Deploy a simple application to WildFly that serves video content via HTML5, like this: https://github.com/slowtrailrunner/html5-vidtest
Load the page with the video (if using the above example then http://localhost:8880/vidtest/) in various browsers:
* Chrome - *will not* play video
* Safari - *will no*t play video
* Firefox - *will* play video
Run this from the CLI, not the results:
{noformat}
$ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
{noformat}
Now deploy the same war to Tomcat 8 and do the above steps again. Notice that the video is playable in all the browsers. Also note the difference in the result from the `curl` test.
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-470) HTTP Form Authentication
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-470:
------------------------------------
Summary: HTTP Form Authentication
Key: ELY-470
URL: https://issues.jboss.org/browse/ELY-470
Project: WildFly Elytron
Issue Type: Sub-task
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta5
The mechanism should be usable both in a Servlet container and non Serlvet container environment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6415) Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6415?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6415:
------------------------------------
Since the pool size is fixed, the term "max-threads" is confusing, since the number of threads is constant. I suggest we rename this to "threads" or "size".
> Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6415
> URL: https://issues.jboss.org/browse/WFLY-6415
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> {code}
> * <p>While this class inherits from {@link ThreadPoolExecutor}, a few
> * of the inherited tuning methods are not useful for it. In
> * particular, because it acts as a fixed-sized pool using
> * {@code corePoolSize} threads and an unbounded queue, adjustments
> * to {@code maximumPoolSize} have no useful effect. Additionally, it
> * is almost never a good idea to set {@code corePoolSize} to zero or
> * use {@code allowCoreThreadTimeOut} because this may leave the pool
> * without threads to handle tasks once they become eligible to run.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-469) A HTTP mechanism needs the ability to write the response.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-469:
------------------------------------
Summary: A HTTP mechanism needs the ability to write the response.
Key: ELY-469
URL: https://issues.jboss.org/browse/ELY-469
Project: WildFly Elytron
Issue Type: Feature Request
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta5
A mechanism either needs to be able to write the content of the response directly, or we need to be able to provide an OutputStream the mechanism can write to so we can cache it's output and subsequently use it.
I think direct access should be sufficient but would need to be first wins - by the time the mechanisms are sending their challenge we already know the response is being sent back to the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6415) Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6415:
------------------------------------
Summary: Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning
Key: WFLY-6415
URL: https://issues.jboss.org/browse/WFLY-6415
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
{code}
* <p>While this class inherits from {@link ThreadPoolExecutor}, a few
* of the inherited tuning methods are not useful for it. In
* particular, because it acts as a fixed-sized pool using
* {@code corePoolSize} threads and an unbounded queue, adjustments
* to {@code maximumPoolSize} have no useful effect. Additionally, it
* is almost never a good idea to set {@code corePoolSize} to zero or
* use {@code allowCoreThreadTimeOut} because this may leave the pool
* without threads to handle tasks once they become eligible to run.
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2033) Replace Java serialization with JGroups marshalling
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2033?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2033 at 3/21/16 1:20 PM:
---------------------------------------------------------
Replaced all occurrences of {{Message.getObject()}} and {{Util.objectFromXXX()}} in:
* NAKACK2
* UNICAST3
* FlowControl
* Locking
* ExtendedUUID
* SiteUUID
Skipped {{Executing}} as this will probably get removed in 4.0 anyway.
was (Author: belaban):
Replaced all occurrences of {{Message.getObject()}} in:
* NAKACK2
* UNICAST3
* FlowControl
* Locking
Skipped {{Executing}} as this will probably get removed in 4.0 anyway.
> Replace Java serialization with JGroups marshalling
> ---------------------------------------------------
>
> Key: JGRP-2033
> URL: https://issues.jboss.org/browse/JGRP-2033
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.9, 4.0
>
>
> In some cases, even JGroups internal code still uses Java serialization. Replace this with marshalling (using {{Streamable}}). Analysis of all occurrences of {{Util.objectFromXXX()}} calls.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6414) Infinispan subsystem XSD does not match InfinispanSubsystemXMLReader
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6414:
------------------------------------
Summary: Infinispan subsystem XSD does not match InfinispanSubsystemXMLReader
Key: WFLY-6414
URL: https://issues.jboss.org/browse/WFLY-6414
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
{{jboss-as-infinispan_4_0.xsd}} uses the same type {{thread-pool}} for all thread pool definitions.
However, {{InfinispanSubsystemXMLReader}} uses a special method {{parseScheduledThreadPool()}} for the {{EXPIRATION_THREAD_POOL}} which accepts fewer attributes than {{parseThreadPool()}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1101) Upgrade protobuf-java from 2.5.0 to 2.6.0
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1101?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1101:
------------------------------------------
The drools tests succeed, but there's a JBPM test that fails in drools-osgi in the integration repo. Hidden in a stacktraces that gets logged and eat, I found this:
{code}
2016-03-21 17:35:57,492 | ERROR | (3)-192.168.1.16 | TransactionSynchronizationUtils | 76 - org.apache.servicemix.bundles.spring-tx - 3.2.9.RELEASE_1 | TransactionSynchronization.beforeCompletion threw exception
java.lang.NoSuchMethodError: org.drools.core.marshalling.impl.ProtobufMessages$ProcessData$Builder.setExtension(Lcom/google/protobuf/GeneratedMessage$GeneratedExtension;Ljava/lang/Object;)Lcom/google/protobuf/GeneratedMessage$ExtendableBuilder;
at org.jbpm.marshalling.impl.ProtobufProcessMarshaller.writeProcessTimers(ProtobufProcessMarshaller.java:90)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:209)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:120)
at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:164)
at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148)
at org.drools.persistence.SessionMarshallingHelper.getSnapshot(SessionMarshallingHelper.java:78)
at org.drools.persistence.info.SessionInfo.transform(SessionInfo.java:96)
at org.drools.persistence.TriggerUpdateTransactionSynchronization.beforeCompletion(TriggerUpdateTransactionSynchronization.java:57)
at org.kie.spring.persistence.SpringTransactionSynchronizationAdapter.beforeCompletion(SpringTransactionSynchronizationAdapter.java:54)
at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerBeforeCompletion(TransactionSynchronizationUtils.java:106)
{code}
> Upgrade protobuf-java from 2.5.0 to 2.6.0
> -----------------------------------------
>
> Key: DROOLS-1101
> URL: https://issues.jboss.org/browse/DROOLS-1101
> Project: Drools
> Issue Type: Task
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Geoffrey De Smet
>
> From RPM discussion (BPMSPL-282)
> Productization: protobuf-java redhat version is: 2.6.0-redhat-1, is it ok to upgrade from 2.5.0->2.6.0?
> Motivation:
> - The 2.5 version isn't build from source by productization, there is no redhat version.
> - The 2.6 version is, which means they can do security patches on it easily (= important for long term support) and it can be RPM'ed (important for BPMSPL-282, which has PM support)
> - 2.6 is higher than 2.5, so in theory this is low-risk change.
> Needed on both master and 6.4.x.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month