Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pending invocations not cleaned up on client disconnect #13388

Closed
mmedenjak opened this issue Jun 29, 2018 · 5 comments
Closed

Pending invocations not cleaned up on client disconnect #13388

mmedenjak opened this issue Jun 29, 2018 · 5 comments

Comments

@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Jun 29, 2018

Example:
Server

public class HazelcastServer {
    public static void main(String[] args) {
        Hazelcast.newHazelcastInstance();
    }
}

Client

public static void main(String[] args) {
        HazelcastInstance hz = com.hazelcast.client.HazelcastClient.newHazelcastClient();
        final ITopic<Object> top = hz.getReliableTopic("topic");
        top.addMessageListener(new Listener());
    }

    public static class Listener implements ReliableMessageListener<Object> {

        @Override
        public long retrieveInitialSequence() {
            return -1;
        }

        @Override
        public void storeSequence(long sequence) {

        }

        @Override
        public boolean isLossTolerant() {
            return false;
        }

        @Override
        public boolean isTerminal(Throwable failure) {
            return false;
        }

        @Override
        public void onMessage(Message<Object> message) {
            System.out.println(message);
        }
    }

If the client is terminated, the member will eventually clean up resources but not pending invocations:
[Invocation{op=com.hazelcast.ringbuffer.impl.operations.ReadManyOperation{serviceName='hz:impl:ringbufferService', identityHash=915683338, partitionId=85, replicaIndex=0, callId=7, invocationTime=1530284086978 (2018-06-29 16:54:46.978), waitTimeout=-1, callTimeout=60000, name=_hz_rb_topic}, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeoutMillis=60000, firstInvocationTimeMs=1530284086978, firstInvocationTime='2018-06-29 16:54:46.978', lastHeartbeatMillis=1530285477544, lastHeartbeatTime='2018-06-29 17:17:57.544', target=[192.168.1.5]:5701, pendingResponse={VOID}, backupsAcksExpected=0, backupsAcksReceived=0, connection=null}, Invocation{op=com.hazelcast.ringbuffer.impl.operations.ReadManyOperation{serviceName='hz:impl:ringbufferService', identityHash=1315481610, partitionId=85, replicaIndex=0, callId=16, invocationTime=1530284233395 (2018-06-29 16:57:13.395), waitTimeout=-1, callTimeout=60000, name=_hz_rb_topic}, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeoutMillis=60000, firstInvocationTimeMs=1530284112421, firstInvocationTime='2018-06-29 16:55:12.421', lastHeartbeatMillis=1530285477544, lastHeartbeatTime='2018-06-29 17:17:57.544', target=[192.168.1.5]:5701, pendingResponse={VOID}, backupsAcksExpected=0, backupsAcksReceived=0, connection=null}, Invocation{op=com.hazelcast.ringbuffer.impl.operations.ReadManyOperation{serviceName='hz:impl:ringbufferService', identityHash=1612708436, partitionId=85, replicaIndex=0, callId=23, invocationTime=1530284267224 (2018-06-29 16:57:47.224), waitTimeout=-1, callTimeout=60000, name=_hz_rb_topic}, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeoutMillis=60000, firstInvocationTimeMs=1530284267224, firstInvocationTime='2018-06-29 16:57:47.224', lastHeartbeatMillis=1530285477544, lastHeartbeatTime='2018-06-29 17:17:57.544', target=[192.168.1.5]:5701, pendingResponse={VOID}, backupsAcksExpected=0, backupsAcksReceived=0, connection=null}, Invocation{op=com.hazelcast.ringbuffer.impl.operations.ReadManyOperation{serviceName='hz:impl:ringbufferService', identityHash=622688307, partitionId=85, replicaIndex=0, callId=29, invocationTime=1530284273485 (2018-06-29 16:57:53.485), waitTimeout=-1, callTimeout=60000, name=_hz_rb_topic}, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeoutMillis=60000, firstInvocationTimeMs=1530284273485, firstInvocationTime='2018-06-29 16:57:53.485', lastHeartbeatMillis=1530285477544, lastHeartbeatTime='2018-06-29 17:17:57.544', target=[192.168.1.5]:5701, pendingResponse={VOID}, backupsAcksExpected=0, backupsAcksReceived=0, connection=null}, Invocation{op=com.hazelcast.ringbuffer.impl.operations.ReadManyOperation{serviceName='hz:impl:ringbufferService', identityHash=2070084819, partitionId=85, replicaIndex=0, callId=38, invocationTime=1530285035282 (2018-06-29 17:10:35.282), waitTimeout=-1, callTimeout=60000, name=_hz_rb_topic}, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeoutMillis=60000, firstInvocationTimeMs=1530285035282, firstInvocationTime='2018-06-29 17:10:35.282', lastHeartbeatMillis=1530285477544, lastHeartbeatTime='2018-06-29 17:17:57.544', target=[192.168.1.5]:5701, pendingResponse={VOID}, backupsAcksExpected=0, backupsAcksReceived=0, connection=null}, Invocation{op=ClientDisconnectionOperation{clientUuid='58d19b28-be41-4125-a4f5-378f3908d852', memberUuid='0bf6f8b7-8081-4ef6-9c30-faa8e5281fc0'} com.hazelcast.client.impl.operations.ClientDisconnectionOperation{serviceName='hz:core:clientEngine', identityHash=1046504827, partitionId=-1, replicaIndex=0, callId=39, invocationTime=1530285103585 (2018-06-29 17:11:43.585), waitTimeout=-1, callTimeout=60000}, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeoutMillis=60000, firstInvocationTimeMs=1530285103585, firstInvocationTime='2018-06-29 17:11:43.585', lastHeartbeatMillis=0, lastHeartbeatTime='1970-01-01 01:00:00.000', target=[192.168.1.5]:5701, pendingResponse={VOID}, backupsAcksExpected=0, backupsAcksReceived=0, connection=null}]

@LoneGumMan
Copy link

@LoneGumMan LoneGumMan commented Aug 2, 2018

If this is indeed the same issue as #12353, is there a possibility to backport the fix to 3.8 / 3.9 / 3.10?

@mmedenjak
Copy link
Contributor Author

@mmedenjak mmedenjak commented Sep 6, 2018

@LoneGumMan the fix was backported to 3.10.5 which should be released in a couple of days.

@LoneGumMan
Copy link

@LoneGumMan LoneGumMan commented Sep 7, 2018

Thank you, appreciate it. Judging by the commits, it looks to be a server only change.

is there anything to look out for when upgrading from 3.8.x to 3.10.5? More importantly, can 3.8 client interop with 3.10 server nodes?

@mmedenjak
Copy link
Contributor Author

@mmedenjak mmedenjak commented Sep 11, 2018

3.10.5 should be backwards compatible with 3.8.x. Clients with versions 3.6+ should be able to work with newer members.

@mmedenjak
Copy link
Contributor Author

@mmedenjak mmedenjak commented Sep 18, 2018

@LoneGumMan 3.10.5 was released. Can you please try with it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants
You can’t perform that action at this time.