[JBoss JIRA] Created: (ISPN-800) Infinispan inside OSGI
by luca stancapiano (JIRA)
Infinispan inside OSGI
----------------------
Key: ISPN-800
URL: https://jira.jboss.org/browse/ISPN-800
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Affects Versions: 4.2.0.CR1
Reporter: luca stancapiano
Assignee: Manik Surtani
We need to import infinispan inside a OSGI repository. Tests are made with Felix.
I added the configuration to use infinispan inside a osgi repository. We need to ignore all listed dependencies. With this configuration we can install infinispan-core.jar inside OSGI. Its achievement will be as a base installation here: https://github.com/flashboss/infinispan
I added the Import-Package because you are forced to put manually in Felix all dependencies as jgroups, jboss marshalling, jcip, all apache commons. I've seen infinispan core working by default without all those libraries, so I think the same achievement should be replicated in OSGI.
Inside the Import-Package tag I excluded those libraries so Infinispan core can be started in default mode without errors. If we want use the replication in OSGI, it is enough add manually the other packages (jgroups.jar etc etc)
Actually the core bundle can be installed. But to be used it needs theese projects be installed as osgi bundles:
jboss transaction api 1.0.1.GA
(It is not yet a OSGI bundle. Waiting for a response to: https://jira.jboss.org/browse/JBEE-67)
jgroups 2.10.1.GA
(fixed in jgroups 1.12)
river 1.2.3.GA
marshalling-api 1.2.3.GA
jboss common core 2.2.14.GA
jboss logging spi 2.0.5.GA
rhq plugin annotations 1.4.0.B01
i18nlog 1.0.9
log4j 1.2.16
We should make sure proper 'Import-Package' property is specified in the MANIFEST.MF so that:
1- it fails to load obviously when there's any missing bundles that are essential in using the very core functionality of Infinispan.
2 - it does not fail due to the dependency that is not really essential.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (ISPN-1195) Rehashing and state transfer to use digesting
by Manik Surtani (JIRA)
Rehashing and state transfer to use digesting
---------------------------------------------
Key: ISPN-1195
URL: https://issues.jboss.org/browse/ISPN-1195
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache, State transfer
Affects Versions: 5.0.0.FINAL
Reporter: Manik Surtani
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.1.0.BETA1, 5.1.0.Final
Rather than pushing entire state to new joiners, a mechanism of digests should be used to minimise network transfers. For example, Merkle trees can be used to determine which entries are out of date and need pushing, in the case of nodes that persist to a local cache store, and is restarted but still has access to some state on disk.
This would require versioned entries though.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (ISPN-375) Enable Hot Rod clients to start transactions
by Galder Zamarreno (JIRA)
Enable Hot Rod clients to start transactions
--------------------------------------------
Key: ISPN-375
URL: https://jira.jboss.org/jira/browse/ISPN-375
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 5.1.0.BETA1, 5.1.0.Final
It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (ISPN-1336) Infinispan core fails to build with JDK 7
by Radoslav Husar (JIRA)
Infinispan core fails to build with JDK 7
-----------------------------------------
Key: ISPN-1336
URL: https://issues.jboss.org/browse/ISPN-1336
Project: Infinispan
Issue Type: Bug
Components: Build process
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.7.0, vendor: Oracle Corporation
Reporter: Radoslav Husar
Assignee: Manik Surtani
"Or is it just me?"
{code}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project infinispan-core: Compilation failure
[ERROR] error: Cannot read org.infinispan.util.logging package files, cause : java.io.FileNotFoundException: org.infinispan.util.logging/Log
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project infinispan-core: Compilation failure
error: Cannot read org.infinispan.util.logging package files, cause : java.io.FileNotFoundException: org.infinispan.util.logging/Log
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
error: Cannot read org.infinispan.util.logging package files, cause : java.io.FileNotFoundException: org.infinispan.util.logging/Log
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
{code}
Trying on master, last commit was
commit e81e8a63fd68b85bc20b3304d62cc5fdcd75f327
Author: Galder Zamarreño
Date: Fri Aug 12 13:35:50 2011 +0200
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (ISPN-1235) Per class(es) logging settings in testsuite
by Galder Zamarreño (JIRA)
Per class(es) logging settings in testsuite
-------------------------------------------
Key: ISPN-1235
URL: https://issues.jboss.org/browse/ISPN-1235
Project: Infinispan
Issue Type: Enhancement
Components: Test Suite
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.2.0.Final
Just brainstorming:
It'd be very useful to have a way to run the testsuite with normal logging settings but have the ability to define one or more test classes as having TRACE on x.y.z. This could be useful for those elusive failures that only happen when the testsuite runs! Clearly, it'd need some programmatic magic to enable/disable the logging at runtime, but there's some benefit to all this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
by Manik Surtani (JIRA)
ManagedConnectionPool doesn't work in a transactional context
-------------------------------------------------------------
Key: ISPN-586
URL: https://jira.jboss.org/browse/ISPN-586
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores, Transactions
Affects Versions: 4.1.0.CR2
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 4.1.0.CR3
>From the reporter:
"Anyways, what seems to be the real problem is that all the things that need to be persisted are saved in memory and then when the transaction is completing (either in prepare or commit phase) the loader attempts to get a connection from the datasource. Apparently this is illegal and throws an exception which is what causes the HeuristicMixedException further up the chain.
This only fails when using a ManagedConnectionFactory. If I swap out a PooledConnectionFactory it works fine. I presume the managed version fails because it returns the same connection that is part of the active transaction for that thread and you can't perform new operations on that connection once the transaction is already in prepare or commit. This feels like a bit of a design flaw to me... I didn't see an obvious fix."
This possibly has to do with the AbstractCacheStore doing the following in prepare():
"
public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException {
if (isOnePhase) {
applyModifications(mods);
} else {
transactions.put(tx, mods);
}
}
"
and later during commit actually writing the changes to the store. This generic, "abstract" behaviour is intended for non-transactional data stores (such as a filesystem). Behaviour should be different when it comes to transactional data stores.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months