6:09 p.m.
Hi Sanne,
Thanks for the response! :-)
On 05/15/2016 06:46 PM, Sanne Grinovero wrote:
Hi Scott,
I don't think that having a default "testdb" would be useful if it
assumes that the user started an instance of Infinispan Server on a
"testhostmachine": very likely end users would want to at least change
the hostname; one might as well add the whole section at that point.
All hostname/port numbers are now defined via the WildFly
socket-binding-group section, so that users can change hostname/port
numbers in the management console.
It could be more interesting if the user could lookup - eg via JNDI or
some connection URL - a reference to a client which is exposing the
same API be it a remote or a local CacheManager instance; in this case
you could have a local CacheManager instance started by default within
WildFly and have applications consume this.
When the user looks up a CacheManager, does the remote CacheManager
handle marshalling of application classes? Or just Java types?
But is it really useful for people to have a default, predefined testdb?
No, the below testdb is just an example of what might be found in the
infinispan-nosql subsystem. I assume that the infinispan-nosql
subsystem could reference many different target hosts.
I wonder if it shouldn't rather be very easy for an application to
define what it needs, e.g. I'd allow applications to include a
"META-INF/caches.xml" to list the Caches needed by the application,
have WildFly create (and manage) these and provide a way for the
application to lookup the client, or have the client injected.
Is the remote cache a mirror system, that contains the same application
deployments as the client calling in?
I assume that the remote cache is not a WildFly clustered host but
really do not know. If the remote cache is a WildFly clustered host,
that is already handled via the WildFly dispatcher. If not, then
authentication needs to be supported for the remote cache clients.
Regarding the "META-INF/caches.xml" idea, I'm not sure yet about that
idea. Would each client deployment, have its own connection pool to the
remote server? Or would caches.xml identify shared connection profiles
that are defined in the WildFly standalone*.xml?
Thanks,
Sanne
On 12 May 2016 at 16:23, Scott Marlow <smarlow(a)redhat.com> wrote:
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev