[JBoss JIRA] (ISPN-9511) Expired event is not raised when modifying an expired entry
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-9511?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-9511:
-------------------------------------
Actually the above failure is something else. There should be no reason to get a clear event in this test until it shuts down :(
> Expired event is not raised when modifying an expired entry
> -----------------------------------------------------------
>
> Key: ISPN-9511
> URL: https://issues.jboss.org/browse/ISPN-9511
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 9.3.3.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.4.0.Final
>
>
> Due to the old way of implementing remove expired for lifespan, we didn't raise an expired event when writing to an entry. This was mostly to cause circular dependencies. But with the new remove expired max idle changes, this is now possible.
> Without this change listeners can be in an inconsistent state, possibly, as the following could happen:
> 1. Entry is created
> 2. Listener is notified of creation
> 3. Entry expires (no event yet)
> 4. Entry is written to (created)
> 5. Listener is notified of creation.
> In this case there is no intermediate state where the listener thought there was no entry. This also becomes problematic if you are listening only for events that don't include create.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9320) Automatic hot rod client version selection
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9320?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9320:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.0.Final)
> Automatic hot rod client version selection
> ------------------------------------------
>
> Key: ISPN-9320
> URL: https://issues.jboss.org/browse/ISPN-9320
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 10.0.0.Final
>
>
> A HotRod client should be able to automatic detect the server version and downgrade the protocol version if the server is older.
> Older HotRod clients are still able to connect to newer servers.
> It would be helpful if new API functions are rejected with a clear error message that the function is not available if using an old protocol.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9320) Automatic hot rod client version selection
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9320?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant edited comment on ISPN-9320 at 9/17/18 12:18 PM:
-----------------------------------------------------------------
I'd also like to see a decoupling of protocol version from available ops:
* return the recognized ops as a response to PING as a list (e.g. SMTP does this in response to EHLO requests)
* version the ops, e.g. if we make incompatible changes to PUT we introduce PUT2 with dedicated ops
was (Author: nadirx):
I'd also like to see a decoupling of protocol version from available ops:
* return the recognized ops as a response to PING as a list (e.g. SMTP does this in response to EHLO requests)
* version the ops, e.g. if we make incompatible changes to PUT we introduce PUT2 with dedicated ops
But this should really go into Hot Rod 3.
> Automatic hot rod client version selection
> ------------------------------------------
>
> Key: ISPN-9320
> URL: https://issues.jboss.org/browse/ISPN-9320
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 10.0.0.Final
>
>
> A HotRod client should be able to automatic detect the server version and downgrade the protocol version if the server is older.
> Older HotRod clients are still able to connect to newer servers.
> It would be helpful if new API functions are rejected with a clear error message that the function is not available if using an old protocol.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9345) TimeutException involving the org.infinispan.CONFIG cache with IPv6
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9345?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-9345:
------------------------------------
[~stehlik.michal] the error message is a catch-all for any problem where we don't know exactly what happens, sorry about that. But the steps to reproduce are quite specific, and it requires 2 nodes to be started on a machine that defaults to IPv6 without {{-Djava.net.preferIPv4Stack=true}}. I've updated the issue subject to reflect that and to keep the discussion focused.
We don't have a satisfying solution for this yet, because I would like to make debugging this easier. The best option right now is to use {{-Djava.net.preferIPv4Stack=true}}. The next best option is to use IPv6 in your UDP/TCP configuration, especially where you didn't have an explicit address in the configuration and JGroups has an IPv4 default.
But if you only see the timeout when you start more than 1 cache manager at once, I believe you're hitting another problem and you should open a new issue.
> TimeutException involving the org.infinispan.CONFIG cache with IPv6
> -------------------------------------------------------------------
>
> Key: ISPN-9345
> URL: https://issues.jboss.org/browse/ISPN-9345
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Dan Berindei
>
> {noformat}
> Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on jedha-64980
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9345) TimeutException involving the org.infinispan.CONFIG cache with IPv6
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9345?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9345:
-------------------------------
Summary: TimeutException involving the org.infinispan.CONFIG cache with IPv6 (was: TimeutException involving the org.infinispan.CONFIG cache)
> TimeutException involving the org.infinispan.CONFIG cache with IPv6
> -------------------------------------------------------------------
>
> Key: ISPN-9345
> URL: https://issues.jboss.org/browse/ISPN-9345
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Dan Berindei
>
> {noformat}
> Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on jedha-64980
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (HRJS-76) Hot Rod 2.5 protocol support broken
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-76?page=com.atlassian.jira.plugin.sy... ]
Work on HRJS-76 started by Galder Zamarreño.
--------------------------------------------
> Hot Rod 2.5 protocol support broken
> -----------------------------------
>
> Key: HRJS-76
> URL: https://issues.jboss.org/browse/HRJS-76
> Project: Infinispan Javascript client
> Issue Type: Bug
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.6.0
>
>
> Trying to run smoke tests with protocol 2.5 results in failure:
> {code}
> rm -drf tmp-tests.log && node node_modules/jasmine-node/lib/jasmine-node/cli.js spec/infinispan_local_spec.js --captureExceptions
> FFFF.FFFFFFFFFFFFTypeError: Cannot read property 'decodeMedia' of undefined
> at decoderMedia (/Users/g/1/infinispan-js-client/lib/protocols.js:73:43)
> at Protocol25.decodeEvent (/Users/g/1/infinispan-js-client/lib/protocols.js:589:28)
> at Socket.onData (/Users/g/1/infinispan-js-client/lib/io.js:121:40)
> at emitOne (events.js:116:13)
> at Socket.emit (events.js:211:7)
> at addChunk (_stream_readable.js:263:12)
> at readableAddChunk (_stream_readable.js:250:11)
> at Socket.Readable.push (_stream_readable.js:208:10)
> at TCP.onread (net.js:597:20)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9511) Expired event is not raised when modifying an expired entry
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-9511?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-9511:
-------------------------------------
This will also fix issues like https://ci.infinispan.org/job/Infinispan/job/PR-6232/17/testReport/junit/...
This is due to the fact that they expect the expiration event to cause an invalidation, but it never comes.
> Expired event is not raised when modifying an expired entry
> -----------------------------------------------------------
>
> Key: ISPN-9511
> URL: https://issues.jboss.org/browse/ISPN-9511
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 9.3.3.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.4.0.Final
>
>
> Due to the old way of implementing remove expired for lifespan, we didn't raise an expired event when writing to an entry. This was mostly to cause circular dependencies. But with the new remove expired max idle changes, this is now possible.
> Without this change listeners can be in an inconsistent state, possibly, as the following could happen:
> 1. Entry is created
> 2. Listener is notified of creation
> 3. Entry expires (no event yet)
> 4. Entry is written to (created)
> 5. Listener is notified of creation.
> In this case there is no intermediate state where the listener thought there was no entry. This also becomes problematic if you are listening only for events that don't include create.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9518) Create a Infinispan JDBC Driver
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/ISPN-9518?page=com.atlassian.jira.plugin.... ]
Ramesh Reddy commented on ISPN-9518:
------------------------------------
If anyone can create an empty git repo on Infinispan organization, and give me rights to the repo, I can start with check in of the initial code.
> Create a Infinispan JDBC Driver
> -------------------------------
>
> Key: ISPN-9518
> URL: https://issues.jboss.org/browse/ISPN-9518
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Querying
> Reporter: Ramesh Reddy
> Labels: jdbc, teiid
>
> Build JDBC driver for Infinispan Cache using Teiid technology. There is currently already an Infinispan translator available in Teiid, this implementation needs to make use of that, but deliverable should be a single JAR that can be loaded as JDBC driver in any third party client applications.
> My current implementation resides at https://github.com/rareddy/infinispan-jdbc
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months