May 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant updated ISPN-701: --------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha2 9.0.0.Final Resolution: Done > New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-701 > URL: https://issues.jboss.org/browse/ISPN-701 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Reporter: Trustin Lee > Assignee: Ryan Emerson > Labels: jdbc > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > The current JDBC {{CacheStore}} implementation has the following shortcomings: > * poor support for vendor specific queries (e.g. MySQL's replace into) > * complex configuration is required to support the key types that cannot be converted to a String easily. > To address this issue: > * Introduce a single unified JDBC {{CacheStore}} implementation. > * Support an arbitrary key type as long as it can be serialized via {{Marshaller}}. > * Support both text and binary key. > * Encode the binary key into a text key using an efficient text encoding if the target database doesn't support binary key column. > * Provide much more flexibility in supporting vendor specific extensions. Let the user extend our {{CacheStore}} implementation and override the DB access (no more TableManipulation). > Once implemented, the existing JDBC {{CacheStore}} could be deprecated. > Configuring this would be, for example, {{GenericJdbcCacheStore}} which would have no vendor-specific optimisations, and {{MySqlJdbcCacheStore}} (subclasses {{GenericJdbcCacheStore}}) which would contain MySQL specific optimisations, etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-20) check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-20?page=com.atlassian.jira.plugin.sy... ] Tristan Tarrant updated ISPN-20: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha2 9.0.0.Final Resolution: Done > check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE > --------------------------------------------------------------------------------- > > Key: ISPN-20 > URL: https://issues.jboss.org/browse/ISPN-20 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Transactions > Reporter: Mircea Markus > Assignee: Ryan Emerson > Labels: hackathon > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > Not sure whether the 'outside' locking (MVCC) can't be used so that we won't need locking code within cache stores -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] Jakub Markos commented on ISPN-6580: ------------------------------------ They are disabled in current master. With db0890270 and default standalone.xml, the access log is indeed TRACE logging every operation. But I turned it off, so the regression between 628819461 and db0890270 is not related to excessive logging. > Hotrod performance regressions after ISPN-5342 ISPN-6545 > -------------------------------------------------------- > > Key: ISPN-6580 > URL: https://issues.jboss.org/browse/ISPN-6580 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: William Burns > Attachments: jfr_recordings.zip, pom.xml, Reproducer.java > > > There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... > It is easily reproducable locally with a single server instance, reproducer attached. > The numbers on my machine: > ||Build commit||Puts time||Gets time|| > |dd5501c5e|21|74| > |628819461|26|102| > |db0890270|48|224| > The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-6580: --------------------------------------- We should really disable access logs out of the box > Hotrod performance regressions after ISPN-5342 ISPN-6545 > -------------------------------------------------------- > > Key: ISPN-6580 > URL: https://issues.jboss.org/browse/ISPN-6580 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: William Burns > Attachments: jfr_recordings.zip, pom.xml, Reproducer.java > > > There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... > It is easily reproducable locally with a single server instance, reproducer attached. > The numbers on my machine: > ||Build commit||Puts time||Gets time|| > |dd5501c5e|21|74| > |628819461|26|102| > |db0890270|48|224| > The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-6580: ------------------------------------- Assignee: William Burns > Hotrod performance regressions after ISPN-5342 ISPN-6545 > -------------------------------------------------------- > > Key: ISPN-6580 > URL: https://issues.jboss.org/browse/ISPN-6580 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: William Burns > Attachments: jfr_recordings.zip, pom.xml, Reproducer.java > > > There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... > It is easily reproducable locally with a single server instance, reproducer attached. > The numbers on my machine: > ||Build commit||Puts time||Gets time|| > |dd5501c5e|21|74| > |628819461|26|102| > |db0890270|48|224| > The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by Jakub Markos (JIRA)

Jakub Markos created ISPN-6580: ---------------------------------- Summary: Hotrod performance regressions after ISPN-5342 ISPN-6545 Key: ISPN-6580 URL: https://issues.jboss.org/browse/ISPN-6580 Project: Infinispan Issue Type: Bug Components: Remote Protocols, Server Reporter: Jakub Markos Attachments: jfr_recordings.zip, pom.xml, Reproducer.java There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... It is easily reproducable locally with a single server instance, reproducer attached. The numbers on my machine: ||Build commit||Puts time||Gets time|| |dd5501c5e|21|74| |628819461|26|102| |db0890270|48|224| The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6579) Migrate near cache demo to a separate repo

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6579?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6579: ---------------------------------- Status: Open (was: New) > Migrate near cache demo to a separate repo > ------------------------------------------ > > Key: ISPN-6579 > URL: https://issues.jboss.org/browse/ISPN-6579 > Project: Infinispan > Issue Type: Task > Components: Demos and Tutorials > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > And also remove the jnp-[client|server] dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6579) Migrate near cache demo to a separate repo

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6579?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6579: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4296 > Migrate near cache demo to a separate repo > ------------------------------------------ > > Key: ISPN-6579 > URL: https://issues.jboss.org/browse/ISPN-6579 > Project: Infinispan > Issue Type: Task > Components: Demos and Tutorials > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > And also remove the jnp-[client|server] dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6579) Migrate near cache demo to a separate repo

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-6579: ------------------------------------- Summary: Migrate near cache demo to a separate repo Key: ISPN-6579 URL: https://issues.jboss.org/browse/ISPN-6579 Project: Infinispan Issue Type: Task Components: Demos and Tutorials Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.0.0.Alpha2, 9.0.0.Final And also remove the jnp-[client|server] dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5916) Filtering by cache status in management console doesn't work

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-5916?page=com.atlassian.jira.plugin.... ] Pedro Zapata commented on ISPN-5916: ------------------------------------ There's no property in the model, but a statistic refresh would have to be issued for each cache and update the model before being able to filter. Currently, no cache stats is retrieved and the cache status is not updated. That might involve a large number of DMR requests in the case of many caches being displayed. > Filtering by cache status in management console doesn't work > ------------------------------------------------------------ > > Key: ISPN-5916 > URL: https://issues.jboss.org/browse/ISPN-5916 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Alpha2 > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > > Page: "Caches" tab -> click on certain cache container: list of caches in that container is shown. > On the left side, these are options how to filter the shown caches and you can also filter by cache status - Indexing, Offline, Rebalancing, Split. When I click any of them, nothing happens, it looks like they do nothing since I definitely don't have any cache rebalancing or indexed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2016