[JBoss JIRA] (ISPN-12332) Pessimistic tx write on a non owner should consolidate LockControlCommand and ClusteredGetCommand
by Will Burns (Jira)
Will Burns created ISPN-12332:
---------------------------------
Summary: Pessimistic tx write on a non owner should consolidate LockControlCommand and ClusteredGetCommand
Key: ISPN-12332
URL: https://issues.redhat.com/browse/ISPN-12332
Project: Infinispan
Issue Type: Enhancement
Components: Transactions
Affects Versions: 10.0.0.Final
Reporter: Will Burns
Today when a write occurs in a pessimistic transaction it must first lock the key for that entry. If the node is not an owner it may also retrieve the previous value, given Flag configuration. This leads to sending 2 requests when we could instead consoldiate this to do a single ClusteredGetCommand with the FORCE_WRITE_FLAG which would both retrieve the value and lock they key.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (ISPN-12331) ContinuousQuery instance should be the same if Search.continuousQuery() is used
by Wolf-Dieter Fink (Jira)
[ https://issues.redhat.com/browse/ISPN-12331?page=com.atlassian.jira.plugi... ]
Wolf-Dieter Fink commented on ISPN-12331:
-----------------------------------------
Also the javadoc should have a statement to clarify it
> ContinuousQuery instance should be the same if Search.continuousQuery() is used
> -------------------------------------------------------------------------------
>
> Key: ISPN-12331
> URL: https://issues.redhat.com/browse/ISPN-12331
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying, Remote Querying
> Affects Versions: 8.1.0.Final
> Reporter: Wolf-Dieter Fink
> Priority: Major
> Labels: query
>
> The static method Search.continuousQuery(<CacheName>) will always return a NEW ContinuousQuery instance, to handle such it should return alway the same instance as this would enhance the handling
> From a user perspective it is unexpected as it is possible to use Search.continuousQuery().register... and this is working but .unregister* will not find any of the registered Listeners because of the different instance.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (IPROTO-155) FileDescriptors use too much memory
by Dan Berindei (Jira)
Dan Berindei created IPROTO-155:
-----------------------------------
Summary: FileDescriptors use too much memory
Key: IPROTO-155
URL: https://issues.redhat.com/browse/IPROTO-155
Project: Infinispan ProtoStream
Issue Type: Bug
Affects Versions: 4.3.3.Final
Reporter: Dan Berindei
E.g. a single {{persistence.counters.proto}} {{FileDescriptor}} instance uses 967KB.
I'm not sure if the field documentation is useful for anything after the annotations have been parsed, but it is kept in memory, and in a hotrod-client test each {{DefaultCacheManager}} instance seem to need 3 instances of the string {{There is no native byte type in protobuf so it is mapped to int32.}} from the {{WrappedMessage.wrappedByte}} documentation.
Many lists are {{LinkedList}} instances, even though a {{LinkedList}} with 3 elements uses more memory than an {{ArrayList}} with 10 elements. Some lists are also wrapped in {{Collections$UnmodifiableRandomAccessList}} twice.
{{FileDescriptor}} {{HashMap}} fields ({{extendDescriptors}}, {{dependants}}) are never queried by key.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (ISPN-12331) ContinuousQuery instance should be the same if Search.continuousQuery() is used
by Wolf-Dieter Fink (Jira)
Wolf-Dieter Fink created ISPN-12331:
---------------------------------------
Summary: ContinuousQuery instance should be the same if Search.continuousQuery() is used
Key: ISPN-12331
URL: https://issues.redhat.com/browse/ISPN-12331
Project: Infinispan
Issue Type: Enhancement
Components: Embedded Querying, Remote Querying
Affects Versions: 8.1.0.Final
Reporter: Wolf-Dieter Fink
The static method Search.continuousQuery(<CacheName>) will always return a NEW ContinuousQuery instance, to handle such it should return alway the same instance as this would enhance the handling
From a user perspective it is unexpected as it is possible to use Search.continuousQuery().register... and this is working but .unregister* will not find any of the registered Listeners because of the different instance.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years