May 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1102) Adaptive marshalling buffer size

by Galder Zamarreño (JIRA)

Adaptive marshalling buffer size -------------------------------- Key: ISPN-1102 URL: https://issues.jboss.org/browse/ISPN-1102 Project: Infinispan Issue Type: Enhancement Components: Marshalling Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.CR3 The default marshaller buffer size is 512 which is often too big. We need a more adaptive method that builds more accurate buffers. Dan's suggestion of reservoir sampling could be handy here to get more accurate buffers rather than fixed size. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-1128) TcpTransportFactory should log more of the construction time parameters

by Galder Zamarreño (JIRA)

TcpTransportFactory should log more of the construction time parameters ----------------------------------------------------------------------- Key: ISPN-1128 URL: https://issues.jboss.org/browse/ISPN-1128 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.CR4 TcpTransportFactory should log the configuration parameters used for: - static configured servers - balancer class - tcpNoDelay - socket timeout -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1124) GenericJBossMarshaller.isMarshallable hiding exceptions

by Galder Zamarreño (JIRA)

GenericJBossMarshaller.isMarshallable hiding exceptions ------------------------------------------------------- Key: ISPN-1124 URL: https://issues.jboss.org/browse/ISPN-1124 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 5.0.0.CR2, 4.2.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.CR3, 5.0.0.FINAL If GenericJBossMarshaller.isMarshallable throws any exception while trying to serialize something like it did in http://pastie.org/1917562, then the original exception is lost and not sent back, so it's hard to figure out the root cause of http://pastie.org/1917310 GenericJBossMarshaller.isMarshallable could log any exception but it's probably better if any exception is propagated back it can be sent back as root cause. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1109) Expose JGroups JChannel JMX monitoring

by Mathieu Lachance (JIRA)

Expose JGroups JChannel JMX monitoring -------------------------------------- Key: ISPN-1109 URL: https://issues.jboss.org/browse/ISPN-1109 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Affects Versions: 5.0.0.CR2 Reporter: Mathieu Lachance Assignee: Manik Surtani Priority: Trivial Fix For: 5.0.0.CR3 To use JGroups JChannel JMX monitoring, it's needed to register it to a MBeanServer. Would it be possible to add a configuration key to be able to monitor the cache at a network level ? Here's the actual JGroups documentation to activate JMX monitoring programmatically : http://community.jboss.org/wiki/JMX I guess the correct place to implements the feature should be located in org.infinispan.remoting.transport.jgroups.JGroupsTransport::startJGroupsChannelIfNeeded() and implementation could look like that : protected void startJGroupsChannelIfNeeded() { if (startChannel) { try { channel.connect(configuration.getClusterName()); // my first contribution M Lachance ArrayList servers = MBeanServerFactory.findMBeanServer(null); if (servers == null || servers.size() == 0) { log.log(Logger.Level.WARN, "No Available MBean Servers"); //throw new Exception("No MBeanServers found;" + // "\nJmxTest needs to be run with an MBeanServer present, or inside JDK 5"); } else { MBeanServer server = (MBeanServer) servers.get(0); try { if (server != null) { JmxConfigurator.registerChannel((JChannel) channel, server, "JChannel=" + channel.getChannelName(), "", true); } } catch (Exception e) { log.log(Logger.Level.WARN, "Could not resgister with JMX",e); } } } catch (ChannelException e) { throw new CacheException("Unable to start JGroups Channel", e); } } address = new JGroupsAddress(channel.getAddress()); if (log.isInfoEnabled()) log.localAndPhysicalAddress(getAddress(), getPhysicalAddresses()); } Thanks, -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-1098) REST server should respond with '501 Not Implemented' to the requests with If-Match and similar headers

by Trustin Lee (JIRA)

REST server should respond with '501 Not Implemented' to the requests with If-Match and similar headers ------------------------------------------------------------------------------------------------------- Key: ISPN-1098 URL: https://issues.jboss.org/browse/ISPN-1098 Project: Infinispan Issue Type: Bug Reporter: Trustin Lee Assignee: Manik Surtani Fix For: 5.0.0.CR2, 5.0.0.FINAL If {{If-Match}} or similar header such as {{If-None-Match}} exists in an HTTP request, the REST server must not perform any update unless the condition meets. The current REST server doesn't understand those headers, leading to unexpected updates. If such header exists in the request, the REST server has to respond with '501 Not Implemented'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1126) Exception hidden on Hot Rod client

