WildFly NoSQL client integration and Infinispan remote/JDG as a NoSQL client...
by Scott Marlow
Hi,
Could you bring answers to the discussion [1] about using Infinispan as
a remote NoSQL store in WildFly.
Perhaps the WildFly standalone.xml subsystem configuration might define
a "testdb" profile that any application deployment can use to remotely
access the remote Infinispan server running on "testhostmachine" via
configuration:
"
<subsystem xmlns="urn:jboss:domain:infinispan-nosql:1.0">
<infinispan name="default" id="dbtestprofile"
jndi-name="java:jboss/infinispan/test" database="testdb">
<host name="default" outbound-socket-binding-ref="testhost"/>
</infinispan>
</subsystem>
<socket-binding-group name="standard-sockets" default-interface="public"
port-offset="${jboss.socket.binding.port-offset:0}">
<outbound-socket-binding name="testhost">
<remote-destination host="testhostmachine" port="11234"/>
</outbound-socket-binding>
</socket-binding-group>
"
Does this match at all with how you thought a WildFly application server
might use a remote Infinispan server?
Are there any concerns about marshalling, since the remote server
(testhostmachine) may be a WildFly application server that doesn't have
the same application deployments?
Mostly, I'd like to discuss the above on [1] but here is fine also (we
can link to this mailing list from [1], if we talk here).
Scott
[1] http://lists.jboss.org/pipermail/wildfly-dev/2016-May/004966.html
8 years, 1 month
Infinispan documentation
by Tristan Tarrant
Hi all,
just a heads up on my documentation overhaul plan (incidentally the
WildFly guys are also currently discussing their own documentation
issues too on wildfly-dev).
First of all, I've issued a PR [1] which performs an initial overhaul of
the documentation source files by removing the meaningless "chapter-xx"
prefix, removing obsolete/duplicated sections, replacing mentions of
JBoss AS 7 with WildFly and rearranging some sections so that the flow
is more accurate (i.e. all cachestores as children of persistence,
simple-cache as a child of local-cache, total-order as a child of
transactions, etc).
The following are issues / tasks I would like to tackle in the near future:
- Single page vs multiple pages
While having a single page might be useful in some situation (offline?)
it is cumbersome to navigate and hurts our SEO. Try searching for
"infinispan transactions" and Google still shows the old wiki page.
- Collapsible Table of Contents
Our current TOC is very large (67 lines) and it is always expanded. This
means that readers need to scroll to find what they are looking for. I
think that providing an expandable/collapsible tree would be ideal.
- Merging the guides
By introducing a multi-page approach, the reason to split our different
guides (getting started, user, server, faq) becomes less of a necessity.
- Versioning
Currently the documentation for each version is available under
docs/major.minor/. I would like to have semantic names for our main docs
instead (i.e. "stable" and "dev"). Unfortunately this means that searching
- Alternative formats
Asciidoc makes it easy to produce alternative formats and I think we
should generate PDF, EPUB and single HTML as well available as separate
downloads.
I've been playing with the "webhelp" style available in docbook and I
got [2] (be warned, it's a partial upload) which has many of the
advantages I'm looking for (and more, like an integrated search), but
some shortcomings as well. In particular each web page is ~145KB of
which 132KB of the sidebar, which I guess could be extracted into an iframe.
Comments and suggestions are obviously welcome
Tristan
[1] https://github.com/infinispan/infinispan/pull/4345
[2] http://www.dataforte.net/infinispan/configuring_cache.html
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
8 years, 1 month
Distributed Counter Discussion
by Pedro Ruivo
Hi everybody,
Discussion about distributed counters.
== Public API ==
interface Counter
String getName() //counter name
long get() //current value. may return stale value due to concurrent
operations to other nodes.
void increment() //async or sync increment. default add(1)
void decrement() //async or sync decrement. default add(-1)
void add(long) //async or sync add.
void reset() //resets to initial value
Note: Tried to make the interface as simple as possible with support for
sync and async operations. To avoid any confusion, I consider an async
operation as happening somewhat in the future, i.e. eventually
increments/decrements.
The sync operation happens somewhat during the method execution.
interface AtomiCounter extends Counter
long addAndGet() //adds a returns the new value. sync operation
long incrementAndGet() //increments and returns the new value. sync
operation. default addAndGet(1)
long decrementAndGet() //decrements and returns the new value. sync
operation. default addAndGet(-1)
interface AdvancedCounter extends Counter
long getMin/MaxThreshold() //returns the min and max threshold value
void add/removeListener() //adds a listener that is invoked when the
value change. Can be extended to notify when it is "reseted" and when
the threshold is reached.
Note: should this interface be splitted?
== Details ==
This is what I have in mind. Two counter managers: one based on JGroups
counter and another one based on Infinispan cache.
The first one creates AtomicCounters and it first perfectly. All
counters are created with an initial value (zero by default)
The second generates counters with all the options available. It can mix
sync/async operation and all counters will be in the same cache. The
cache will be configure by us and it would be an internal cache. This
will use all the features available in the cache.
Configuration-wise, I'm thinking about 2 parameters: number of backups
and timeout (for sync operations).
So, comment bellow and let me know alternatives, improvement or if I
missed something.
ps. I also consider implement a counter based on JGroups-raft but I
believe it is an overkill.
ps2. sorry for the long email :( I tried to be shorter as possible.
Cheers,
Pedro
8 years, 1 month
HDFS FileStore
by Cristian Malinescu
Hello folks - I would like to implement for my own project a custom cache
store for Infinispan using HDFS and using as base line one of the already
implemented file stores - SoftIndex and SingleFile.
I thought it would be beneficiary if I start and do it directly as
contribution to the Infinispan code base, is someone interested to take on
this subject and we start brainstorming about how should this task being
approached to be sure it gets done smooth, accordingly to the project's
community house rules so we don't encounter hassle at the point when we can
look at merging in the baseline, avoid potentially double work for same
feature etc.
Kind regards
Cristian Malinescu
https://github.com/Cristian-Malinescu
https://www.linkedin.com/in/cristianmalinescu
P.S I went already trough
http://infinispan.org/docs/8.2.x/contributing/contributing.html
so theoretically I can just start and place a pull request on GitHub but I
wanted to be sure you guys are also aware of this plan so we keep in sync
and all opinions are taken in consideration and addressed.
8 years, 1 month
GSOC 2016. Smart HTTP/2-based protocol for Infinispan. Community Bonding
by Anton Gabov
Hello everybody!
My name is Anton. I'm participating in project "Infinispan. Smart
HTTP/2-based protocol for Infinispan" (GSoC 2016). Here is link to the
proposal https://summerofcode.withgoogle.com/projects/#6140413916217344.
I'm newbie in Infinispan. Currently, I'm trying to deploy Infinispan
server to my virtual server + play with configurations :)
Also, read documentations concerning to Infinispan, Hot Rod protocol and HTTP/2.
It's really difficult project and I'll do my best!
I hope I can count on your support!
May I ask questions in IRC chat (#infinispan), if I have them?
Best Wishes,
Gabov Anton.
8 years, 1 month
