[JBoss JIRA] (ISPN-9113) SITE_UNREACHABLE not handled by JGroupsTransport
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9113?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9113:
-----------------------------------
Description:
If a user defineds a site with SYNC x-site replication and the site is unavailable, requests will timeout instead of quickly failing. See below for a summary discussion:
{code}
Galder: @Dan Berindei @Pedro Ruivo @Bela Ban Any thoughts on my dev thread?
Galder: In essence, @Dan Berindei you made ChannelCallbacks implement UpHandler, but JChannel.invokeCallback()
won't pass any events to receive instance variable because it doesn't check whether the receiver is UpHandler //cc @Tristan
Bela Ban: @Galder yes, this won't work
Bela Ban: @Galder You need to call RELAY2.setRouterStatusListener() directly
Bela Ban: Implementing this as part of Receiver won't help
Galder: Don't think RELAY2.setRouterStatusListener() is what I want - I can see RELAY2.handleMessage() passing up the
stack Event.SITE_UNREACHABLE though, the problem is that there's no handler for that
Bela Ban: @Galder Yes, but the SITE_UNREACHABLE event is only handled by RequestCorrelator, not by JChannel
Galder: Ah ok, let me check what that does
Bela Ban: The thing is that RequestCorrelator is not used anymore (AFAIK), as Infinispan moved from
MessageDispatcher to JChannel
Galder: the RequestCorrelator is never called
Galder: exactly
Bela Ban: So this is a regression caused by that move then
Galder: Yeah, that's my feeling too. That's why I was asking Dan about the move to make ChannelCallbacks class an
UpHandler, because I noticed that happened when the move to JChannel happened
Galder: The impact of this is the following: if any site in SYNC and the site is unreachable, you'd get a timeout eventually
instead of a immediate failure
Galder: I'm trying to implement auto x-site state transfer for protobuf metadata cache and I cannot do it until this is fixed
Galder: I'll see if I can get something working with ASYNC, but ASYNC is not a good option for protobuf metadata.
If a node does not succesfully get it, it won't be able to work properly
{code}
was:
If a user defineds a site with SYNC x-site replication and the site is unavailable, requests will timeout instead of quickly failing. See below for a summary discussion:
{code}
Galder: @Dan Berindei @Pedro Ruivo @Bela Ban Any thoughts on my dev thread?
Galder: In essence, @Dan Berindei you made ChannelCallbacks implement UpHandler, but JChannel.invokeCallback() won't pass any events to receive instance variable because it doesn't check whether the receiver is UpHandler //cc @Tristan
Bela Ban: @Galder yes, this won't work
Bela Ban: @Galder You need to call RELAY2.setRouterStatusListener() directly
Bela Ban: Implementing this as part of Receiver won't help
Galder: Don't think RELAY2.setRouterStatusListener() is what I want - I can see RELAY2.handleMessage() passing up the stack Event.SITE_UNREACHABLE though, the problem is that there's no handler for that
Bela Ban: @Galder Yes, but the SITE_UNREACHABLE event is only handled by RequestCorrelator, not by JChannel
Galder: Ah ok, let me check what that does
Bela Ban: The thing is that RequestCorrelator is not used anymore (AFAIK), as Infinispan moved from MessageDispatcher to JChannel
Galder: the RequestCorrelator is never called
Galder: exactly
Bela Ban: So this is a regression caused by that move then
Galder: Yeah, that's my feeling too. That's why I was asking Dan about the move to make ChannelCallbacks class an UpHandler, because I noticed that happened when the move to JChannel happened
Galder: The impact of this is the following: if any site in SYNC and the site is unreachable, you'd get a timeout eventually instead of a immediate failure
Galder: I'm trying to implement auto x-site state transfer for protobuf metadata cache and I cannot do it until this is fixed
Galder: I'll see if I can get something working with ASYNC, but ASYNC is not a good option for protobuf metadata. If a node does not succesfully get it, it won't be able to work properly
{code}
> SITE_UNREACHABLE not handled by JGroupsTransport
> ------------------------------------------------
>
> Key: ISPN-9113
> URL: https://issues.jboss.org/browse/ISPN-9113
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 9.2.2.Final, 9.3.0.Alpha1
> Reporter: Galder Zamarreño
>
> If a user defineds a site with SYNC x-site replication and the site is unavailable, requests will timeout instead of quickly failing. See below for a summary discussion:
> {code}
> Galder: @Dan Berindei @Pedro Ruivo @Bela Ban Any thoughts on my dev thread?
> Galder: In essence, @Dan Berindei you made ChannelCallbacks implement UpHandler, but JChannel.invokeCallback()
> won't pass any events to receive instance variable because it doesn't check whether the receiver is UpHandler //cc @Tristan
> Bela Ban: @Galder yes, this won't work
> Bela Ban: @Galder You need to call RELAY2.setRouterStatusListener() directly
> Bela Ban: Implementing this as part of Receiver won't help
> Galder: Don't think RELAY2.setRouterStatusListener() is what I want - I can see RELAY2.handleMessage() passing up the
> stack Event.SITE_UNREACHABLE though, the problem is that there's no handler for that
> Bela Ban: @Galder Yes, but the SITE_UNREACHABLE event is only handled by RequestCorrelator, not by JChannel
> Galder: Ah ok, let me check what that does
> Bela Ban: The thing is that RequestCorrelator is not used anymore (AFAIK), as Infinispan moved from
> MessageDispatcher to JChannel
> Galder: the RequestCorrelator is never called
> Galder: exactly
> Bela Ban: So this is a regression caused by that move then
> Galder: Yeah, that's my feeling too. That's why I was asking Dan about the move to make ChannelCallbacks class an
> UpHandler, because I noticed that happened when the move to JChannel happened
> Galder: The impact of this is the following: if any site in SYNC and the site is unreachable, you'd get a timeout eventually
> instead of a immediate failure
> Galder: I'm trying to implement auto x-site state transfer for protobuf metadata cache and I cannot do it until this is fixed
> Galder: I'll see if I can get something working with ASYNC, but ASYNC is not a good option for protobuf metadata.
> If a node does not succesfully get it, it won't be able to work properly
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months
[JBoss JIRA] (ISPN-9113) SITE_UNREACHABLE not handled by JGroupsTransport
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9113?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9113:
-----------------------------------
Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2018-April/018104.html
> SITE_UNREACHABLE not handled by JGroupsTransport
> ------------------------------------------------
>
> Key: ISPN-9113
> URL: https://issues.jboss.org/browse/ISPN-9113
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 9.2.2.Final, 9.3.0.Alpha1
> Reporter: Galder Zamarreño
>
> If a user defineds a site with SYNC x-site replication and the site is unavailable, requests will timeout instead of quickly failing. See below for a summary discussion:
> {code}
> Galder: @Dan Berindei @Pedro Ruivo @Bela Ban Any thoughts on my dev thread?
> Galder: In essence, @Dan Berindei you made ChannelCallbacks implement UpHandler, but JChannel.invokeCallback()
> won't pass any events to receive instance variable because it doesn't check whether the receiver is UpHandler //cc @Tristan
> Bela Ban: @Galder yes, this won't work
> Bela Ban: @Galder You need to call RELAY2.setRouterStatusListener() directly
> Bela Ban: Implementing this as part of Receiver won't help
> Galder: Don't think RELAY2.setRouterStatusListener() is what I want - I can see RELAY2.handleMessage() passing up the
> stack Event.SITE_UNREACHABLE though, the problem is that there's no handler for that
> Bela Ban: @Galder Yes, but the SITE_UNREACHABLE event is only handled by RequestCorrelator, not by JChannel
> Galder: Ah ok, let me check what that does
> Bela Ban: The thing is that RequestCorrelator is not used anymore (AFAIK), as Infinispan moved from
> MessageDispatcher to JChannel
> Galder: the RequestCorrelator is never called
> Galder: exactly
> Bela Ban: So this is a regression caused by that move then
> Galder: Yeah, that's my feeling too. That's why I was asking Dan about the move to make ChannelCallbacks class an
> UpHandler, because I noticed that happened when the move to JChannel happened
> Galder: The impact of this is the following: if any site in SYNC and the site is unreachable, you'd get a timeout eventually
> instead of a immediate failure
> Galder: I'm trying to implement auto x-site state transfer for protobuf metadata cache and I cannot do it until this is fixed
> Galder: I'll see if I can get something working with ASYNC, but ASYNC is not a good option for protobuf metadata.
> If a node does not succesfully get it, it won't be able to work properly
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months
[JBoss JIRA] (ISPN-9113) SITE_UNREACHABLE not handled by JGroupsTransport
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-9113:
--------------------------------------
Summary: SITE_UNREACHABLE not handled by JGroupsTransport
Key: ISPN-9113
URL: https://issues.jboss.org/browse/ISPN-9113
Project: Infinispan
Issue Type: Bug
Components: Cross-Site Replication
Affects Versions: 9.3.0.Alpha1, 9.2.2.Final
Reporter: Galder Zamarreño
If a user defineds a site with SYNC x-site replication and the site is unavailable, requests will timeout instead of quickly failing. See below for a summary discussion:
{code}
Galder: @Dan Berindei @Pedro Ruivo @Bela Ban Any thoughts on my dev thread?
Galder: In essence, @Dan Berindei you made ChannelCallbacks implement UpHandler, but JChannel.invokeCallback() won't pass any events to receive instance variable because it doesn't check whether the receiver is UpHandler //cc @Tristan
Bela Ban: @Galder yes, this won't work
Bela Ban: @Galder You need to call RELAY2.setRouterStatusListener() directly
Bela Ban: Implementing this as part of Receiver won't help
Galder: Don't think RELAY2.setRouterStatusListener() is what I want - I can see RELAY2.handleMessage() passing up the stack Event.SITE_UNREACHABLE though, the problem is that there's no handler for that
Bela Ban: @Galder Yes, but the SITE_UNREACHABLE event is only handled by RequestCorrelator, not by JChannel
Galder: Ah ok, let me check what that does
Bela Ban: The thing is that RequestCorrelator is not used anymore (AFAIK), as Infinispan moved from MessageDispatcher to JChannel
Galder: the RequestCorrelator is never called
Galder: exactly
Bela Ban: So this is a regression caused by that move then
Galder: Yeah, that's my feeling too. That's why I was asking Dan about the move to make ChannelCallbacks class an UpHandler, because I noticed that happened when the move to JChannel happened
Galder: The impact of this is the following: if any site in SYNC and the site is unreachable, you'd get a timeout eventually instead of a immediate failure
Galder: I'm trying to implement auto x-site state transfer for protobuf metadata cache and I cannot do it until this is fixed
Galder: I'll see if I can get something working with ASYNC, but ASYNC is not a good option for protobuf metadata. If a node does not succesfully get it, it won't be able to work properly
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months
[JBoss JIRA] (ISPN-7420) Hot Rod enhancements for transcoding
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7420?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7420:
------------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5951
> Hot Rod enhancements for transcoding
> ------------------------------------
>
> Key: ISPN-7420
> URL: https://issues.jboss.org/browse/ISPN-7420
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Galder Zamarreño
> Assignee: Gustavo Fernandes
>
> Several enhancements will need to be made to the Hot Rod protocol to work with transcoding:
> h3. Cache Writes (key + value)
> * Cache write operations that include values should have an optional parameter to be able to define the MIME type of the key and value that is being written. When the optional parameter is sent to the server, it will enable the server to implicitly discover what the types of the key+value are.
> * Once the first cache write has determined the key+value types, the clients do not need to send them again. If the client sends different types for the same cache, it should either result in the server ignoring it or an error (the former is preferable).
> * To avoid sending unnecessary data, advanced clients could cache the key+value type for a given cache after the first write request and then don't send it again.
> h3. Cache reads
> * Any operation that involves retrieving data should optionally take the type that the value should be transcoded to when returning it back to the client. This enables data to be read in different formats.
> * Within these operations, write operations that return previous values should be included.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months
[JBoss JIRA] (ISPN-8976) 2 subclusters failed to merge to 1 cluster - IllegalLifecycleStateException
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/ISPN-8976?page=com.atlassian.jira.plugin.... ]
Robert Cernak commented on ISPN-8976:
-------------------------------------
ok, thanks for the analysis. Could you please tell me what are the next steps? Are you going to fix it, or should some actions be done on my side?
> 2 subclusters failed to merge to 1 cluster - IllegalLifecycleStateException
> ---------------------------------------------------------------------------
>
> Key: ISPN-8976
> URL: https://issues.jboss.org/browse/ISPN-8976
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.1.4.Final
> Reporter: Robert Cernak
> Assignee: Ryan Emerson
> Attachments: logs.zip
>
>
> At the beginning I have main cluster consisted of 8 nodes.
> Then I disconnected main switch on which these nodes were connected.
> This leaded to separating main cluster to 2 subclusters - first with 2 nodes and second with 6 nodes. This was expected.
> After that I rebooted the nodes. After reboot, nodes again correctly formed 2 subclusters with 2 and 6 members.
> After a long time when all nodes were stable with low cpu load, I connected the main switch back which should lead to recreation of main cluster with 8 controllers.
> However main cluster did not recovered:
> subcluster2 did not change - still had 6 nodes connected - no new members
> subcluster1 - nodes did not connect with subcluster2 and after cca 30min they left the cluster.
> When I checked infinispan logs of node1 from 1st subcluster I had IllegalLifecycleStateException for every created cache (see included logs.zip):
> [transport-thread-744a974a-2811-4f79-ac63-f32daf005d7f-p4-t6] (ClusterCacheStatus.java:599) - ISPN000228: Failed to recover cache XXX state after the current node became the coordinator
> org.infinispan.IllegalLifecycleStateException: Cache container has been stopped and cannot be reused. Recreate the cache container.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months
[JBoss JIRA] (HRJS-58) Listener error with latest Infinispan server instances
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/HRJS-58?page=com.atlassian.jira.plugin.sy... ]
Tristan Tarrant updated HRJS-58:
--------------------------------
Git Pull Request: https://github.com/infinispan/js-client/pull/19 (was: https://issues.jboss.org/browse/HRJS-58)
> Listener error with latest Infinispan server instances
> ------------------------------------------------------
>
> Key: HRJS-58
> URL: https://issues.jboss.org/browse/HRJS-58
> Project: Infinispan Javascript client
> Issue Type: Bug
> Affects Versions: 0.4.0
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.5.0
>
>
> Node.js client fails to pass testsuite against 9.2.1.Final:
> {code}
> Infinispan local client can listen for create/modified/remove events in same listener
> Message:
> TypeError: Cannot read property 'value' of undefined
> Stacktrace:
> TypeError: Cannot read property 'value' of undefined
> at /Users/g/1/infinispan-js-client/spec/utils/testing.js:321:20
> at tryCallOne (/Users/g/1/infinispan-js-client/node_modules/promise/lib/core.js:37:12)
> at /Users/g/1/infinispan-js-client/node_modules/promise/lib/core.js:123:15
> at flush (/Users/g/1/infinispan-js-client/node_modules/promise/node_modules/asap/raw.js:50:29)
> at process._tickCallback (node.js:458:13)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months
[JBoss JIRA] (HRJS-58) Listener error with latest Infinispan server instances
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-58?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño updated HRJS-58:
---------------------------------
Status: Open (was: New)
> Listener error with latest Infinispan server instances
> ------------------------------------------------------
>
> Key: HRJS-58
> URL: https://issues.jboss.org/browse/HRJS-58
> Project: Infinispan Javascript client
> Issue Type: Bug
> Affects Versions: 0.4.0
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.5.0
>
>
> Node.js client fails to pass testsuite against 9.2.1.Final:
> {code}
> Infinispan local client can listen for create/modified/remove events in same listener
> Message:
> TypeError: Cannot read property 'value' of undefined
> Stacktrace:
> TypeError: Cannot read property 'value' of undefined
> at /Users/g/1/infinispan-js-client/spec/utils/testing.js:321:20
> at tryCallOne (/Users/g/1/infinispan-js-client/node_modules/promise/lib/core.js:37:12)
> at /Users/g/1/infinispan-js-client/node_modules/promise/lib/core.js:123:15
> at flush (/Users/g/1/infinispan-js-client/node_modules/promise/node_modules/asap/raw.js:50:29)
> at process._tickCallback (node.js:458:13)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months
[JBoss JIRA] (HRJS-58) Listener error with latest Infinispan server instances
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-58?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño updated HRJS-58:
---------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://issues.jboss.org/browse/HRJS-58
> Listener error with latest Infinispan server instances
> ------------------------------------------------------
>
> Key: HRJS-58
> URL: https://issues.jboss.org/browse/HRJS-58
> Project: Infinispan Javascript client
> Issue Type: Bug
> Affects Versions: 0.4.0
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.5.0
>
>
> Node.js client fails to pass testsuite against 9.2.1.Final:
> {code}
> Infinispan local client can listen for create/modified/remove events in same listener
> Message:
> TypeError: Cannot read property 'value' of undefined
> Stacktrace:
> TypeError: Cannot read property 'value' of undefined
> at /Users/g/1/infinispan-js-client/spec/utils/testing.js:321:20
> at tryCallOne (/Users/g/1/infinispan-js-client/node_modules/promise/lib/core.js:37:12)
> at /Users/g/1/infinispan-js-client/node_modules/promise/lib/core.js:123:15
> at flush (/Users/g/1/infinispan-js-client/node_modules/promise/node_modules/asap/raw.js:50:29)
> at process._tickCallback (node.js:458:13)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 12 months