[infinispan-issues] [JBoss JIRA] (ISPN-9511) Expired event is not raised when modifying an expired entry

[William Burns (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635167#comment-13635167 ] 

William Burns commented on ISPN-9511:
-------------------------------------

So the problem is that the actual error was never stored in the correct log file.

If I check the global trace file, I can find the exception causing the "failover".

{code}
09:11:00,159 TRACE (HotRod-client-async-pool-3:[]) [HeaderDecoder] Response 23 belongs to PutOperation{(default), key=[B0x034BEBCEF4CA, value=[B0x033E027632, flags=6} on [id: 0x876415fe, L:/127.0.0.1:41108 - R:127.0.0.1/127.0.0.1:34808]
09:11:00,159 TRACE (HotRod-client-async-pool-3:[]) [HeaderDecoder] Decoding header for PutOperation{(default), key=[B0x034BEBCEF4CA, value=[B0x033E027632, flags=6} on [id: 0x876415fe, L:/127.0.0.1:41108 - R:127.0.0.1/127.0.0.1:34808]
09:11:00,159 WARN  (HotRod-client-async-pool-2:[]) [HeaderDecoder] ISPN004039: Unable to complete reading event from server 127.0.0.1/127.0.0.1:39088
org.infinispan.client.hotrod.exceptions.HotRodClientException: ISPN004034: Unable to unmarshall bytes 3C737472696E673E262378333B4BEFBFBDEFBFBDEFBFBDEFBFBD3C2F737472696E673E
	at org.infinispan.client.hotrod.marshall.MarshallerUtil.bytes2obj(MarshallerUtil.java:47) ~[classes/:?]
	at org.infinispan.client.hotrod.DataFormat.keyToObj(DataFormat.java:103) ~[classes/:?]
	at org.infinispan.client.hotrod.impl.protocol.Codec21.readCacheEvent(Codec21.java:79) ~[classes/:?]
	at org.infinispan.client.hotrod.impl.transport.netty.HeaderDecoder.decode(HeaderDecoder.java:153) [classes/:?]
	at org.infinispan.client.hotrod.impl.transport.netty.HintedReplayingDecoder.callDecode(HintedReplayingDecoder.java:98) [classes/:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265) [netty-codec-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) [netty-handler-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1414) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:945) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:806) [netty-transport-native-epoll-4.1.22.Final-linux-x86_64.jar:4.1.22.Final]
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:404) [netty-transport-native-epoll-4.1.22.Final-linux-x86_64.jar:4.1.22.Final]
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304) [netty-transport-native-epoll-4.1.22.Final-linux-x86_64.jar:4.1.22.Final]
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) [netty-common-4.1.22.Final.jar:4.1.22.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_181]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_181]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
Caused by: java.io.IOException: Unsupported protocol version 60
	at org.jboss.marshalling.river.RiverUnmarshaller.start(RiverUnmarshaller.java:1345) ~[jboss-marshalling-osgi-2.0.5.Final.jar:2.0.5.Final]
	at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.startObjectInput(AbstractJBossMarshaller.java:129) ~[classes/:?]
	at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:110) ~[classes/:?]
	at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82) ~[classes/:?]
	at org.infinispan.client.hotrod.marshall.MarshallerUtil.bytes2obj(MarshallerUtil.java:31) ~[classes/:?]
	... 23 more
{code}

> Expired event is not raised when modifying an expired entry
> -----------------------------------------------------------
>
>                 Key: ISPN-9511
>                 URL: https://issues.jboss.org/browse/ISPN-9511
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Listeners
>    Affects Versions: 9.3.3.Final
>            Reporter: William Burns
>            Assignee: William Burns
>             Fix For: 9.4.0.Final
>
>
> Due to the old way of implementing remove expired for lifespan, we didn't raise an expired event when writing to an entry. This was mostly to cause circular dependencies. But with the new remove expired max idle changes, this is now possible.
> Without this change listeners can be in an inconsistent state, possibly, as the following could happen:
> 1. Entry is created
> 2. Listener is notified of creation
> 3. Entry expires (no event yet)
> 4. Entry is written to (created)
> 5. Listener is notified of creation.
> In this case there is no intermediate state where the listener thought there was no entry. This also becomes problematic if you are listening only for events that don't include create.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)