What are the current Maven Repos needed?
by Jason T. Greene
A build of the root infinispan fails on my system looking for artifacts
I don't have (e.g. casandra). I'm using the standard jboss repo settings
which proxies central and others. I can see casandra 0.7 is on central
but not 0.6.
Is there an additional list of repos I should be using? Or am I supposed
to just install these all locally?
--
Jason T. Greene
JBoss, a division of Red Hat
14 years, 5 months
issue with Websocket in firefox
by Pavana Kumari
Hi
I enabled websocket Security features in firefox4.0 but still firefox4.0 is unable to receive WebSocket events(onOpen,onMessage). Please help me in finding this issue
Regards
Pavana
DISCLAIMER: This email message and all attachments are confidential and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or to mailadmin(a)spanservices.com and destroy the original message. Opinions, conclusions and other information in this message that do not relate to the official business of SPAN, shall be understood to be neither given nor endorsed by SPAN.
14 years, 5 months
Please update your IDE's template / copyright settings
by "이희승 (Trustin Lee)"
Hi,
It seems like some of you have out-of-date template / copyright
settings. Please update it as described in:
http://community.jboss.org/wiki/CopyrightOwnershipAndLicenses
I'm using IDEA's copyright plugin and here's what mine looks like:
========
JBoss, Home of Professional Open Source
Copyright $today.year Red Hat Inc. and/or its affiliates and other
contributors as indicated by the @author tags. All rights reserved.
See the copyright.txt in the distribution for a full listing of
individual contributors.
This is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation; either version 2.1 of
the License, or (at your option) any later version.
This software is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this software; if not, write to the Free
Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA, or see the FSF site: http://www.fsf.org.
--
Trustin Lee, http://gleamynode.net/
14 years, 5 months
Releasing 4.2.2.BETA1
by Manik Surtani
Guys,
I'm going to cut this release this week - possibly tomorrow (Tuesday). Is there anything you want me to hold up the release for?
The only 2 things I see that are worth waiting for are ISPN-1046 and ISPN-1056 (both Galder). And maybe, just maybe ISPN-1007 (Mircea).
If you think you want these in 4.2.2.BETA1, could you have these in first thing tomorrow so I can go ahead and cut the release?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
14 years, 5 months
[ISPN-78] Feedback needed
by Olaf Bergner
I have the skeleton of an implementation of ISPN-78 - Large Object
Support - at https://github.com/obergner/infinispan/tree/t_ispn78.
Before going forward I could need some feedback on whether my approach
makes sense at all, what alternatives there are, where things might be
improved or modified to adhere to INFINISPAN's standards and so forth.
Any hint is highly appreciated.
Keep in mind that so far I have completely ignored the issue of
supporting transactions when reading and writing large objects. I would
prefer to have a working core implementation before tackling the more
complicated aspects.
Cheers,
Olaf
14 years, 5 months
infinispan-spring module
by Manik Surtani
Olaf,
After discussing with Marius, maybe the best place for your work on the Infinispan Spring integration is a module within Infinispan itself. I'm proposing infinispan-spring. WDYT?
You can add this module to Infinispan's repository under the root (so, a 'spring' directory alongside 'core', etc). I also think it makes sense to have this in 4.2.x and master branches.
Thoughts?
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
14 years, 5 months
CloudTM: Additional Atomic broadcast based replication mechanism integrated in Infinispan
by Paolo Romano
Hi,
at INESC-ID, we have just finished brewing another (full) replication
protocol for Infinispan, in the context of the Cloud-TM project. The
credits go to Pedro Ruivo, a Msc student working in our group, who
developed this as part of his thesis work.
Like the current Infinispan's 2PC-based replication mechanism, also this
is a multi-master scheme in which transactions are executed locally by
any node and without any coordination among replicas till the commit phase.
Rather than using 2PC, however, this scheme scheme relies on a single
Atomic broadcast (AB, a.k.a. total order broadcast) to disseminate
transactions' writesets while ensuring totally ordered delivery of
messages across the various nodes.
The replication scheme is, in fact, quite simple. Upon delivery of the
AB with the writeset of a transaction, we ensure that each replica
executes the following operations in the order established by the AB layer:
- acquiring locks on the writeset, possibly stealing the lock from any
locally running transaction (and flagging it as aborted)
- performing a write-skew check (in case Infinispan is configured to do
this check)
- applying the writeset
- release the locks.
ABcast can be implemented in many many ways, but for simplicity we used
the sequencer based implementation available in JGroups. This scheme is
quite simple:
- upon an atomic broadcast, the message is simply broadcast to all nodes
- upon receipt of the message, however, the nodes do not deliver it
immediately to the application layer (Infinispan in this case). Instead,
a special node (e.g. the one with lesser id in the group), namely the
sequencer, broadcasts back the order in which processes should deliver
this message.
- finally, the nodes deliver the atomic broadcast message in the order
specified by the sequencer.
The main advantage of this replication mechanism is that it avoids
distributed deadlocks, which makes its performance way better at high
contention (note that local deadlocks may still occur, as Infinispan's
encounter locking scheme does not prevent them. But these are much more
rare as the number of "contending" threads is much lower).
Further, locks are held shorter with respect to 2PC. With 2PC, the
cohort nodes, maintain the locks on behalf of the coordinator, since the
reception of the prepare and until they receive the commit message. This
encompasses a round trip (collecting votes from all cohorts, and sending
back the decision). With the ABcast scheme, instead, the locks acquired
on behalf of remote transactions, are held only for the time strictly
required to writeback locally.
Finally the sequencer is, in fact, a privileged node, as it can commit
transactions much faster than the other nodes, as it can self-assign the
order in which transactions need to be processed. This may not be very
fair at high contention rate, as it gets higher chances of committing
transactions, but does make it MUCH faster overall.
Concerning blocking scenarios in case of failures. Just like 2PC is
blocking in case of crashes of a node coordinating a transaction, this
replication scheme is also blocking, but this time in case of crashes of
the sequencer. The comparison in terms of liveness guarantees seem
therefore quite fair. (Note that it would have been possible to make
this replication mechanism non-blocking, at the cost of one extra
communication step. But we opted not to do it, to compare protocols more
fairly).
To evaluate performance we ran the same kind of experiments we used in
our recent mail where we evaluted a Primary backup-based replication
scheme. All nodes only do write operations, transactions of 10
statements, one of which being a put. Accesses are uniformly distributed
to 1K, 10K, 100K data items. Machines are 8cores, 8GB RAM, radargun is
using 10 threads per ndoe.
Summary of results (see attached pdf):
- Throughput, page 1: the plots show significant speedups. Especially at
high contention, where 2PC stumbles upon very frequent distributed
deadlocks. Note that we enabled deadlock detection in all experiments
running 2PC.
- Abort rate, page 2: abort rates are similar in both protocols (note
the logscale on y-axis). But the AB-based solution, avoiding deadlocks,
detects the need to abort transactions much faster than 2PC.
- Average Commit duration, page 3: at high contention, 2PC trashes due
to deadlocks (despite the deadlock detection mechanism), and this is
reflected in the Avg. commit duration as well. In the other cases (10K
and 100K keys), where there is less contention, the commit duration of
the two protocols is similar (see next).
- To bundle or not to bundle?, page 4: the throughput results shown in
page 1 have actually a little trick :-P We used "some" bundling ONLY in
the case of transactions spanning 100K data items. We noticed that w/o
bundling, the commit time duration of the AB-based scheme got way
lousier and experimented with a few bundling values till we got decent
performance (See plot at page 4). This is explainable since with 100K
keys, being the contention low, less transactions get aborted along
their execution. This means that more transaction reach the commit
phase, and, in its turn, more atomic broadcasts hit the network layer,
and more load for the sequencing node. Bundling, as you can see in page
4, makes the trick however. We did not retry the tests with the other
protocols with and w/o bundling, as this would have been very time
consuming. BTW, I believe that the results would not have been very
different.
Let me open a small parenthesis about bundling: this can be an extremely
effective weapon, but manual configuration is a bid headache and
extremely time consuming. I believe that it would be very useful to have
some self-tuning mechanism for it in JGroups. In fact, we've recently
got very nice results using Reinforcement-learning to tackle this
problem (well, to be precise, not really the same problem, but a very
similar one):
http://www.inesc-id.pt/ficheiros/publicacoes/7163.pdf
...but I've implemented the prototype of this solution in Appia, as I
knew it much better than JGroups. What do you think about integrating a
similar mechanism in JGroup's ergonomics?
Back to replication: we are now working on a similar solution for
partial replication (a.k.a. distribution in Infinispan).
I'll keep you posted on our progresses!
Cheers,
Paolo
PS: The code is available on GitHUB, if you want to take a look at it:
https://github.com/cloudtm/infinispan/tree/abcast_replication
14 years, 5 months
conflicts resolution in DeltaAware
by Sanne Grinovero
Hi Mircea,
I remember you recently mentioned that you have been looking into ways
to give the ability to the application to resolve updating conflicts.
I don't think you where referring to AtomicMap or any other DeltaAware
specifically, but it seems now that we urgently need something like
this in OGM.
I'm looking into the Delta interface, which defines this single method:
DeltaAware merge(DeltaAware d);
This looks great to merge an update onto an existing value; But of
course the world is made of parallel executing updates, especially so
when transactions are involved, so we would like to be able to deal
with multiple concurrent updates being applied on the same read value.
I'm wondering if we could get something like
DeltaAware merge(DeltaAware originalValue, DeltaAware updateA,
DeltaAware updateB) throws UnsolvableConflict;
As Emmanuel pointed out while implementing OGM, if two different
updates are being applied to an AtomicMap, it's possible that the
updates relate to different keys in the AtomicMap, and for the OGM
usecase we would be totally fine with that and would *not* like the
transaction to be rolled back. From my understanding of AtomicMap, if
two different keys are changed one transaction will fail (correct?).
Of course it's totally possible that both updates where going to
affect the same keys, and in this case we want to have the operation
rolled back.
I don't mean the API I wrote literally, I wrote it like that just to
give a general picture of what we need; I'm not really liking the idea
of throwing an exception on a potentially frequently occurring event,
and also while you could chain such invocations in case of multiple
updates arriving on the same key, I think it would be far better to be
able to try different combinations - or let the application try to be
clever - to try resolving as much non conflicting DeltaAware updates
as possible.
Considering that each transaction might change multiple keys, it would
be awesome to describe the API in such a way that either Infinispan or
the application can be "smart" and be able to estimate which
transaction could be removed (rolled back) to provide the minimum
amount of rolled back transactions. I'm not even sure the policy
should favour the maximum amount of transactions, maybe the
application wants to favour the highest possible changeset, or a
specific important one.
Even if we start just implementing the method signature I proposed,
that could bring a hell of scalability improvements; possibly not only
to HibernateOGM but as far as I understood the TreeCache as well.
Ideas?
Emmanuel, do you agree this would fit the HibernateOGM needs?
Cheers,
Sanne
14 years, 5 months
new Infinispan Query API - ISPN-194
by Sanne Grinovero
Infinispan 4.0 contained an integration with Hibernate Search to index
stored POJOs using the well-known Hibernate Search annotations; but
the configuration was tricky and the API quite limited.
With the latest changes in H.Search, we could now make a better integration.
Quick recap on configuration/usage on Infinispan 4:
1) indexing must be enabled in Infinispan configuration
2) a queryHelper class must be started and pointed to known types to
be indexed, passing it HS configuration properties
- this would start a Hibernate Search engine
- modifications done on the grid before the queryHelper was started
are ignored by the indexing engine
- list of "known entities" could not be changed
3) use a queryFactory to create queries, which needs to be hooked up
the previously started queryHelper
- the query options where a bit limited
What's coming in Infinispan 5:
1) indexing is still be enabled in Infinispan configuration
- Hibernate Search configuration properties are embedded in the
Infinispan configuration
<infinispan>
<default>
<indexing enabled="true" indexLocalOnly="true">
<properties>
<property
name="hibernate.search.default.directory_provider" value="ram" />
</properties>
</indexing>
</default>
</infinispan>
2) no queryHelper is needed
- lifecycle of the indexing engine is managed by Infinispan
- new entity types are autodiscovered
(each time a previously unseen class is put/removed it's annotation
scanned and HS is potentially reconfigured)
3) you still use a QueryFactory, like in the examples linked below
- exposes all features of Hibernate Search query builder DSL
- Faceting
- projections, etc..
API, most significant classes:
https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42d...
https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42d...
Two usage examples:
https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42d...
https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42d...
there's one catch:
when searching for a class type, it will only include results from
known subtypes. The targeted type is automatically added to the known
classes, but eventually existing subtypes are not discovered.
Bringing this issue to an extreme, if the query is not targeting any
type, and no indexed types where added to the grid (even if some exist
already as they might have been inserted by other JVMs or previous
runs), all queries will return no results.
How to solve this?
- class scanning?
- explicitly list indexed entities in Infinispan configuration?
- a metadata cache maintaining a distributed&stored copy of known types
- search for types in the index :) would be nice, but the current
design in Search mandates to know the entities first to know how the
indexes are named. without name I can't open the index, but maybe we
could have the user specify the index names instead of all entity
classtypes.
Feedback on the API is more urgent than to solve this, so it could
make it for Infinispan 5 Beta1.
Cheers,
Sanne
14 years, 5 months
XAResource without recovery
by Mircea Markus
Hi,
At the moment Infinispan can enlist in a tx either as an XAResource or as an Synchronization.
Do you see any situation in which somebody would want to use XAResource integration *without* recovery?
Cheers,
Mircea
14 years, 5 months
