[
https://issues.jboss.org/browse/ISPN-9511?page=com.atlassian.jira.plugin....
]
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)