[JBoss JIRA] (ISPN-1858) clusterName=null causes NPE or hanging at JGroups startup
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-1858:
----------------------------------
Summary: clusterName=null causes NPE or hanging at JGroups startup
Key: ISPN-1858
URL: https://issues.jboss.org/browse/ISPN-1858
Project: Infinispan
Issue Type: Enhancement
Components: Core API
Affects Versions: 5.1.1.FINAL
Reporter: Thomas Fromm
Assignee: Manik Surtani
When configuring the cache programmatic using the GlobalConfigurationBuilder and setting the clustername to null,
causes JGroupsTransport to hang at startup or creating NPE, when JMX is enabled.
e.g.:
Caused by: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:236)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:875)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:630)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:619)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:523)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:200)
... 32 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:234)
... 37 more
Caused by: org.infinispan.CacheException: Channel connected, but unable to register MBeans
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:195)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:169)
... 42 more
Caused by: java.lang.NullPointerException
at javax.management.ObjectName.quote(ObjectName.java:1855)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:189)
... 43 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (ISPN-1801) Enable virtual nodes in the default configuration
by Mircea Markus (JIRA)
Mircea Markus created ISPN-1801:
-----------------------------------
Summary: Enable virtual nodes in the default configuration
Key: ISPN-1801
URL: https://issues.jboss.org/browse/ISPN-1801
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Affects Versions: 5.1.0.FINAL
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 5.1.1.CR1, 5.1.1.FINAL
ATM the default value for virtualNodes is 1. This means that the wheel-share each node has can be very uneven for small(up to 15 nodes) clusters.
Increasing this value even to a small number(10-30) would significantly improve each node's share of wheel and the chance for a well balanced data distribution over the cluster.
Here are some suggestions from an email from Dan:
<snip>
I've been working on a test to search for an optimal default value here:
https://github.com/danberindei/infinispan/commit/983c0328dc40be9609fcabb7...
I'm measuring both the number of keys for which a node is primary
owner and the number of keys for which it is one of the owners
compared to the ideal distribution (K/N keys on each node). The former
tells us how much more work the node could be expected to do, the
latter how much memory the node is likely to need.
I'm only running 10000 loops, so the max figure is not the absolute
maximum. But it's certainly bigger than the 0.9999 percentile.
The full results are here:
http://fpaste.org/cI1r/
The uniformity of the distribution goes up with the number of virtual
nodes but down with the number of physical nodes. I think we should go
with a default of 48 nodes (or 50 if you prefer decimal). With 32
nodes, there's only a 0.1% chance that a node will hold more than 1.35
* K/N keys, and a 0.1% chance that the node will be primary owner for
more than 1.5 * K/N keys.
We could go higher, but we run against the risk of node addresses
colliding on the hash wheel. According to the formula on the Birthday
Paradox page (http://en.wikipedia.org/wiki/Birthday_problem), we only
need 2072 addresses on our 2^31 hash wheel to get a 0.1% chance of
collision. That means 21 nodes * 96 virtual nodes, 32 nodes * 64
virtual nodes or 43 nodes * 48 virtual nodes.
</snip>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (ISPN-1851) c3p0 and missing JDBC drivers
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-1851:
----------------------------------
Summary: c3p0 and missing JDBC drivers
Key: ISPN-1851
URL: https://issues.jboss.org/browse/ISPN-1851
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 5.1.1.FINAL
Reporter: Thomas Fromm
Assignee: Manik Surtani
Missing drivers can only be recognized when looking at the traces and see there a:
2012-02-07 18:08:30,714 [WARN] com.mchange.v2.c3p0.DriverManagerDataSource - Could not load driverClass oracle.jdbc.OracleDriver
java.lang.ClassNotFoundException: oracle.jdbc.OracleDriver
The caches are started but without working cache loaders.
I would expect an exception during cache start.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (ISPN-1852) If a global component fails to start during cache startup, future getCache calls for that cache will never return
by Dan Berindei (JIRA)
Dan Berindei created ISPN-1852:
----------------------------------
Summary: If a global component fails to start during cache startup, future getCache calls for that cache will never return
Key: ISPN-1852
URL: https://issues.jboss.org/browse/ISPN-1852
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.1.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.1.2.CR1
In DefaultCacheManager, before starting a cache we register a CacheWrapper with the cache name, and subsequent calls to getCache(cacheName) will wait for a countdown latch in the CacheWrapper to confirm that the cache has finished starting.
However, if a global component fails to start, that latch is never opened - so future calls to getCache(cacheName) will block forever.
If startCaches() is used to start multiple caches at once, the global start exception will be on a background thread and the user will only notice that the getCache calls on the main thread never return.
This situation appeared in the hibernate-search test suite, which extended JGroupsTransport to change the cluster name to a unique value on startup. The cluster name is not dynamic in 5.1, so the global component registry failed to start.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (ISPN-1840) Problem on InfinispanConfiguration.findSchemaInputStream() on certain HW configuration
by Damiano Pezzotti (JIRA)
Damiano Pezzotti created ISPN-1840:
--------------------------------------
Summary: Problem on InfinispanConfiguration.findSchemaInputStream() on certain HW configuration
Key: ISPN-1840
URL: https://issues.jboss.org/browse/ISPN-1840
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.1.FINAL
Environment: The problem occurs on my customer test enviroment ()
Reporter: Damiano Pezzotti
Assignee: Manik Surtani
I have a strange problem with infinispan 5.1.x.
On my develompent enviroment (Mac 10.6.x and Linux) the cache works fine.
When I tried to deploy my app on my customers test enviroment (a virtualized linux machine) the cache doesn't start... The JVM is blocked during cache initialization.
I tried to debug infinispan and I found that the init process is blocked on DefaultCacheManager at this line
InputStream schemaInputStream = InfinispanConfiguration.findSchemaInputStream();
If I comment this line ( and the Util.close(schemaInputStream) ) the cache starts successfully.
I see that the findSchemaInputStream() method is deprecated and the schemaInputStream object is never used.
Is it possible to remove these 2 lines of code?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months