[JBoss JIRA] (ISPN-800) Infinispan inside OSGI
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ISPN-800?page=com.atlassian.jira.plugin.s... ]
Brett Meyer commented on ISPN-800:
----------------------------------
[~bibryam], I'm pulling in your changes. Thanks! Here are a couple of questions:
1.) Why was it necessary to make commons a fragment attached to core, rather than ensuring the imports and exports are correct and running commons as a separate bundle? Just curious.
2.) Was allowing BND to automatically define imports causing issues, or do you simply prefer to explicitly list them?
> Infinispan inside OSGI
> ----------------------
>
> Key: ISPN-800
> URL: https://issues.jboss.org/browse/ISPN-800
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Luca Stancapiano
> Assignee: Galder Zamarreño
>
> 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
> We patched it. There is a new OSGI version here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... )
> jgroups 2.10.1.GA
> (it's a osgi bundle since the 3.x version)
> river 1.2.3.GA
> (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/river/pom.xml )
> marshalling-api 1.2.3.GA
> (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/api/pom.xml )
> jboss logging spi 2.0.5.GA
> (added a jira issue in JBLOGGING-51 . It could be fixed in the 2.2.0.CR2 version. Fixed in the 3.x version)
> rhq plugin annotations 1.4.0.B01
> (opened a feature request in https://bugzilla.redhat.com/show_bug.cgi?id=657754 )
> i18nlog 1.0.9
> (sent a patch in https://sourceforge.net/projects/i18nlog . It could become a OSGI bundle in the 1.0.10 version. Waiting for a response. Fixed in 1.15)
> log4j 1.2.16
> (that's ok...it is a osgi bundle ;))
> jcip-annotations 1.0
> (I sent a patch via email to brian(a)briangoetz.com and a post in http://tembrel.blogspot.com. Sent the patch in concurrency-interest(a)cs.oswego.edu too. They responded to me. There is a OSGI version with a different artifact name. I changed the dependency in the pom.xml of the parent project)
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3877) Disk Space optimizations for SingleFileStore
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam commented on ISPN-3877:
-------------------------------------
The forums link contains the patched version of the file.
> Disk Space optimizations for SingleFileStore
> --------------------------------------------
>
> Key: ISPN-3877
> URL: https://issues.jboss.org/browse/ISPN-3877
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
> Reporter: Rajesh Jangam
> Assignee: Mircea Markus
>
> We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
> We tend to create a lot of entries in the store and remove them when not required.
> However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
>
> This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
> We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
> The proposed fix is twofold:
> 1. Truncates the file if there are free fileentries at the end of the data file.
> 2. Coalesces consecutive free fileentries into one so that the probability of finding a free file entry capable enough to contain a newly added key-value pair increases.
> Please review this diff and let us know your opinion
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3877) Disk Space optimizations for SingleFileStore
by Rajesh Jangam (JIRA)
Rajesh Jangam created ISPN-3877:
-----------------------------------
Summary: Disk Space optimizations for SingleFileStore
Key: ISPN-3877
URL: https://issues.jboss.org/browse/ISPN-3877
Project: Infinispan
Issue Type: Patch
Components: Loaders and Stores
Affects Versions: 6.0.0.Final
Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
Reporter: Rajesh Jangam
Assignee: Mircea Markus
We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
We tend to create a lot of entries in the store and remove them when not required.
However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
The proposed fix is twofold:
1. Truncates the file if there are free fileentries at the end of the data file.
2. Coalesces consecutive free fileentries into one so that the probability of finding a free file entry capable enough to contain a newly added key-value pair increases.
Please review this diff and let us know your opinion
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3421) State Transfer can leave keys on < numOwners nodes for transactional caches.
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3421?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3421:
------------------------------------
I think the problem is that A leaves the cluster before it managed to send the CommitCommand to all the replicas. E.g. B receives the commit, but C doesn't. When C sees a new view without A in it, it deletes all transactions that originated on A in {{TransactionTable.cleanupStaleTransactions()}} (at least if recovery is not enabled). [~an1310], did I get it right?
I think fixing this would require changing the CH update that happens after a leave to be done in two phases, just like rebalancing. In the first phase, all the members would install the new CH and would stop accepting commands from the leaver. In the second phase, each member would delete the pending transactions from the leaver, but first it would check with the other owners if they received a commit command. If any owner received the commit, the transaction should be committed, otherwise it should be removed.
Enabling recovery may help a bit, since C won't delete transactions originated from A outright, but on the other hand it doesn't keep backup locks for them - new transactions can update the same data while the originator is down, so we still have inconsistencies.
> State Transfer can leave keys on < numOwners nodes for transactional caches.
> ----------------------------------------------------------------------------
>
> Key: ISPN-3421
> URL: https://issues.jboss.org/browse/ISPN-3421
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Priority: Critical
>
> There's a hole in state transfer mechanism that can occur when a node is leaving the cluster, but it was creating the entries and was only able to replicate the data to some of the nodes.
> The problem occurs when the segment ownership of the node doesn't change after the rebalance. Since state transfer does not request state for keys in which it is already an owner, the cache could be left in a state where a key is resident < numOwners nodes. In addition, this could be any subset of the primary OR backup nodes.
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3876) TcpTransportFactory stores failed SocketAddress in RequestBalancingStrategy
by Patrick Seeber (JIRA)
Patrick Seeber created ISPN-3876:
------------------------------------
Summary: TcpTransportFactory stores failed SocketAddress in RequestBalancingStrategy
Key: ISPN-3876
URL: https://issues.jboss.org/browse/ISPN-3876
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.0.Final, 5.3.0.Final, 5.2.1.Final
Environment: Hotrod Client, Java
Reporter: Patrick Seeber
Assignee: Mircea Markus
The "updateServers" Method in the TcpTransportFactory class iterates over all addedServers and adds them to the connection pool if no exceptions are thrown. Howerver, if an exception is thrown, the SocketAddress may not have been added to the conection pool but is added to the balancer afterwards. Therefore, the balancer may contain an invalid SocketAddress which is not contained in the connection pool.
In our application with few distributed caches, we encounter situations where all servers (SocketAddresses) are corrupt and the application fails to load or store entries in/from the cache.
--
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
12 years, 3 months
[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3745:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1033087|https://bugzilla.redhat.com/show_bug.cgi?id=1033087] from ON_QA to VERIFIED
> Forwarded Prepare/Commit executed after transaction finished
> ------------------------------------------------------------
>
> Key: ISPN-3745
> URL: https://issues.jboss.org/browse/ISPN-3745
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha1
>
>
> Replicated TX cache, nodes A, B, C
> 0. A and B have topology 2, C already got topology 3
> 1. A sends prepare with topology 2 to B and C, both apply the prepare and respond
> 2. C forwards prepare to B with topology 3
> 3. A sends commit with topology 2 to B and C, both commit and respond
> 4. again, C forwards prepare to B with topology 3
> 5. A and B get updated topology id
> 6. A executes another transaction on the same entry
> 7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites (or removes) the entry again
> Result: on B we have inconsistent state
--
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
12 years, 3 months
[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3704:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1032050|https://bugzilla.redhat.com/show_bug.cgi?id=1032050] from ON_QA to VERIFIED
> StateTransfer's PutKeyValueCommand may trigger remote get
> ---------------------------------------------------------
>
> Key: ISPN-3704
> URL: https://issues.jboss.org/browse/ISPN-3704
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha1
>
>
> In TX mode with write skew check on, ST executing puts may trigger a remote get.
> The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from
> {code}
> if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> to
> {code}
> if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> EDIT:
> I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well.
--
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
12 years, 3 months
[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-3704:
------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2304
> StateTransfer's PutKeyValueCommand may trigger remote get
> ---------------------------------------------------------
>
> Key: ISPN-3704
> URL: https://issues.jboss.org/browse/ISPN-3704
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha1
>
>
> In TX mode with write skew check on, ST executing puts may trigger a remote get.
> The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from
> {code}
> if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> to
> {code}
> if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> EDIT:
> I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well.
--
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
12 years, 3 months
[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ]
Radim Vansa reopened ISPN-3704:
-------------------------------
> StateTransfer's PutKeyValueCommand may trigger remote get
> ---------------------------------------------------------
>
> Key: ISPN-3704
> URL: https://issues.jboss.org/browse/ISPN-3704
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha1
>
>
> In TX mode with write skew check on, ST executing puts may trigger a remote get.
> The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from
> {code}
> if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> to
> {code}
> if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> EDIT:
> I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well.
--
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
12 years, 3 months