[infinispan-dev] WildFly NoSQL client integration and Infinispan remote/JDG as a NoSQL client...

[Scott Marlow]

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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>