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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sanne Grinovero-3
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.

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.

But is it really useful for people to have a default, predefined testdb?

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.

Thanks,
Sanne


On 12 May 2016 at 16:23, Scott Marlow <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev