[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from ON_QA to VERIFIED
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3108
> URL: https://issues.jboss.org/browse/WFLY-3108
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> ... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.
--
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, 9 months
[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-3144:
---------------------------------
Component/s: Clustering
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
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, 9 months
[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on WFLY-315:
---------------------------------------
The IO I'm talking about is writes. The reads are all done by remoting threads, so that's fine. But in many places the thread executing an op itself writes, e.g. to proxy a request, to send a prepared, failed or completed response, or to send a commit/rollback instruction. The problem with this is if an administrative action to cancel the op occurs, the thread is interrupted, and when that thread later interacts with the channel to write, the channel gets closed. Testing administratively cancelling ops from various processes I was regularly seeing the connection from a slave to the master or a server to its HC getting closed.
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-315
> URL: https://issues.jboss.org/browse/WFLY-315
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Emanuel Muckenhuber
> Priority: Blocker
> Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock
--
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, 9 months
[JBoss JIRA] (WFLY-937) ServletContext.getResource() doesn't work correctly for files containing hash characters
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-937?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved WFLY-937.
---------------------------------
Fix Version/s: 8.0.1.Final
Resolution: Done
> ServletContext.getResource() doesn't work correctly for files containing hash characters
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-937
> URL: https://issues.jboss.org/browse/WFLY-937
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.CR1
> Environment: Linux 3.2.0-30-generic Ubuntu SMP x86_64 GNU/Linux
> Reporter: Christian Kaltepoth
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
> Attachments: as7-url-bug.zip
>
>
> {{ServletContext.getResource()}} returns an invalid URL if the file name contains {{#}} characters.
> Example:
> {code:java}
> URL url = servletContext.getResource("/file#1.txt");
> {code}
> The resulting URL object will be spitted at the {{#}} character like this:
> {code}
> url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
> url.getPath(): /default-host/tomcat-url-bug/file
> url.getRef(): 1.txt
> {code}
> Calling {{url.openStream()}} will throw a {{FileNotFoundException}}.
> This is a known Tomcat issue fixed in 7.0.28.
> References:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53257
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51584
> According to the discussion on the Tomcat issue tracker, there are also problems for other characters which have special meaning in URLs.
--
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, 9 months
[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3087.
----------------------------------
Fix Version/s: 8.0.1.Final
Resolution: Done
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3087
> URL: https://issues.jboss.org/browse/WFLY-3087
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows server 2008
> Reporter: Admin FlirtyMob
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
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, 9 months
[JBoss JIRA] (WFLY-3113) Websocket connection fails when connecting to protected URL (basic login)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3113.
----------------------------------
Resolution: Rejected
As far as I can tell Undertow is behaving as it should.
> Websocket connection fails when connecting to protected URL (basic login)
> -------------------------------------------------------------------------
>
> Key: WFLY-3113
> URL: https://issues.jboss.org/browse/WFLY-3113
> Project: WildFly
> Issue Type: Clarification
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
> Chrome, Firefox
> Reporter: Alexandre Nikolov
> Assignee: Stuart Douglas
> Labels: jsr356,, login
>
> In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.
> When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
> 1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
> 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.
> But in a different application, using Atmosphere - both connections fails:
> 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
> 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
> For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info)
> Here is the related discussion on the Atmosphere users group:
> https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc
> There is test WAR and source in the Atmosphere forum to reproduce the problem.
--
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, 9 months
[JBoss JIRA] (WFLY-3093) Undertow doesn't show the correct error page (401)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3093?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3093.
----------------------------------
Fix Version/s: 8.0.1.Final
Resolution: Done
> Undertow doesn't show the correct error page (401)
> --------------------------------------------------
>
> Key: WFLY-3093
> URL: https://issues.jboss.org/browse/WFLY-3093
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> I'm using the WildFly snapshot from last Thursday with Undertow 1.0.1.
> When I try to invoke a protected web page, I'm getting an almost blank web page with just the contents "401 - Unauthorized".
> However, in WEB-INF/web.xml I'm having this declaration:
> {code}
> <error-page>
> <error-code>401</error-code>
> <location>/rf/error/accessDenied.jsf</location>
> </error-page>
> {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
10 years, 9 months
[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3146.
-------------------------------
Assignee: Stuart Douglas (was: Tomaz Cerar)
Resolution: Done
Both component upgrades ware merged.
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
> Key: WFLY-3146
> URL: https://issues.jboss.org/browse/WFLY-3146
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
> Reporter: Darren Jones
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: MemoryLeak
> Fix For: 8.0.1.Final
>
> Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl.
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.
--
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, 9 months
[JBoss JIRA] (WFLY-3153) Testing legacy subsystem transformers between different versions of Wildlfy
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-3153:
---------------------------------------
Summary: Testing legacy subsystem transformers between different versions of Wildlfy
Key: WFLY-3153
URL: https://issues.jboss.org/browse/WFLY-3153
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Final
Reporter: Emmanuel Hugonnet
Assignee: Brian Stansberry
The legacy web subsystem is still evolving. Thus we need to make the legacy web subsystem in WildFly evolve and test the transformers.
But testing the transformation between WildFly 8.0.0.Final and the next version of WildFly fails with the following exception :
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.as.subsystem.bridge.local.ScopedKernelServicesBootstrap.createChildClassLoaderKernelServices(ScopedKernelServicesBootstrap.java:85)
at org.jboss.as.subsystem.bridge.local.ScopedKernelServicesBootstrap.createKernelServices(ScopedKernelServicesBootstrap.java:53)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:771)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:644)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:616)
at org.jboss.as.web.test.WebSubsystemTestCase.testTransformation_2_0(WebSubsystemTestCase.java:443)
at org.jboss.as.web.test.WebSubsystemTestCase.testTransformationWildFly8(WebSubsystemTestCase.java:427)
Caused by: java.lang.IllegalArgumentException: JBAS014880: No operation entry called 'add' registered at '[("subsystem" => "web")]'
at org.jboss.as.controller.operations.validation.OperationValidator.throwOrWarnAboutDescriptorProblem(OperationValidator.java:549)
at org.jboss.as.controller.operations.validation.OperationValidator.validateOperation(OperationValidator.java:123)
at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:199)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:289)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
at java.lang.Thread.run(Thread.java:744)
--
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, 9 months