[JBoss JIRA] (ISPN-9035) Rest endpoint not loaded in domain mode due to missing socket-bindings
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-9035:
----------------------------------
Summary: Rest endpoint not loaded in domain mode due to missing socket-bindings
Key: ISPN-9035
URL: https://issues.jboss.org/browse/ISPN-9035
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 9.2.1.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 9.2.2.Final
Rest endpoint cannot be loaded on startup due to the mangement-http and mangement-https socket bindings not being configured in domain.xml resulting in the following error:
{code}
[Server:server-two] 12:03:08,084 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
[Server:server-two] ("subsystem" => "datagrid-infinispan-endpoint"),
[Server:server-two] ("rest-connector" => "rest-connector")
[Server:server-two] ]) - failure description: {
[Server:server-two] "WFLYCTL0412: Required services that are not installed:" => [
[Server:server-two] "org.wildfly.network.socket-binding.management-https",
[Server:server-two] "org.wildfly.network.socket-binding.management-http"
[Server:server-two] ],
[Server:server-two] "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.datagrid-infinispan-endpoint.rest.rest-connector is missing [org.wildfly.network.socket-binding.management-http, org.wildfly.network.socket-binding.management-https]"]
[Server:server-two] }
[Server:server-two] 12:03:08,126 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
[Server:server-two] WFLYCTL0184: New missing/unsatisfied dependencies:
[Server:server-two] service org.wildfly.network.socket-binding.management-http (missing) dependents: [service jboss.datagrid-infinispan-endpoint.rest.rest-connector]
[Server:server-two] service org.wildfly.network.socket-binding.management-https (missing) dependents: [service jboss.datagrid-infinispan-endpoint.rest.rest-connector]
[Server:server-two]
[Server:server-two] 12:03:08,166 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
[Server:server-two] 12:03:08,169 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: Infinispan Server 9.2.2-SNAPSHOT (WildFly Core 3.0.8.Final) started (with errors) in 10503ms - Started 206 of 257 services (1 services failed or missing dependencies, 126 services are lazy, passive or on-demand)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9034) InfinispanExtensionIT should depend on "org.infinispan"
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9034?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reopened ISPN-9034:
--------------------------------
> InfinispanExtensionIT should depend on "org.infinispan"
> -------------------------------------------------------
>
> Key: ISPN-9034
> URL: https://issues.jboss.org/browse/ISPN-9034
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server, WildFly modules
> Affects Versions: 9.2.1.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.2.Final
>
>
> Currently the deployment in InfinispanExtensionIT does not have an explicit dependency on "org.infinispan" which means that a ClassNotFoundException will be thrown if certain methods are called on the container. The test should be updated so that the deployment has the appropriate manifest dependency, but if said dependency is removed the test will fail.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9034) InfinispanExtensionIT should depend on "org.infinispan"
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-9034?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-9034:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated in master. Thanks [~ryanemerson]!
> InfinispanExtensionIT should depend on "org.infinispan"
> -------------------------------------------------------
>
> Key: ISPN-9034
> URL: https://issues.jboss.org/browse/ISPN-9034
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server, WildFly modules
> Affects Versions: 9.2.1.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.2.Final
>
>
> Currently the deployment in InfinispanExtensionIT does not have an explicit dependency on "org.infinispan" which means that a ClassNotFoundException will be thrown if certain methods are called on the container. The test should be updated so that the deployment has the appropriate manifest dependency, but if said dependency is removed the test will fail.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ]
William Burns edited comment on ISPN-9003 at 4/3/18 1:12 PM:
-------------------------------------------------------------
Talking with [~NadirX] we believe the best approach may be a consensus based removal of maxIdle entries. That is it will do the following things
1. Read occurs on node where maxIdle is expired and sends request to primary owner (blocks the read)
2. Primary owner locks the key
3. Primary sends message to all nodes asking if entry is expired due to maxIdle -(also updates the updated time on all keys - just in case it isn't expired)-
4. Primary receives responses to decide if it is expired
5a. Primary responds to read node and tells them if it was expired
5b. Primary removes from all nodes if it was expired or sends request to all nodes to update last access time (reaper updates to largest access and read updates every node to now + maxIdle).
6. Cluster wide expiration occurs if necessary allowing for listeners to be invoked (including cluster listeners - which we didn't do before)
The above approach gives no overhead for reads when the entry is not present and is not expired. The only overhead is if a node finds that the entry was expired via maxIdle and then must block to confirm if it should be removed. However the chance of this occurring seems a bit low depending on what maxIdle was set to. If the expiration reaper finds the expired entry first it will properly update its timestamps or remove as needed.
Another side effect of this is that maxIdle may be refreshed for all entries that are transferred via state transfer since I don't think the access time is currently replicated when state transfer occurs.
was (Author: william.burns):
Talking with [~NadirX] we believe the best approach may be a consensus based removal of maxIdle entries. That is it will do the following things
1. Read occurs on node where maxIdle is expired and sends request to primary owner (blocks the read)
2. Primary owner locks the key
3. Primary sends message to all nodes asking if entry is expired due to maxIdle -(also updates the updated time on all keys - just in case it isn't expired)-
4. Primary receives responses to decide if it is expired
5a. Primary responds to read node and tells them if it was expired
5b. Primary removes from all nodes if it was expired or sends request to all nodes to update last access time.
6. Cluster wide expiration occurs if necessary allowing for listeners to be invoked (including cluster listeners - which we didn't do before)
The above approach gives no overhead for reads when the entry is not present and is not expired. The only overhead is if a node finds that the entry was expired via maxIdle and then must block to confirm if it should be removed. However the chance of this occurring seems a bit low depending on what maxIdle was set to. If the expiration reaper finds the expired entry first it will properly update its timestamps or remove as needed.
Another side effect of this is that maxIdle may be refreshed for all entries that are transferred via state transfer since I don't think the access time is currently replicated when state transfer occurs.
> Clustered maxIdle expiration
> ----------------------------
>
> Key: ISPN-9003
> URL: https://issues.jboss.org/browse/ISPN-9003
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: William Burns
> Fix For: 9.3.0.Beta1, 9.3.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-9003:
-------------------------------------
Talking with [~dan.berindei] more I agree that we can tweak the algorithm to return the last access time from the various nodes. This way when the reaper runs it update the last access time to the highest number of all nodes and setting their access time to that. This prevents a full refresh when the reaper thread finds an expired entry that may not yet be expired.
> Clustered maxIdle expiration
> ----------------------------
>
> Key: ISPN-9003
> URL: https://issues.jboss.org/browse/ISPN-9003
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: William Burns
> Fix For: 9.3.0.Beta1, 9.3.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-9003:
------------------------------------
If you're running the reaper on all the owners, every time the entry is about to expire on one node, that node will ask the other owners, see that the entry is not expired there, and update the last access time to {{now}} everywhere. In a replicated cache, I can see this going on forever without expiring the entry.
> Clustered maxIdle expiration
> ----------------------------
>
> Key: ISPN-9003
> URL: https://issues.jboss.org/browse/ISPN-9003
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: William Burns
> Fix For: 9.3.0.Beta1, 9.3.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months