June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3146) PrepareCommand triggers RollbackCommand in TxInterceptor if the commit arrives at the same time

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3146?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3146: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > PrepareCommand triggers RollbackCommand in TxInterceptor if the commit arrives at the same time > ----------------------------------------------------------------------------------------------- > > Key: ISPN-3146 > URL: https://issues.jboss.org/browse/ISPN-3146 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Beta2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 5.3.0.Final > > > Total Order only! > When the CommitCommand arrives, it marks the transaction as completed. In TxInterceptor, if the transaction is completed, a RollbackCommand is triggered. Total Order already handles this case and the RollbackCommand will create inconsistencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2786) ThreadLocal memory leak in Tomcat

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2786?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2786: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ThreadLocal memory leak in Tomcat > --------------------------------- > > Key: ISPN-2786 > URL: https://issues.jboss.org/browse/ISPN-2786 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Transactions > Affects Versions: 5.1.8.Final > Reporter: Johann Burkard > Assignee: Galder Zamarreño > Labels: leak, local, memory, thread, threadlocal > Fix For: 5.3.0.Final > > > Just started an app using Infinispan 5.1.8.Final on Tomcat and got a few ThreadLocal problems during un-deployment: > (Shortened) > {code} > key=org.jboss.marshalling.UTFUtils.BytesHolder > value=org.jboss.marshalling.UTFUtils$BytesHolder@697a1686 > key=java.lang.ThreadLocal@36ed5ba6 > value=org.infinispan.context.SingleKeyNonTxInvocationContext{flags=null} > key=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1@75f10df7 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller.PerThreadInstanceHolder > {code} > I do call {{DefaultCacheManager#shutdown()}} during un-deployment. :) > Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2669) Add a Active-Passive Failover Strategy for Hot Rod client

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2669?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2669. --------------------------------- Resolution: Out of Date the functionality requested here is the default one starting with 5.2 > Add a Active-Passive Failover Strategy for Hot Rod client > --------------------------------------------------------- > > Key: ISPN-2669 > URL: https://issues.jboss.org/browse/ISPN-2669 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Ray Tsang > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > Currently HotRod client has only Round Robin request balancing strategy. There may be use cases where user needs to do an active-passive setup where all requests to go primary active node and only fallback to passive node when active is down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3153) REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3153?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3153: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1867 > REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3153 > URL: https://issues.jboss.org/browse/ISPN-3153 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > When an entry is stored via HotRod an embedded cache, and later retrieved via REST,the Last-modified header looks like this: > Last Modified: null > Another observation is that when the entry is stored via REST and retrieved via REST again, the Last-modified header is: > Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > This is obviously wrong and this was working correctly with JDG-server which contained ISPN 5.2. OTOH, when I set "timeToLiveSeconds" header on the request, the Last-modified is properly set (not to 1970). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3154) REST endpoint does not return correct Expiry header for GET opeartion when the key is stored via HotRod or embedded cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3154?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3154: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1867 > REST endpoint does not return correct Expiry header for GET opeartion when the key is stored via HotRod or embedded cache > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3154 > URL: https://issues.jboss.org/browse/ISPN-3154 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > The expiry header is not sent back at all if the entry was stored via HotRod or Embedded cache. It is sent back correctly only if the entry was stored via REST with timToLiveSeconds set. > The following test fails if added to EmbeddedRestHotRodTest class: > {code:java} > public void testHotRodEmbeddedPutRestGetExpiry() throws Exception { > final String key = "8"; > final String key2 = "9"; > // 1. Put with HotRod > assertEquals(null, cacheFactory.getHotRodCache().put(key, "v1", 5, TimeUnit.SECONDS)); > // 2. Put with Embedded > assertEquals(null, cacheFactory.getEmbeddedCache().put(key2, "v2", 5, TimeUnit.SECONDS)); > // 3. Get with REST key > HttpMethod get1 = new GetMethod(cacheFactory.getRestUrl() + "/" + key); > cacheFactory.getRestClient().executeMethod(get1); > assertEquals(HttpServletResponse.SC_OK, get1.getStatusCode()); > assertNotNull(get1.getResponseHeader("Expires")); > //^^^fails here - returns null > // 4. Get with REST key2 > HttpMethod get2 = new GetMethod(cacheFactory.getRestUrl() + "/" + key2); > cacheFactory.getRestClient().executeMethod(get2); > assertEquals(HttpServletResponse.SC_OK, get2.getStatusCode()); > assertNotNull(get2.getResponseHeader("Expires")); > //^^^fails here - returns null > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3153) REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3153?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3153: ---------------------------------------- This last-modified issue could be better defined in next Infinispan version, maybe using the REST metadata extension to really store the last time that cache entry is modified. That'd be a proper solution. I'd suggest you create a separate jira for that and mark it for 6.0 (you can assign it to me). > REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3153 > URL: https://issues.jboss.org/browse/ISPN-3153 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > When an entry is stored via HotRod an embedded cache, and later retrieved via REST,the Last-modified header looks like this: > Last Modified: null > Another observation is that when the entry is stored via REST and retrieved via REST again, the Last-modified header is: > Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > This is obviously wrong and this was working correctly with JDG-server which contained ISPN 5.2. OTOH, when I set "timeToLiveSeconds" header on the request, the Last-modified is properly set (not to 1970). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3153) REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3153?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3153: ---------------------------------------- Since immortal entries never die, we don't track creation time for them. We don't wanna be doing that either cos it takes valuable space that's might only be relevant for REST. In fact, we don't have anything that maps directly to last-modified per se. For transient entries, we track when the entry was last used (read or write) and for mortal entries, we track the creation time, which is not necessarily last modified time. Last-modified returns the expected value only when timeToLiveSeconds has been set and we're tracking creation time (mortal entry). > REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3153 > URL: https://issues.jboss.org/browse/ISPN-3153 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > When an entry is stored via HotRod an embedded cache, and later retrieved via REST,the Last-modified header looks like this: > Last Modified: null > Another observation is that when the entry is stored via REST and retrieved via REST again, the Last-modified header is: > Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > This is obviously wrong and this was working correctly with JDG-server which contained ISPN 5.2. OTOH, when I set "timeToLiveSeconds" header on the request, the Last-modified is properly set (not to 1970). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3179) The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3179?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3179: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/110 > The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one > ---------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3179 > URL: https://issues.jboss.org/browse/ISPN-3179 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Martin Gencur > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > Attachments: standalone-compatibility-mode.xml > > > Even if I use the following in the endpoint subsustem, the server complains that the memcachedCache is missing during startup: > {code:xml} > <memcached-connector socket-binding="memcached" cache-container="local" cache="default"/> > {code} > {code} > JBAS014775: New missing/unsatisfied dependencies: > service jboss.infinispan.local.memcachedCache (missing) dependents: [service jboss.endpoint.memcached.memcached-connector] > 11:08:19,058 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management > 11:08:19,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990 > 11:08:19,059 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started (with errors) in 2973ms - Started 88 of 124 services (1 services failed or missing dependencies, 35 services are passive or on-demand) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3179) The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3179?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3179: -------------------------------- Attachment: standalone-compatibility-mode.xml A configuration file used to reproduce the bug > The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one > ---------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3179 > URL: https://issues.jboss.org/browse/ISPN-3179 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Martin Gencur > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > Attachments: standalone-compatibility-mode.xml > > > Even if I use the following in the endpoint subsustem, the server complains that the memcachedCache is missing during startup: > {code:xml} > <memcached-connector socket-binding="memcached" cache-container="local" cache="default"/> > {code} > {code} > JBAS014775: New missing/unsatisfied dependencies: > service jboss.infinispan.local.memcachedCache (missing) dependents: [service jboss.endpoint.memcached.memcached-connector] > 11:08:19,058 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management > 11:08:19,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990 > 11:08:19,059 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started (with errors) in 2973ms - Started 88 of 124 services (1 services failed or missing dependencies, 35 services are passive or on-demand) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3179) The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one

by Martin Gencur (JIRA)

Martin Gencur created ISPN-3179: ----------------------------------- Summary: The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one Key: ISPN-3179 URL: https://issues.jboss.org/browse/ISPN-3179 Project: Infinispan Issue Type: Bug Components: Server Reporter: Martin Gencur Assignee: Tristan Tarrant Fix For: 5.3.0.Final Even if I use the following in the endpoint subsustem, the server complains that the memcachedCache is missing during startup: {code:xml} <memcached-connector socket-binding="memcached" cache-container="local" cache="default"/> {code} {code} JBAS014775: New missing/unsatisfied dependencies: service jboss.infinispan.local.memcachedCache (missing) dependents: [service jboss.endpoint.memcached.memcached-connector] 11:08:19,058 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management 11:08:19,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990 11:08:19,059 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started (with errors) in 2973ms - Started 88 of 124 services (1 services failed or missing dependencies, 35 services are passive or on-demand) {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013