[JBoss JIRA] (ISPN-10646) Custom jars in server/lib is not working
by Gustavo Lira e Silva (Jira)
[ https://issues.jboss.org/browse/ISPN-10646?page=com.atlassian.jira.plugin... ]
Gustavo Lira e Silva reassigned ISPN-10646:
-------------------------------------------
Assignee: Gustavo Lira e Silva
> Custom jars in server/lib is not working
> -----------------------------------------
>
> Key: ISPN-10646
> URL: https://issues.jboss.org/browse/ISPN-10646
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.CR2
> Reporter: Gustavo Lira e Silva
> Assignee: Gustavo Lira e Silva
> Priority: Major
> Attachments: h2-1.4.199.jar, ispn-10646.zip
>
>
> Custom jars added to the server classpath using server/lib folder are not working properly
> Example:
> {code:java}
> GlobalConfigurationBuilder globalConfigurationBuilder = new GlobalConfigurationBuilder().defaultCacheName("default");
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration build = builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
> .table()
> .dropOnExit(true)
> .createOnStart(true)
> .tableNamePrefix("ISPN_STRING_TABLE")
> .idColumnName("ID_COLUMN").idColumnType("VARCHAR(255)")
> .dataColumnName("DATA_COLUMN").dataColumnType("VARBINARY(1000)")
> .timestampColumnName("TIMESTAMP_COLUMN").timestampColumnType("BIGINT")
> .connectionPool()
> .connectionUrl("jdbc:h2:mem:test;DB_CLOSE_DELAY=-1")
> .username("sa")
> .password("sa")
> .driverClass("org.h2.Driver")
> .build();
> DefaultCacheManager cacheManager = new DefaultCacheManager(globalConfigurationBuilder.build(), build, true);
> Cache<String, String> cache = cacheManager.getCache();
> cache.put("k1", "v1");
> System.out.println(cache.get("k1"));
> {code}
> If you place H2 driver inside ISPN_HOME/server/lib start the server and run the code above, you will receive {{ClassNotFoundException: org.h2.Driver}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10650) Expiration should not be replicated cross site
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10650?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-10650:
------------------------------
Status: Open (was: New)
> Expiration should not be replicated cross site
> ----------------------------------------------
>
> Key: ISPN-10650
> URL: https://issues.jboss.org/browse/ISPN-10650
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Expiration
> Affects Versions: 9.4.16.Final, 10.0.0.CR2
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> There is no reason currently to replicate expiration commands across site.
> Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks.
> However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. Also this requires having system clocks somewhat close in time, which can be even more problematic with clusters in disparate locations. We need to document that this doesn't work as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10650) Expiration should not be replicated cross site
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10650?page=com.atlassian.jira.plugin... ]
Work on ISPN-10650 started by Will Burns.
-----------------------------------------
> Expiration should not be replicated cross site
> ----------------------------------------------
>
> Key: ISPN-10650
> URL: https://issues.jboss.org/browse/ISPN-10650
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Expiration
> Affects Versions: 9.4.16.Final, 10.0.0.CR2
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> There is no reason currently to replicate expiration commands across site.
> Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks.
> However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. Also this requires having system clocks somewhat close in time, which can be even more problematic with clusters in disparate locations. We need to document that this doesn't work as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10650) Expiration should not be replicated cross site
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10650?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-10650:
------------------------------
Description:
There is no reason currently to replicate expiration commands across site.
Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks.
However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. Also this requires having system clocks somewhat close in time, which can be even more problematic with clusters in disparate locations. We need to document that this doesn't work as well.
was:
There is no reason currently to replicate expiration commands across site.
Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks.
However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. We need to document that this doesn't work as well.
> Expiration should not be replicated cross site
> ----------------------------------------------
>
> Key: ISPN-10650
> URL: https://issues.jboss.org/browse/ISPN-10650
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Expiration
> Affects Versions: 9.4.16.Final, 10.0.0.CR2
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> There is no reason currently to replicate expiration commands across site.
> Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks.
> However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. Also this requires having system clocks somewhat close in time, which can be even more problematic with clusters in disparate locations. We need to document that this doesn't work as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10650) Expiration should not be replicated cross site
by Will Burns (Jira)
Will Burns created ISPN-10650:
---------------------------------
Summary: Expiration should not be replicated cross site
Key: ISPN-10650
URL: https://issues.jboss.org/browse/ISPN-10650
Project: Infinispan
Issue Type: Bug
Components: Cross-Site Replication, Expiration
Affects Versions: 10.0.0.CR2, 9.4.16.Final
Reporter: Will Burns
Assignee: Will Burns
There is no reason currently to replicate expiration commands across site.
Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks.
However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. We need to document that this doesn't work as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10645) Configured eviction bases on COUNT will unexpected start eviction to early and might evict until the cache is empty
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10645?page=com.atlassian.jira.plugin... ]
Will Burns commented on ISPN-10645:
-----------------------------------
I have been unable to reproduce this yet. I have tried with upstream, 9.4.x, and patches JDG 7.3.2 from 7.3.1. Every time the reproducer says there are 120 entries in the cache. I must be missing a step or something.
> Configured eviction bases on COUNT will unexpected start eviction to early and might evict until the cache is empty
> -------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10645
> URL: https://issues.jboss.org/browse/ISPN-10645
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.CR2
> Reporter: Wolf-Dieter Fink
> Assignee: Will Burns
> Priority: Major
>
> If a cache is populated and configured with eviction and maybe expiration the eviction will start earlier than expected and the size count will go down to more or less 0.
> Assume the cache is configured like this
> <distributed-cache name="ExpirationCache">
> <memory>
> <binary eviction="COUNT" size="120"/>
> </memory>
> <expiration lifespan="60000" interval="-1"/>
> </distributed-cache>
> The client is simple and add a new entry every second to keep the monitoring simple
> minute 1 - entries are added up to ~59 without eviction
> minute 2 - entries are added but the cache.size() is still 59
> CLI check attribute number_of_entries and evictions for the cache
> shows the same size and no eviction
> minute 3 - continue adding, cache.size()==59 but
> CLI shows the same size and increasing evictions
> minute 4 - still adding but size() decrease as well as CLI n-o-e and evictions grow
> The fact is that having less than 120 entries in the cache is unexpected as well as remove more entries after a time.
> The issue remain for
> <off-heap> and <object> with object count.
> as well as without exiration element or configured with interval - here the entries are expiring but eviction will have effects as well and drop the cache content unexpected.
> So it seems not releated to expiration at all
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10343) LocalCacheStateTransferTest random failures
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10343?page=com.atlassian.jira.plugin... ]
Ryan Emerson resolved ISPN-10343.
---------------------------------
Resolution: Done
> LocalCacheStateTransferTest random failures
> -------------------------------------------
>
> Key: ISPN-10343
> URL: https://issues.jboss.org/browse/ISPN-10343
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.CR3
>
> Attachments: master_20190622-0130_LocalCacheStateTransferTest-infinispan-core.log.gz, master_20190622-0130_threaddump-org_infinispan_xsite_statetransfer_LocalCacheStateTransferTest_testStateTransferWithClusterIdle-2019-06-22-28963.log
>
>
> NodeA starts xsite state transfer before the bridge cluster view is updated, and the push start command is dropped without reaching NodeB. Then NodeA sends a cancel command which does reach NodeB, but before NodeB updates its bridge cluster view, so the response is dropped, and NodeA waits for the response for 20 mins (if the JVM wasn't killed).
> {noformat}
> 01:40:54,271 INFO (testng-Test:[]) [TestSuiteProgress] Test starting: org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.testStateTransferWithClusterIdle
> 01:40:54,274 INFO (testng-Test:[]) [CLUSTER] [Context=Test][Context=Test-NodeA-48836] ISPN100005: Site 'NYC-2' is online.
> 01:40:54,277 TRACE (testng-Test:[]) [JGroupsTransport] Test-NodeA-48836 sending backup request 2 to SiteMaster(NYC-2): XSiteStateTransferControlCommand{control=START_RECEIVE, siteName='null', statusOk=false, cacheName='Test'}
> 01:40:54,277 ERROR (testng-Test:[]) [TEST_RELAY2] Test-NodeA-48836: no route to NYC-2: dropping message
> 01:40:54,313 TRACE (jgroups-5,bridge-org.infinispan.xsite.statetransfer.Test,_Test-NodeA-48836:LON-1:[]) [TEST_RELAY2] [Relayer _Test-NodeA-48836:LON-1] view: [_Test-NodeA-48836:LON-1|1] (2) [_Test-NodeA-48836:LON-1, _Test-NodeB-37463:NYC-2]
> 01:40:54,313 TRACE (jgroups-5,bridge-org.infinispan.xsite.statetransfer.Test,_Test-NodeA-48836:LON-1:[]) [JGroupsTransport] Sites view changed: up [NYC-2], down [], new view is [NYC-2, LON-1]
> 01:40:54,347 TRACE (testng-Test:[]) [JGroupsBackupResponse] Communication error with site NYC-2
> org.infinispan.remoting.transport.jgroups.SuspectException: ISPN000400: Node null was suspected
> at org.infinispan.remoting.transport.ResponseCollectors.remoteNodeSuspected(ResponseCollectors.java:34) ~[classes/:?]
> at org.infinispan.remoting.transport.impl.SingleResponseCollector.targetNotFound(SingleResponseCollector.java:31) ~[classes/:?]
> at org.infinispan.remoting.transport.impl.SingleResponseCollector.targetNotFound(SingleResponseCollector.java:17) ~[classes/:?]
> at org.infinispan.remoting.transport.ValidSingleResponseCollector.addResponse(ValidSingleResponseCollector.java:23) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.SingleSiteRequest.receiveResponse(SingleSiteRequest.java:50) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.SingleSiteRequest.sitesUnreachable(SingleSiteRequest.java:68) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$siteUnreachable$7(JGroupsTransport.java:1229) ~[classes/:?]
> at org.infinispan.remoting.transport.impl.RequestRepository.lambda$forEach$0(RequestRepository.java:60) ~[classes/:?]
> at java.util.concurrent.ConcurrentHashMap.forEach(ConcurrentHashMap.java:1603) ~[?:?]
> at org.infinispan.remoting.transport.impl.RequestRepository.forEach(RequestRepository.java:60) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.siteUnreachable(JGroupsTransport.java:1227) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$200(JGroupsTransport.java:130) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.up(JGroupsTransport.java:1446) ~[classes/:?]
> at org.jgroups.JChannel.up(JChannel.java:756) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:914) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.relay.RELAY2.handleMessage(RELAY2.java:533) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> Suppressed: org.infinispan.util.logging.TraceException
> at org.infinispan.remoting.transport.jgroups.JGroupsBackupResponse.waitForBackupToFinish(JGroupsBackupResponse.java:93) [classes/:?]
> at org.infinispan.remoting.transport.RetryOnFailureXSiteCommand.execute(RetryOnFailureXSiteCommand.java:64) [classes/:?]
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.controlStateTransferOnRemoteSite(XSiteStateTransferManagerImpl.java:343) [classes/:?]
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.startPushState(XSiteStateTransferManagerImpl.java:136) [classes/:?]
> at org.infinispan.xsite.XSiteAdminOperations.pushState(XSiteAdminOperations.java:276) [classes/:?]
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.startStateTransfer(LocalCacheStateTransferTest.java:99) [test-classes/:?]
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.testStateTransferWithClusterIdle(LocalCacheStateTransferTest.java:53) [test-classes/:?]
> ...
> 01:40:54,348 TRACE (testng-Test:[]) [JGroupsTransport] Test-NodeA-48836 sending backup request 4 to SiteMaster(NYC-2): XSiteStateTransferControlCommand{control=FINISH_RECEIVE, siteName='null', statusOk=false, cacheName='Test'}
> 01:40:54,348 TRACE (testng-Test:[]) [TEST_RELAY2] routing message to SiteMaster(NYC-2) via _Test-NodeB-37463:NYC-2
> 01:40:54,349 DEBUG (remote-thread-Test-NodeB-p37359-t2:[]) [XSiteStateConsumerImpl] Ending state transfer from LON-1
> 01:40:54,349 TRACE (remote-thread-Test-NodeB-p37359-t2:[]) [JGroupsTransport] Test-NodeB-37463 sending response for request 4 to Test-NodeA-48836:LON-1: SuccessfulResponse(null)
> 01:40:54,349 ERROR (remote-thread-Test-NodeB-p37359-t2:[]) [TEST_RELAY2] Test-NodeB-37463: no route to LON-1: dropping message
> 01:40:54,350 TRACE (jgroups-6,Test-NodeB-37463:[]) [TEST_RELAY2] [Relayer _Test-NodeB-37463:NYC-2] view: [_Test-NodeA-48836:LON-1|1] (2) [_Test-NodeA-48836:LON-1, _Test-NodeB-37463:NYC-2]
> 01:40:54,350 TRACE (jgroups-6,Test-NodeB-37463:[]) [JGroupsTransport] Sites view changed: up [NYC-2, LON-1], down [], new view is [NYC-2, LON-1]
> ... 5 mins later ...
> [ERROR] Test org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.testStateTransferWithClusterIdle has been running for more than 300 seconds. Interrupting the test thread and dumping threads of the test suite process and its children.
> "testng-LocalCacheStateTransferTest" #17 prio=5 os_prio=0 cpu=26949.68ms elapsed=898.86s tid=0x00007f527d399800 nid=0x7147 waiting on condition [0x00007f5203cfb000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base(a)11.0.3/Native Method)
> - parking to wait for <0x00000000c8300010> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.3/LockSupport.java:234)
> at java.util.concurrent.CompletableFuture$Signaller.block(java.base@11.0.3/CompletableFuture.java:1798)
> at java.util.concurrent.ForkJoinPool.managedBlock(java.base@11.0.3/ForkJoinPool.java:3128)
> at java.util.concurrent.CompletableFuture.timedGet(java.base@11.0.3/CompletableFuture.java:1868)
> at java.util.concurrent.CompletableFuture.get(java.base@11.0.3/CompletableFuture.java:2021)
> at org.infinispan.remoting.transport.jgroups.JGroupsBackupResponse.waitForBackupToFinish(JGroupsBackupResponse.java:87)
> at org.infinispan.remoting.transport.RetryOnFailureXSiteCommand.execute(RetryOnFailureXSiteCommand.java:64)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.controlStateTransferOnRemoteSite(XSiteStateTransferManagerImpl.java:343)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.handleFailure(XSiteStateTransferManagerImpl.java:328)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.startPushState(XSiteStateTransferManagerImpl.java:147)
> at org.infinispan.xsite.XSiteAdminOperations.pushState(XSiteAdminOperations.java:276)
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.startStateTransfer(LocalCacheStateTransferTest.java:99)
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.testStateTransferWithClusterIdle(LocalCacheStateTransferTest.java:53)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months