September 2017 - infinispan-issues

[JBoss JIRA] (IPROTO-34) Protobuf/Json mapping generates invalid json

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/IPROTO-34?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated IPROTO-34: ------------------------------------ Description: A json containing a string field value with the '\n', when converted to protobuf and back results in invalid json with line breaks (was: A json containing '\n' converted to protobuf and back results in invalid json with line breaks) > Protobuf/Json mapping generates invalid json > -------------------------------------------- > > Key: IPROTO-34 > URL: https://issues.jboss.org/browse/IPROTO-34 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.0.0.Alpha5 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > A json containing a string field value with the '\n', when converted to protobuf and back results in invalid json with line breaks -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8357) Avoid index="LOCAL" in default configurations

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8357?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-8357: ---------------------------------------- This could be causing exceptions like this to appear: {code} org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=11 returned server error (status=0x85): org.hibernate.search.exception.SearchException: Unknown index referenced : org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363) at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152) at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138) at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60) at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:58) at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:34) at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:268) at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:77) at stream.StationBoardsInjectorVerticle.lambda$startLoading$12(StationBoardsInjectorVerticle.java:90) {code} > Avoid index="LOCAL" in default configurations > --------------------------------------------- > > Key: ISPN-8357 > URL: https://issues.jboss.org/browse/ISPN-8357 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.3.Final, 9.1.1.Final > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > > This option is deprecated and should be changed. > The default server configuration comes with configurations that use this deprecated option. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8357) Avoid index="LOCAL" in default configurations

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-8357: -------------------------------------- Summary: Avoid index="LOCAL" in default configurations Key: ISPN-8357 URL: https://issues.jboss.org/browse/ISPN-8357 Project: Infinispan Issue Type: Bug Components: Embedded Querying Affects Versions: 9.1.1.Final, 9.0.3.Final Reporter: Galder Zamarreño Assignee: Adrian Nistor This option is deprecated and should be changed. The default server configuration comes with configurations that use this deprecated option. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-34) Protobuf/Json mapping generates invalid json

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created IPROTO-34: --------------------------------------- Summary: Protobuf/Json mapping generates invalid json Key: IPROTO-34 URL: https://issues.jboss.org/browse/IPROTO-34 Project: Infinispan ProtoStream Issue Type: Bug Affects Versions: 4.0.0.Alpha5 Reporter: Gustavo Fernandes Line breaks should be converted to '\n' inside string field values, otherwise the json rendered is invalid -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-34) Protobuf/Json mapping generates invalid json

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/IPROTO-34?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned IPROTO-34: --------------------------------------- Assignee: Gustavo Fernandes > Protobuf/Json mapping generates invalid json > -------------------------------------------- > > Key: IPROTO-34 > URL: https://issues.jboss.org/browse/IPROTO-34 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.0.0.Alpha5 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > Line breaks should be converted to '\n' inside string field values, otherwise the json rendered is invalid -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8348) Some methods from cache API do not work properly with off-heap

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8348?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-8348: ------------------------------------ +100 to document that behaviour is undefined if {{!key1.equals(key2)}} but {{Arrays.equals(marshaller.objectToByteBuffer(key1), marshaller.objectToByteBuffer(key2)}}. And not just for off-heap, but for all storage modes. > Some methods from cache API do not work properly with off-heap > -------------------------------------------------------------- > > Key: ISPN-8348 > URL: https://issues.jboss.org/browse/ISPN-8348 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.0.Final > Reporter: Vojtech Juranek > Assignee: William Burns > Fix For: 9.1.2.Final, 9.2.0.Alpha1 > > > Following methods from cache API don't work properly with off-heap: > * {{get()}} returns value even for keys, which are not equal (for keys, which have same content, but {{key#equals()}} returns {{false}}) > * {{keySet()}} - from docs: modifications and changes to the cache will be reflected in the set and vice versa. This is not the case for off-heap. > * {{replaceAll()}} fails with class cast exception (e.g. in case of {{Cache<String,String>}} with {{java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes}}) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7122) JpaStore Performance is Poor

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-7122?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-7122: --------------------------------------- Hi [~tuomas_kiviaho], the second level cache stores the SQL results and not the materialized objects so that would be safe. Be careful with what you mean by "detach" ? The mapping configuration are allowed to control settings such as cascading for eviction, so evicting one object might still leak some of its related objects. The only safe operation is to {{clear}} the {{Session}} (or {{EntityManager}}), or close it. P.S. don't worry about the use of deprecated criteria queries. That's just a warning from the Hibernate ORM team that this API will get removed in the next major version, but it's still working fine. > JpaStore Performance is Poor > ---------------------------- > > Key: ISPN-7122 > URL: https://issues.jboss.org/browse/ISPN-7122 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.4.Final > Reporter: Dan Siviter > Assignee: Ryan Emerson > > When using the {{JpaStore}} it load's IDs, then iterates around the result and manually getting the record. This means for large datasets the performance is really poor. There is a comment in the code regarding this, but in it's current state it effectively makes it unusable. > As an example with a dataset of 12,600 records using a a generic but customised JPA: > * Bulk load: 977ms, > * {{JpaStore}}: 137,906ms > > Increase: 14,015% > Obviously paralleling the call or another DB might be quicker, but not much! > Would it possible to have some level of chunking/batching of the load? IMO this would be a suitable compromise. > I'm afraid I can't share the code for my loader, but it is loading a simple entity with no referenced objects, no so no joins. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8104) Implement Ansible Service Broker

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8104?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-8104: -------------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jboss-container-images/jboss-dataservices-image/pull/10 > Implement Ansible Service Broker > -------------------------------- > > Key: ISPN-8104 > URL: https://issues.jboss.org/browse/ISPN-8104 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7122) JpaStore Performance is Poor

by Tuomas Kiviaho (JIRA)

[ https://issues.jboss.org/browse/ISPN-7122?page=com.atlassian.jira.plugin.... ] Tuomas Kiviaho commented on ISPN-7122: -------------------------------------- The bad thing is that the slowness can creep in gradually long after the decision to utilize this cache-store has been made. It seems to me based on what is documented into the codebase that in the feat of JPA eager fetch causing OOME, the fetching of only id's is being applied. Hibernate nowadays admits in it's fetching strategies that eager fetch should be disabled by default and (named) entity graphs/queries should be used instead in contradiction what default fetch types of @ManyToOne and @OneToOne are. The code base seems to be still using now deprecated criteria queries, but allowing different fetching strategies would leave the responsibility of avoiding possible OOME to the configurator. When no named entity graphs/queries have been provided then the default behavior could be what it is currently. [~sannegrinovero] What would happen if the https://issues.jboss.org/browse/ISPN-4538 would be solved by just applying detach right after the entity has been consumed. Would it impact also the possible second level cache. > JpaStore Performance is Poor > ---------------------------- > > Key: ISPN-7122 > URL: https://issues.jboss.org/browse/ISPN-7122 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.4.Final > Reporter: Dan Siviter > Assignee: Ryan Emerson > > When using the {{JpaStore}} it load's IDs, then iterates around the result and manually getting the record. This means for large datasets the performance is really poor. There is a comment in the code regarding this, but in it's current state it effectively makes it unusable. > As an example with a dataset of 12,600 records using a a generic but customised JPA: > * Bulk load: 977ms, > * {{JpaStore}}: 137,906ms > > Increase: 14,015% > Obviously paralleling the call or another DB might be quicker, but not much! > Would it possible to have some level of chunking/batching of the load? IMO this would be a suitable compromise. > I'm afraid I can't share the code for my loader, but it is loading a simple entity with no referenced objects, no so no joins. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8339) Cache Stream response should send asynchronously

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8339?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8339: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Cache Stream response should send asynchronously > ------------------------------------------------ > > Key: ISPN-8339 > URL: https://issues.jboss.org/browse/ISPN-8339 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Alpha1 > > > When a cache stream completes a request it sends that back to the requestor. Currently this is using RpcManager.invokeRemotely such as [1]. This is causing the remote nodes to use a remote thread to wait for the response to process. We should instead send this asynchronously so we don't have to keep the remote thread used. This can cause exhaustion if you have too many requests since these responses are also processed on the remote thread pool. > [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2017