New configuration
by Radim Vansa
Hi,
looking on the new configuration parser, I've noticed that you cannot
configure ConsistentHashFactory anymore - is this by purpose?
Another my concern is the fact that you enable stuff by parsing the
element - for example L1. I expect that omitting the element and setting
it with the default value (as presented in XSD) makes no difference, but
this is not how current configuration works.
My opinion comes probably too late as the PR was already reviewed,
discussed and integrated, but at least, please clearly describe the
behaviour in the XSD. The fact that l1-lifespan "Defaults to 10
minutes." is not correct - it defaults to L1 being disabled.
Thanks
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
9 years, 10 months
Where's the roadmap?
by Sanne Grinovero
I was asked about the Infinispan roadmap on a forum post, my draft reads:
"Sure it's available online, see.."
but then I could actually only find this:
https://community.jboss.org/wiki/InfinispanRoadmap
(which is very outdated).
So, what's the roadmap?
Would be nice if we could have it updated and published on the new website.
Cheers,
Sanne
9 years, 10 months
Remote Hot Rod events wiki updated
by Galder Zamarreño
Hi all,
I’ve finally managed to get around to updating the remote hot rod event design wiki [1].
The biggest changes are related to piggybacking on the cluster listeners functionality in order to for registration/deregistration of listeners and handling failure scenarios. This should simplify the actual implementation on the Hot Rod side.
Based on feedback, I’ve also changed some of the class names so that it’s clearer what’s client side and what’s server side.
A very important change is the fact that source id information has gone. This is primarily because near-cache like implementations cannot make assumptions on what to store in the near caches when the client invokes operations. Such implementations need to act purely on the events received.
Finally, a filter/converter plugging mechanism will be done via factory implementations, which provide more flexibility on the way filter/converter instances are created. This opens the possibility for filter/converter factory parameters to be added to the protocol and passed, after unmarshalling, to the factory callbacks (this is not included right now).
I hope to get started on this in the next few days, so feedback at this point is crucial to get a solid first release.
Cheers,
[1] https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
10 years
New API to iterate over current entries in cache
by William Burns
While working on ISPN-4068 to add the current state to listeners that
were added I found that what I essentially needed was a way to iterate
over the entries of the cache. I am thinking of adding this to the
public API available on the AdvancedCache interface.
I wanted to get your guy's opinions if you don't think we should add
it or any changes you might suggest.
My thought was to add 2 overloaded methods:
<C> Iterator<Map.Entry<K, C>> entryIterator(KeyValueFilter<? super K,
? super V> filter, Converter<? super K, ? super V, C> converter);
and
Iterator<Map.Entry<K, V>> entryIterator(KeyValueFilter<? super K, ?
super V> filter);
The method would return almost immediately after invocation and the
iterator would queue entries and block as entries are required to be
returned. The filter and converter are applied on each of the remote
nodes and are required to be serializable or have an externalizer
registered.
Internally the iterator would use chunking to help prevent memory
saturation. The max memory usage would be (chunkSize * N) + local
entries where N is the number of nodes.
These methods would be different than other methods on the
Cache/AdvancedCache in the following things:
1. This operation is treated as nontx and thus won't store them into
the context and thus repeatable read semantics would not be
guaranteed. This doesn't preclude manually adding values to the
context. Also prior writes in the current context would be ignored
(current data returned), although this could be changed if desired.
2. Values are not activated from loaders and visited listeners would
not be notified of access. The latter could be sensibly changed if
desired.
- Will
10 years
Infinispan Test language level to Java 8?
by Galder Zamarreño
Hi all,
Just thinking out loud: what about we start using JDK8+ for all the test code in Infinispan?
The production code would still have language level 6/7 (whatever is required…).
This way we start getting ourselves familiar with JDK8 in a safe environment and we reduce some of the boiler plate code currently existing in the tests.
This would only problematic for anyone consuming our test jars. They’d need move up to JDK8+ along with us.
Thoughts?
p.s. Recently I found https://leanpub.com/whatsnewinjava8/read which provides a great overview on what’s new in JDK8 along with small code samples.
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
10 years
ABI compatibility of C++ client
by Radim Vansa
Hi guys,
as I've tried to get rid of all the warnings emitted in Windows build of
C++ HotRod client, I've noticed that the ABI of this library is not very
well designed.
I am not an expert for this kind of stuff, but many sources I've found
say that exporting STL containers (such as string or vector, or
shared_ptr) is not ABI-safe.
For windows, the STL export is allowed [1] when both library and user
application is linked against the same version of CRT. I am really not
sure whether we want to force it to the user, and moreover, due to bug
in VC10 implementation of STL [2] we can't explicitly export shared_ptr
(I haven't found any workaround for that so far).
Regarding the GCC-world, situation is not better. The usual response for
exporting STL classes is "don't do that". It is expected that these
trouble will be addressed in C++17 (huh :)).
What can we do about that? Fixing this requires a lot of changes in
API... can we afford to do that now? Or will we just declare "compile
with the same versions and compile options as we did"? (we should state
them, then)
I have only limited knowledge of the whole C++ ecosystem, if I am wrong,
I'd be gladly corrected.
Radim
[1] http://support.microsoft.com/kb/168958
[2] http://connect.microsoft.com/VisualStudio/feedback/details/649531
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
10 years
Infinispan 7.0 to Java 7
by Mircea Markus
Hi guys,
Hibernate Search 5.0 is moving to Java 7 (besides others, because Lucene 4.8 does it).
For us it makes a lot of sense to bring in HSearch 5/Lucene 4 rather soon, as it's important for remote querying.
How does that sound?
Paul, how does that fit with the WF integration?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
10 years
OSGi
by Bilgin Ibryam
Hi Emmanuel,
I will give another try these days but I believe OSGi support in infinispan
is almost there now.
As for Camel integration, having a string based query language would
definitely be useful, for the time being I've provided a
QueryBuilderStrategy where the users has to manually build a QueryBuilder
from a QueryFactory Not ideal but works.
Cheers,
Brett has offered to help you but I know for sure he won?t lead it. He
> would be more like a good expect to talk to.
> Bilgin has shown a Camel integration prototype but he also seemed to imply
> that he had some significant problems that needed Infinispan improvements.
>
> Also, I?m not quite sure but looking at these Camel routes, they seem to
> be very URI driven. If we want to support query over a Camel route and
> express them via a URI, we will need a string based query language. I might
> be talking nonsense and somehow the query is written in Java. But better
> anticipate. Bilgin would know more, he has written in his demo
> CamelInfinispanOperationQuery after all :)
>
> Emmanuel
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 27 Mar 2014 11:32:37 +0100
> From: Giovanni Meo <gmeo(a)cisco.com>
> Subject: Re: [infinispan-dev] OSGi
> To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>,
> emmanuel(a)hibernate.org
> Message-ID: <5333FE45.3080909(a)cisco.com>
> Content-Type: text/plain; charset=windows-1252
>
> Hi Emmanuel and infinispan folks,
>
> we have been using Infinispan in OSGi environment in a project called
> OpenDayLight, if interested you can look at:
>
> >
> https://git.opendaylight.org/gerrit/gitweb?p=controller.git;a=blob;f=open...
>
> Granted we are using a tiny part of the infinispan capabilities, but we
> found
> very helpful to first of all define the contract the applications would
> have
> with the infinispan. For other issues like the classloading, we just made
> sure
> to provider a ClassResolver that always enforce the lookup in the OSGi
> class
> loader, and in spite of some initial unreliability things has been doing
> ok for us.
>
> My 2 cents,
> Giovanni
>
> On 27-Mar-14 10:28, Emmanuel Bernard wrote:
> > Hey guys,
> >
> > Sanne and Hardy are working on the OSGi-ification of Hibernate Search
> and it
> > does not come without trouble.
> >
> > Who is leading this effort on the Infinispan side? I recommend you start
> > early in a release cycle because you will have to butcher APIs and
> packages
> > to do it properly. Worse, you will suffer from you dependencies.
> >
> > Brett has offered to help you but I know for sure he won?t lead it. He
> would
> > be more like a good expect to talk to. Bilgin has shown a Camel
> integration
> > prototype but he also seemed to imply that he had some significant
> problems
> > that needed Infinispan improvements.
> >
> > Also, I?m not quite sure but looking at these Camel routes, they seem to
> be
> > very URI driven. If we want to support query over a Camel route and
> express
> > them via a URI, we will need a string based query language. I might be
> > talking nonsense and somehow the query is written in Java. But better
> > anticipate. Bilgin would know more, he has written in his demo
> > CamelInfinispanOperationQuery after all :)
> >
> > Emmanuel _______________________________________________ infinispan-dev
> > mailing list infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Giovanni Meo
> Via del Serafico, 200 Telephone: +390651644000
> 00142, Roma Mobile: +393480700958
> Italia Fax: +390651645917
> VOIP: 8-3964000
> ?The pessimist complains about the wind;
> the optimist expects it to change;
> the realist adjusts the sails.? -- Wm. Arthur Ward
> IETF credo: "Rough consensus and running code"
>
>
> ------------------------------
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> End of infinispan-dev Digest, Vol 60, Issue 30
> **********************************************
>
--
Bilgin Ibryam
Apache Camel & Apache OFBiz committer
Blog: ofbizian.com
Twitter: @bibryam <https://twitter.com/bibryam>
Author of Instant Apache Camel Message Routing
http://www.amazon.com/dp/1783283475
10 years, 1 month
