[JBoss JIRA] (WFWIP-57) MalformedInputException is thrown in case config-source dir contains binaries
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-57?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda commented on WFWIP-57:
----------------------------------------
File size should be also checked, I can imagine 100kB would be more than enough size limit.
In my experiment text file 100kB == 1300 lines.
> MalformedInputException is thrown in case config-source dir contains binaries
> -----------------------------------------------------------------------------
>
> Key: WFWIP-57
> URL: https://issues.jboss.org/browse/WFWIP-57
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Config
> Environment: {noformat}
> git@github.com:jmesnil/wildfly.git:WFLY-10522_microprofile-config-smallrye_extension
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
>
> Management operation for adding a config-source dir fails with MalformedInputException in case that the dir contains some binaries.
> *reproduce*
> {noformat}
> TEST_DIR=/tmp/test_dir
> mkdir -p $TEST_DIR
> head -c 1K </dev/urandom > ${TEST_DIR}/random.data
> echo 'value' > ${TEST_DIR}/my.property
> sh wildfly-14.0.0.Beta1-SNAPSHOT/bin/standalone.sh &
> sh wildfly-14.0.0.Beta1-SNAPSHOT/bin/jboss-cli.sh -c "/subsystem=microprofile-config-smallrye/config-source=config:add(dir=${TEST_DIR})"
> {noformat}
> *expected*
> Binaries and e.g. corrupted files (log?) are ignored.
> *actual*
> {noformat}
> 12:53:59,083 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "microprofile-config-smallrye"),
> ("config-source" => "asd")
> ]): java.io.UncheckedIOException: java.nio.charset.MalformedInputException: Input length = 1
> at java.io.BufferedReader$1.hasNext(BufferedReader.java:574)
> at java.util.Iterator.forEachRemaining(Iterator.java:115)
> at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at io.smallrye.config.DirConfigSource.readContent(DirConfigSource.java:72)
> at io.smallrye.config.DirConfigSource.scan(DirConfigSource.java:60)
> at io.smallrye.config.DirConfigSource.<init>(DirConfigSource.java:46)
> at org.wildfly.extension.microprofile.config.smallrye.ConfigSourceDefinition$1.performRuntime(ConfigSourceDefinition.java:120)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-65:
-------------------------------------
[~mtoth] Could you clone this one to ENTMQBR jira, please?
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak updated WFWIP-65:
--------------------------------
Description:
There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
Test scenario:
* There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
* InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
* When all messages are sent, deploy message driven bean on Node 3.
* MDB sends messages form InQueue to OutQueue.
* Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
* Receive messages from OutQueue from live server.
Results:
After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
Attaching reproduce and logs.
was:
There is regression in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
Test scenario:
* There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
* InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
* When all messages are sent, deploy message driven bean on Node 3.
* MDB sends messages form InQueue to OutQueue.
* Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
* Receive messages from OutQueue from live server.
Results:
After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
Attaching reproduce and logs.
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-65:
-------------------------------------
cc-ing Jeff
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months
[JBoss JIRA] (WFLY-10715) TransactionSubsystemTestCase does not test for invalid XML in some cases
by Tom Jenkinson (JIRA)
Tom Jenkinson created WFLY-10715:
------------------------------------
Summary: TransactionSubsystemTestCase does not test for invalid XML in some cases
Key: WFLY-10715
URL: https://issues.jboss.org/browse/WFLY-10715
Project: WildFly
Issue Type: Bug
Components: Test Suite, Transactions
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
7.0.0+ introduces the following attributes not found in 6.4.0: [use-journal-store, statistics-enabled, journal-store-enable-async-io]. The test xml should be updated to include these and transformers added where missing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months
[JBoss JIRA] (WFWIP-64) IllegalStateException: No ConfigProviderResolver implementation found
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-64?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda commented on WFWIP-64:
----------------------------------------
Moving to Critical for now, in product it would be Blocker.
We need ERROR free bott and shutdown.
> IllegalStateException: No ConfigProviderResolver implementation found
> ---------------------------------------------------------------------
>
> Key: WFWIP-64
> URL: https://issues.jboss.org/browse/WFWIP-64
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Config
> Environment: git@github.com:jmesnil/wildfly.git:WFLY-10522_microprofile-config-smallrye_extension
> Reporter: Jan Stourac
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: MicroProfileConfigTestCase.war
>
>
> There is following IllegalStateException printed during the server shutdown when an application which utilizes microprofile-config-smallrye subsystem is deployed:
> {code}
> 16:06:45,862 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@2e89bd6f unexpectedly threw an exception during undeploy phase POST_MODULE of deployment "MicroProfileConfigTestCase.war": java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:122)
> at org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:109)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:204)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1792)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1761)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Looks like there is missing implementation for {{ConfigProviderResolver}} abstract class?
> The application [^MicroProfileConfigTestCase.war] is quite simple and almost same as one used in [this test|https://github.com/jmesnil/wildfly/blob/55a2c220206abc9ca3b6550df988...].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months
[JBoss JIRA] (WFWIP-64) IllegalStateException: No ConfigProviderResolver implementation found
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-64?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda edited comment on WFWIP-64 at 7/19/18 5:23 AM:
-----------------------------------------------------------------
Moving to Critical for now, in product it would be Blocker.
We need ERROR-FREE boot and shutdown.
was (Author: rsvoboda):
Moving to Critical for now, in product it would be Blocker.
We need ERROR free bott and shutdown.
> IllegalStateException: No ConfigProviderResolver implementation found
> ---------------------------------------------------------------------
>
> Key: WFWIP-64
> URL: https://issues.jboss.org/browse/WFWIP-64
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Config
> Environment: git@github.com:jmesnil/wildfly.git:WFLY-10522_microprofile-config-smallrye_extension
> Reporter: Jan Stourac
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: MicroProfileConfigTestCase.war
>
>
> There is following IllegalStateException printed during the server shutdown when an application which utilizes microprofile-config-smallrye subsystem is deployed:
> {code}
> 16:06:45,862 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@2e89bd6f unexpectedly threw an exception during undeploy phase POST_MODULE of deployment "MicroProfileConfigTestCase.war": java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:122)
> at org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:109)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:204)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1792)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1761)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Looks like there is missing implementation for {{ConfigProviderResolver}} abstract class?
> The application [^MicroProfileConfigTestCase.war] is quite simple and almost same as one used in [this test|https://github.com/jmesnil/wildfly/blob/55a2c220206abc9ca3b6550df988...].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months
[JBoss JIRA] (WFWIP-64) IllegalStateException: No ConfigProviderResolver implementation found
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-64?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda updated WFWIP-64:
-----------------------------------
Priority: Critical (was: Major)
> IllegalStateException: No ConfigProviderResolver implementation found
> ---------------------------------------------------------------------
>
> Key: WFWIP-64
> URL: https://issues.jboss.org/browse/WFWIP-64
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Config
> Environment: git@github.com:jmesnil/wildfly.git:WFLY-10522_microprofile-config-smallrye_extension
> Reporter: Jan Stourac
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: MicroProfileConfigTestCase.war
>
>
> There is following IllegalStateException printed during the server shutdown when an application which utilizes microprofile-config-smallrye subsystem is deployed:
> {code}
> 16:06:45,862 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@2e89bd6f unexpectedly threw an exception during undeploy phase POST_MODULE of deployment "MicroProfileConfigTestCase.war": java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:122)
> at org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:109)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:204)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1792)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1761)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Looks like there is missing implementation for {{ConfigProviderResolver}} abstract class?
> The application [^MicroProfileConfigTestCase.war] is quite simple and almost same as one used in [this test|https://github.com/jmesnil/wildfly/blob/55a2c220206abc9ca3b6550df988...].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 12 months