[wildfly-dev] adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

[Scott Marlow]

On 06/06/2016 03:26 PM, Brian Stansberry wrote:
> On 5/31/16 6:04 PM, Scott Marlow wrote:
>>
>> On 05/31/2016 04:48 PM, Scott Marlow wrote:
>>>
>>>
>>> On 05/27/2016 10:19 AM, Scott Marlow wrote:
>>>>
>>>>
>>>> On 05/27/2016 09:33 AM, Brian Stansberry wrote:
>>>>> Can a new profile be added post-boot without requiring a reload to
>>>>> take
>>>>> effect? If yes, the add handler for the profile resource should do the
>>>>> service installation for that profile. It shouldn't count on the
>>>>> parent
>>>>> to do it, as the parent logic will only execute during boot.
>>>>
>>>> I like the idea of adding a new profile post-boot, without requiring a
>>>> reload of all of the profiles defined by the MongoDB/Cassandra
>>>> subsystem.
>>>
>>> I need to back up on my response.  What does it mean for adding a new
>>> profile without requiring a reload?  Does that require a hot change to
>>> the NoSQL profile service without undeploying the application?
>>
>> After refreshing on
>> https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-applyingruntimeupdates,
>>
>> I think currently, we should specify that a reload (all-services) is
>> needed when adding/removing profiles.
>>
>
> Ok.
>
> I was on vacation, so sorry for no reply.

Welcome back! :-)

>
> I don't fully understand what these services are doing, so my only
> comment is that it's ok (and common) to require a reload for a remove
> but not for an add. A removal can disrupt other services while an add
> often doesn't.

I think that should also be true for the NoSQL integration.  So, we 
should probably handle both add/remove at the "profile" level, so that 
add does not require a reload.  Some more details are below about what 
should be going on internally with these services...

For the example below, "mongodbtestprofile" represents a connection 
profile that applications can @Inject/@Resource into an application 
MongoClient/MongoDatabase variable.  The application may use the 
MongoClient/MongoDatabase to read/write the MongoDB database as 
represented by the "mongodbtestprofile" hostname/port/other settings.

There could be zero to many, different application deployments that are 
using "mongodbtestprofile".  A removal of the internal service 
representing "mongodbtestprofile", would *disrupt* the deployments that 
are using "mongodbtestprofile".  The deployments do not yet have 
dependencies set on the "mongodbtestprofile" internal service but I 
think they will need to (currently on the TODO list).

Adding a new NoSQL profile, would likely be done before some new 
application(s) are deployed that will use the added profile.

There are differences between the different NoSQL profiles that we will 
support, which is why we will have a subsystem per NoSQL database type 
(MongoDB/Cassandra/Neo4J initially).  For example, the Neo4J Driver 
class is thread safe and can be expected to be shared by multiple 
deployments, however the Neo4J Session is not expected to be shared.  In 
contrast, MongoDB allows the MongoClient/MongoDatabase class instances 
to be shared by multiple threads.

Hibernate OGM will also use the NoSQL profiles as well.

>
>>>
>>>>
>>>> Currently, the standalone*.xml might contain:
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:mongodb:1.0">
>>>>    <mongo name="default" id="mongodbtestprofile"
>>>> jndi-name="java:jboss/mongodb/test" database="mongotestdb">
>>>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>>>    </mongo>
>>>>    <mongo name="default2" id="mongodbdiary"
>>>> jndi-name="java:jboss/mongodb/diary" database="diarydb">
>>>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>>>    </mongo>
>>>> </subsystem>
>>>>
>>>> If the user wants to add an additional profile to the mongodb
>>>> subsystem,
>>>> I think it would be worth us making the code changes to allow that.
>>>> Will be great to add a new "otherDB", without stopping the existing
>>>> database profiles.
>>>>
>>>> For supporting "remove" of an existing profile, I think that we will
>>>> need dependencies added on the underlying
>>>> MongoDriverService/CassandraDriverService, will be very worthwhile to
>>>> have that as well!  Great feedback! :-)
>>>>
>>>>>
>>>>> BTW, if post-boot profile adds/removes don't require reload, then [1]
>>>>> should not be inside the "if
>>>>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?
>>>>
>>>> Makes sense, looks like we need a remove handler also for the profile
>>>> resource.
>>>>
>>>>> Same
>>>>> question applies for the cassandra add handler.
>>>>
>>>> We should change the cassandra add handler also.
>>>>
>>>> Thanks again,
>>>> Scott
>>>>
>>>>>
>>>>> [1]
>>>>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>>>>>
>>>>>
>>>>>
>>>>> On 5/26/16 3:02 PM, Scott Marlow wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We will soon add several (nested) NoSQL configuration settings.
>>>>>> Before
>>>>>> we do that, I would like some feedback on the current NoSQL subsystem
>>>>>> code that reads connection settings.
>>>>>>
>>>>>> Any major corrections that you can suggest for the NoSQL subsystem
>>>>>> code
>>>>>> [1][2]?  Especially, the
>>>>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>>>>>>
>>>>>>
>>>>>> methods.
>>>>>>
>>>>>> Should we continue to read all of the configuration settings from one
>>>>>> AddStepHandler or should we do that differently (perhaps with
>>>>>> separate
>>>>>> AbstractAddStepHandler's)?
>>>>>>
>>>>>> Thanks,
>>>>>> Scott
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>>>>>
>>>>>>
>>>>>>
>>>>>> [2]
>>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
>