[JBoss JIRA] (ISPN-12110) Upgrade httpcomponents to 4.4.5
by Pedro Ruivo (Jira)
Pedro Ruivo created ISPN-12110:
----------------------------------
Summary: Upgrade httpcomponents to 4.4.5
Key: ISPN-12110
URL: https://issues.redhat.com/browse/ISPN-12110
Project: Infinispan
Issue Type: Component Upgrade
Affects Versions: 9.4.19.Final
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 9.4.20.Final
org.apache.httpcomponents:httpasyncclient=4.1.4
org.apache.httpcomponents:httpclient=4.5.4
org.apache.httpcomponents:httpcore=4.4.5
org.apache.httpcomponents:httpcore-nio=4.4.5
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (ISPN-12109) TcpConnection.Receiver.run() blocking call
by Dan Berindei (Jira)
Dan Berindei created ISPN-12109:
-----------------------------------
Summary: TcpConnection.Receiver.run() blocking call
Key: ISPN-12109
URL: https://issues.redhat.com/browse/ISPN-12109
Project: Infinispan
Issue Type: Bug
Components: Core, Test Suite
Affects Versions: 11.0.1.Final
Reporter: Dan Berindei
Assignee: Will Burns
Fix For: 12.0.0.Final, 11.0.2.Final
{noformat}
[TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.WorkDuringJoinTest[DIST_SYNC, tx=false].BlockingChecker
22:28:37.967 [Connection.Receiver [127.0.0.1:34169 - 127.0.0.1:8001]-8,WorkDuringJoinTest-NodeC] ERROR org.infinispan.commons.test.TestSuiteProgress - Test failed: org.infinispan.distribution.rehash.WorkDuringJoinTest[DIST_SYNC, tx=false].BlockingChecker
java.lang.AssertionError: Blocking call! java.net.SocketInputStream#socketRead0 on thread Thread[Connection.Receiver [127.0.0.1:34169 - 127.0.0.1:8001]-8,WorkDuringJoinTest-NodeC,5,ISPN-non-blocking-thread-group]
at org.infinispan.util.CoreTestBlockHoundIntegration.lambda$applyTo$0(CoreTestBlockHoundIntegration.java:45) ~[test-classes/:?]
at reactor.blockhound.BlockHound$Builder.lambda$install$8(BlockHound.java:383) ~[blockhound-1.0.3.RELEASE.jar:?]
at reactor.blockhound.BlockHoundRuntime.checkBlocking(BlockHoundRuntime.java:89) [?:?]
at java.net.SocketInputStream.socketRead0(SocketInputStream.java) [?:?]
at java.net.SocketInputStream.socketRead(SocketInputStream.java:115) [?:?]
at java.net.SocketInputStream.read(SocketInputStream.java:168) [?:?]
at java.net.SocketInputStream.read(SocketInputStream.java:140) [?:?]
at java.io.BufferedInputStream.fill(BufferedInputStream.java:252) [?:?]
at java.io.BufferedInputStream.read(BufferedInputStream.java:271) [?:?]
at java.io.DataInputStream.readInt(DataInputStream.java:392) [?:?]
at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:301) [jgroups-4.2.1.Final.jar:4.2.1.Final]
at java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
The blocking call doesn't always happen, but it appears to be more common in the unstable CI builds:
https://ci.infinispan.org/job/InfinispanAlternateBuilds/job/InfinispanUns...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (ISPN-12109) TcpConnection.Receiver.run() blocking call
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12109?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-12109:
--------------------------------
Status: Open (was: New)
> TcpConnection.Receiver.run() blocking call
> ------------------------------------------
>
> Key: ISPN-12109
> URL: https://issues.redhat.com/browse/ISPN-12109
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 11.0.1.Final
> Reporter: Dan Berindei
> Assignee: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final, 11.0.2.Final
>
>
> {noformat}
> [TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.WorkDuringJoinTest[DIST_SYNC, tx=false].BlockingChecker
> 22:28:37.967 [Connection.Receiver [127.0.0.1:34169 - 127.0.0.1:8001]-8,WorkDuringJoinTest-NodeC] ERROR org.infinispan.commons.test.TestSuiteProgress - Test failed: org.infinispan.distribution.rehash.WorkDuringJoinTest[DIST_SYNC, tx=false].BlockingChecker
> java.lang.AssertionError: Blocking call! java.net.SocketInputStream#socketRead0 on thread Thread[Connection.Receiver [127.0.0.1:34169 - 127.0.0.1:8001]-8,WorkDuringJoinTest-NodeC,5,ISPN-non-blocking-thread-group]
> at org.infinispan.util.CoreTestBlockHoundIntegration.lambda$applyTo$0(CoreTestBlockHoundIntegration.java:45) ~[test-classes/:?]
> at reactor.blockhound.BlockHound$Builder.lambda$install$8(BlockHound.java:383) ~[blockhound-1.0.3.RELEASE.jar:?]
> at reactor.blockhound.BlockHoundRuntime.checkBlocking(BlockHoundRuntime.java:89) [?:?]
> at java.net.SocketInputStream.socketRead0(SocketInputStream.java) [?:?]
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:115) [?:?]
> at java.net.SocketInputStream.read(SocketInputStream.java:168) [?:?]
> at java.net.SocketInputStream.read(SocketInputStream.java:140) [?:?]
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:252) [?:?]
> at java.io.BufferedInputStream.read(BufferedInputStream.java:271) [?:?]
> at java.io.DataInputStream.readInt(DataInputStream.java:392) [?:?]
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:301) [jgroups-4.2.1.Final.jar:4.2.1.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> The blocking call doesn't always happen, but it appears to be more common in the unstable CI builds:
> https://ci.infinispan.org/job/InfinispanAlternateBuilds/job/InfinispanUns...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (ISPN-12097) Invalidation Cache invalidation removes entry from store with new SPI changes
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-12097?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-12097:
------------------------------
Summary: Invalidation Cache invalidation removes entry from store with new SPI changes (was: NonBlockingStore.batch(...) unexpectedly triggers entry removal)
> Invalidation Cache invalidation removes entry from store with new SPI changes
> -----------------------------------------------------------------------------
>
> Key: ISPN-12097
> URL: https://issues.redhat.com/browse/ISPN-12097
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 11.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Will Burns
> Priority: Blocker
> Attachments: Test.java
>
>
> There seems to be something amiss with the new NonBlockingStore changes. When a transactional invalidation cache is used with a shared cache store, I've observed the entries published to the removePublisher of the NonBlockStore.batch(...) which should have targeted the writePublisher. This seems to happen when a batch only contains writes, but no removes.
> See the attached test to reproduce the issue, which executes two simple cache operations against a transactional vs non-transactional cache using a shared write-through store. The transactional version fails due to unexpected removals triggered by the batch(...) method (which, in the case of the JDBC store delegates to the deleteBatch(...) and bulkUpdate(...) methods. TRACE logging indicates that entries are unexpectedly published to the removePublisher of batch(...) when transactions are enabled causing entries to be removed unexpectedly from the store (as the result of a Cache.put(...)). When tx are disabled, the batch(...) method is, of course, not in play, and everything works correctly via the individual write/delete methods.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months