[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on WFWIP-65:
--------------------------------------
If u know how to fix it. Go ahead. If you need more than a day I will pick it up.
> [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: Clebert Suconic
> Priority: Blocker
> Labels: feature-branch-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, 11 months
[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/WFLY-10728?page=com.atlassian.jira.plugin... ]
Ron Sigal commented on WFLY-10728:
----------------------------------
[~gwsch], I'm not getting as far as [~mkopecky].
Where are
* ch.performancebuildings.cms.wordpress.model.*?
* Order, OrderBy?
* RenderObject, Link?
Thanks.
-Ron
> RESTEASY008200: JSON Binding deserialization error for valid JSON
> -----------------------------------------------------------------
>
> Key: WFLY-10728
> URL: https://issues.jboss.org/browse/WFLY-10728
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Environment: JDK-10.0.1
> Reporter: Guido Schmidt
> Assignee: Ron Sigal
> Attachments: User.java, UserQueryForm.java, UsersApi.java, single-application.zip
>
>
> I found the following regression issue running the code inside an ejb jar:
> In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String:
> {code:JavaScript}
> {{[{
> "id": 15,
> "username": "wpx1",
> "name": "Word Press1",
> "first_name": "Word",
> "last_name": "Press1",
> "email": "wpx1(a)pb.com",
> "url": "",
> "description": "",
> "link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1",
> "locale": "en_US",
> "nickname": "wpx1",
> "slug": "wpx1",
> "roles": ["contributor"],
> "registered_date": "2018-07-23T08:59:13+00:00",
> "capabilities": {
> "edit_posts": true,
> "read": true,
> "level_1": true,
> "level_0": true,
> "delete_posts": true,
> "manage_bookings": true,
> "upload_event_images": true,
> "delete_events": true,
> "edit_events": true,
> "read_private_events": true,
> "delete_recurring_events": true,
> "edit_recurring_events": true,
> "edit_locations": true,
> "read_private_locations": true,
> "read_others_locations": true,
> "contributor": true
> },
> "extra_capabilities": {
> "contributor": true
> },
> "avatar_urls": {
> "24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g",
> "48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g",
> "96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g"
> },
> "meta": [],
> "_links": {
> "self": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15"
> }
> ],
> "collection": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users"
> }
> ]
> }
> }
> ]}}
> {code}
> This is achieved by a call of the UsersApi method listUsersAsString:
>
> ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri);
> target.proxy(UsersApi.class);
> The call rendering the result into a List<User> fails with error message in the subject.
> The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4036) can't undefine task-max-threads
by 金沢 栄治 (JIRA)
金沢 栄治 created WFCORE-4036:
-----------------------------
Summary: can't undefine task-max-threads
Key: WFCORE-4036
URL: https://issues.jboss.org/browse/WFCORE-4036
Project: WildFly Core
Issue Type: Bug
Components: IO
Reporter: 金沢 栄治
when undefining task-max-threads attribute, it will cause exception as follow.
`
[standalone@localhost:9990 /] /subsystem=io/worker=default:undefine-attribute(name=task-max-threads)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
"rolled-back" => true
}
`
although this fix can clear the model value, but the value in xnio is remainded,
can check it by read-attribute operation,
but reload is needed to modidy task-max-threads,
so IMHO it's not a issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4035) operation-requires-reload message is missing
by 金沢 栄治 (JIRA)
金沢 栄治 created WFCORE-4035:
-----------------------------
Summary: operation-requires-reload message is missing
Key: WFCORE-4035
URL: https://issues.jboss.org/browse/WFCORE-4035
Project: WildFly Core
Issue Type: Bug
Components: IO
Reporter: 金沢 栄治
Priority: Minor
when modify values of task-max-threads and task-keepalive,
operation-requires-reload message is not outputed.
these two attributes is processed in XnioWorker#setOption, and have values return,
so it should always return true.
---
[standalone@localhost:9990 /] /subsystem=io/worker=default:write-attribute(name=task-keepalive, value=10000)
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=io/worker=default:write-attribute(name=task-max-threads, value=10000)
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=io/worker=default:write-attribute(name=io-threads, value=10000)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=io/worker=default:write-attribute(name=task-core-threads, value=10000)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
---
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3962) Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3962?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3962:
---------------------------------------
I think this is going to be best handled with documentation. For standalone we could probably just add the module if we know we're using Java 9+. Another option would be to just have commented out {{JAVA_OPT="--add-modules=java.se $JAVA_OPTS"}} in the {{standalone.conf}} file.
For domain it would be a manual process anyway. While we could detect Java 9+ for the HC and DC we can't for the servers.
In the {{domain.conf}} we'd need:
{code}
PROCESS_CONTROLLER_JAVA_OPTS="--add-modules=java.se $PROCESS_CONTROLLER_JAVA_OPTS"
HOST_CONTROLLER_JAVA_OPTS="--add-modules=java.se $HOST_CONTROLLER_JAVA_OPTS"
{code}
Then the following CLI command would need to be executed:
{code}
/host=master/jvm=default:add-jvm-option(jvm-option="--add-modules=java.se")
{code}
Note though that means the target server is using Java 9+.
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3962
> URL: https://issues.jboss.org/browse/WFCORE-3962
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Modules, Scripts
> Affects Versions: 6.0.0.Alpha3
> Reporter: Matej Novotny
> Assignee: Richard Opalka
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> As per request, copying MODULES-372 to WFCORE as well.
> Starting WFLY with JDK 11 using {{standalone.sh}} yields:
> {code}
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> {code}
> Output of {{java -version}}:
> {code}
> openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+21)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10839) RetryingInvoker fails with millisecond timeouts (IllegalArgumentException: nanosecond timeout value out of range)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10839?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10839:
----------------------------------
Priority: Critical (was: Blocker)
> RetryingInvoker fails with millisecond timeouts (IllegalArgumentException: nanosecond timeout value out of range)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10839
> URL: https://issues.jboss.org/browse/WFLY-10839
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 14.0.0.CR1
>
>
> This is because Duration stores the value as seconds + nanosecond precision, while Thread.sleep requests nanoseconds as remainder to milliseconds, i.e. less than or equal to 999_999.
> {code}
> 15:18:43,654 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 82) MSC000001: Failed to start service org.wildfly.clustering.cache.registry.ejb.client-mappings: org.jboss.msc.service.StartException in service org.wildfly.clustering.cache.registry.ejb.client-mappings: java.lang.IllegalArgumentException: nanosecond timeout value out of range
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$start$0(AsyncServiceConfigurator.java:117) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> Caused by: java.lang.IllegalArgumentException: nanosecond timeout value out of range
> at java.lang.Thread.sleep(Thread.java:332) [rt.jar:1.8.0_181]
> at org.wildfly.clustering.ee.retry.RetryingInvoker.invoke(RetryingInvoker.java:60)
> at org.wildfly.clustering.ee.retry.RetryingInvoker.invoke(RetryingInvoker.java:78)
> at org.wildfly.clustering.server.registry.CacheRegistry.<init>(CacheRegistry.java:105)
> at org.wildfly.clustering.server.registry.CacheRegistryFactoryServiceConfigurator.apply(CacheRegistryFactoryServiceConfigurator.java:64)
> at org.wildfly.clustering.server.registry.CacheRegistryFactoryServiceConfigurator.apply(CacheRegistryFactoryServiceConfigurator.java:48)
> at org.wildfly.clustering.server.registry.FunctionalRegistryFactory.createRegistry(FunctionalRegistryFactory.java:55)
> at org.wildfly.clustering.server.registry.RegistryServiceConfigurator.get(RegistryServiceConfigurator.java:69)
> at org.wildfly.clustering.server.registry.RegistryServiceConfigurator.get(RegistryServiceConfigurator.java:53)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> ... 7 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4034) RuntimeException when call key-store=ks:revoke-certificate
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4034?page=com.atlassian.jira.plugi... ]
Farah Juma reassigned WFCORE-4034:
----------------------------------
Assignee: Farah Juma (was: Darran Lofthouse)
> RuntimeException when call key-store=ks:revoke-certificate
> ----------------------------------------------------------
>
> Key: WFCORE-4034
> URL: https://issues.jboss.org/browse/WFCORE-4034
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Farah Juma
>
> There is a RuntimeException when call a key-store=keys:revoke-certificate on a existing alias, but having failed to obtain certificate from CA
> Steps to reproduce
> {code}
> /subsystem=elytron/key-store=keyst2:add(credential-reference={clear-text=senha},type=JKS,path=keyst2.jks)
> /subsystem=elytron/certificate-authority-account=ca_letsenc2:add(alias=www.cnn.com,key-store=keyst2)
> /subsystem=elytron/key-store=keyst2:obtain-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2,domain-names=["www.cnn.com"],agree-to-terms-of-service,algorithm=RSA)
> /subsystem=elytron/key-store=keyst2:revoke-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2)
> {code}
> obtain-certificate results in an exception, then call revoke-certificate
> {code}
> /subsystem=elytron/key-store=keyst2:obtain-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2,domain-names=["www.cnn.com"],agree-to-terms-of-service,algorithm=RSA)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: org.wildfly.security.x500.cert.acme.AcmeException: ELY10048: Challenge response failed validation by the ACME ser
> ver",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=keyst2:revoke-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: org.wildfly.security.x500.cert.acme.AcmeException: No such certificate",
> "rolled-back" => true
> }
> {code}
> I understand it make no sense to revoke a certificate that doesn't exist in CA provider, but it was more an accident to discover it as I was playing with the operations.
> Probably a WARN message would be more appropriate than a RuntimeException.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months