by Galder Zamarreño (JIRA)

Exception hidden on Hot Rod client ---------------------------------- Key: ISPN-1126 URL: https://issues.jboss.org/browse/ISPN-1126 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.2.BETA1 RetryOnFailureOperation is not logging exceptions that lead to a retry correctlty and this is hiding a crucial exception to clarify JBPAPP-6113. So, here's the log: {code}tcpTransport.log:33670:2011-05-17 11:23:31,119 211988 TRACE [org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation] (Runner - 0:) Exception encountered. Retry 4 out of 40{code} So, what exception was encountered? No idea. Why? Log code is: {code}log.trace(message, i, transportFactory.getTransportCount(), te);{code} Which translates to talking to "void trace(Object message, Object... params);" which won't print the stacktrace as cause. Instead, the log code should be: {code}log.trace(message, te, i, transportFactory.getTransportCount());{code} So that it uses "void trace(Object message, Throwable t, Object... params);" Verify master as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1049) transaction participant failure after prepare causes data inconsistency

by Mircea Markus (JIRA)

transaction participant failure after prepare causes data inconsistency ------------------------------------------------------------------------ Key: ISPN-1049 URL: https://issues.jboss.org/browse/ISPN-1049 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.FINAL cluster {A, B, C, D}, dist, numOwners=3. transaction started on A touches B and C. A prepares then C crashes. When TM commits the user gets a TimeoutException as commit rpc to C failed. The state of the cluster after commit is: tx state successfully applied on A and B, but not on D! The tx should successfully be applied on D as well, as numOwners=3. Or, at least, it should rollback on A and B as well; the point being the cluster should remain in a consistent state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-1125) Log size of stored objects in JDBC CacheLoaders

by Sanne Grinovero (JIRA)

Log size of stored objects in JDBC CacheLoaders ----------------------------------------------- Key: ISPN-1125 URL: https://issues.jboss.org/browse/ISPN-1125 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.0.0.CR3 It's currently pretty hard for people to define proper sizing of the table columns: it would be helpfull to be able to figure it out by looking at the log trends. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-878) update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches

by Mircea Markus (JIRA)

update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches ------------------------------------------------------------------------------- Key: ISPN-878 URL: https://issues.jboss.org/browse/ISPN-878 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.0.0.Final Update http://community.jboss.org/wiki/MultipleTiersofCaches as follows: Feedback from Galder: though, the text in the diagram is very very small and can hardly be read. Maybe you can improve it a little? Feedback from Manik: Also some more feedback: * Spelling: "Multi-Tiered", not "Multiered" * Your diagram probably wants to demonstrate 2 separate tiers, not just 1 client with a clustered server backend. E.g., FE1 --- FE2 --- FE3 =============== BE1 --- BE2 --- BE3 where FE = front-end servers (embedded, maybe an app server running a webapp, with an embedded Infinispan instance as a "near cache") BE = backend, dedicated cache tier, running Hot Rod endpoints FE configured with RemoteCacheStore, and also using Invalidation so that FE's can invalidate each other BE's running DIST for max addressable space + ultimate scalability This way, with the FE's running in INVAL mode, it doesn't matter if the BE's cannot communicate changes back to the FE's, since the FE's wil already know about changes and will invalidate accordingly. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-1080) Investigate and document XA recovery integration with JBossTS

by Mircea Markus (JIRA)

Investigate and document XA recovery integration with JBossTS ------------------------------------------------------------- Key: ISPN-1080 URL: https://issues.jboss.org/browse/ISPN-1080 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.FINAL Reading the JBossTS recovery documentation[1], the recovery process should be able to pull recovery info from ISPN's XAResource implementation by calling .recover(). The issue is that this method needs to be called in the same process where ISPN node leaves and ATM its not possible to invoke it from a different process. This would also be useful for users that want to set up/play with transaction recovery in general. [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2011