4:35 a.m.
FYI
I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for
integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's
own.
The integration is done as a subsystem, which can be used to run a a single C* node on a
standalone box, but more importantly it allows for launching and managing a complete C*
cluster as part of Wildfly managed domain. I've provided example configuration files
for both options which can be used to play around with it and get going.
The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't
designed to be used an embedded library. In particular the CassandraDaemon and some of the
core services make heavy use 'System.exit()' calls. In order to embed Cassandra as
a managed service, we had to remove some of the code that would otherwise break the
service contracts in Wildfly. But I am confident we can find a way to get these changes
back into the upstream project. But I haven't discussed all the details with the
Apache folks yet.
Overall it's pretty much work in progress, but I think it's good enough to get
your hands dirty. You can find the codebase in my github repository:
https://github.com/heiko-braun/wildfly-cassandra
Thoughts and comments are welcome.
/Heiko
[1] http://cassandra.apache.org/
[2] https://github.com/rhq-project/rhq-metrics
8:10 a.m.
On 8/25/14, 4:35 AM, Heiko Braun wrote:
FYI
I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for
integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's
own.
The integration is done as a subsystem, which can be used to run a a single C* node on a
standalone box, but more importantly it allows for launching and managing a complete C*
cluster as part of Wildfly managed domain. I've provided example configuration files
for both options which can be used to play around with it and get going.
The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't
designed to be used an embedded library. In particular the CassandraDaemon and some of the
core services make heavy use 'System.exit()' calls. In order to embed Cassandra as
a managed service, we had to remove some of the code that would otherwise break the
service contracts in Wildfly. But I am confident we can find a way to get these changes
back into the upstream project. But I haven't discussed all the details with the
Apache folks yet.
Overall it's pretty much work in progress, but I think it's good enough to get
your hands dirty. You can find the codebase in my github repository:
https://github.com/heiko-braun/wildfly-cassandra
Thoughts and comments are welcome.
One possible option might be to run it as a subprocess.
--
- DML
10:36 a.m.
Yeah, you could have a service that controls the cassandra daemon as a
service and uses whatever its default network API is for communications.
This should be safe and reliable as of JDK 7.
Just a suggestion in case embedding becomes an untenable proposition.
On 8/26/14, 8:23 AM, Heiko Braun wrote:
Not sure I can follow. Do you refer to the System.exit() calls?
On 26 Aug 2014, at 15:10, David M. Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
> One possible option might be to run it as a subprocess.
--
- DML
3:12 a.m.
David,
I've been thinking more about your proposal to treat the cassandra daemon as a
subprocess. Currently the cassandra dependencies are installed along side the module. How
would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to
the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules?
/Heiko
On 26 Aug 2014, at 17:36, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
Yeah, you could have a service that controls the cassandra daemon as
a
service and uses whatever its default network API is for communications.
This should be safe and reliable as of JDK 7.
Just a suggestion in case embedding becomes an untenable proposition.
On 8/26/14, 8:23 AM, Heiko Braun wrote:
>
>
> Not sure I can follow. Do you refer to the System.exit() calls?
>
> On 26 Aug 2014, at 15:10, David M. Lloyd <david.lloyd(a)redhat.com
> <mailto:david.lloyd@redhat.com>> wrote:
>
>> One possible option might be to run it as a subprocess.
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
7:52 a.m.
Well, I have a bias of course, but it seems to me like you could just
add Cassandra and its dependencies as modules and then launch it like this:
String javaHome = System.getProperty("java.home");
ProcessBuilder pb = new ProcssBuilder(
javaHome + File.pathSeparator + "bin" + File.pathSeparator + "java",
...jvm args...,
"-jar",
"jboss-modules.jar",
"-mp",
"modules",
"org.whatever.cassandra",
...cassandra args...);
...set up I/O redirection here...
Process p = pb.start();
On 09/19/2014 03:12 AM, Heiko Braun wrote:
David,
I've been thinking more about your proposal to treat the cassandra daemon as a
subprocess. Currently the cassandra dependencies are installed along side the module. How
would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to
the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules?
/Heiko
On 26 Aug 2014, at 17:36, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> Yeah, you could have a service that controls the cassandra daemon as a
> service and uses whatever its default network API is for communications.
> This should be safe and reliable as of JDK 7.
>
> Just a suggestion in case embedding becomes an untenable proposition.
>
> On 8/26/14, 8:23 AM, Heiko Braun wrote:
>>
>>
>> Not sure I can follow. Do you refer to the System.exit() calls?
>>
>> On 26 Aug 2014, at 15:10, David M. Lloyd <david.lloyd(a)redhat.com
>> <mailto:david.lloyd@redhat.com>> wrote:
>>
>>> One possible option might be to run it as a subprocess.
>>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
7:57 a.m.
It's not my preferred solution, but something to explore. At the same time I talking
to the apache folks if we can get rid of the System.exit() call in C*. Which they seem to
consider a good thing too.
But thanks for the pointers, I'll have a look. Bootstrapping modules like we do it for
WF didn't come to my mind.
Regards, Heiko
On 19 Sep 2014, at 14:52, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
Well, I have a bias of course, but it seems to me like you could just
add Cassandra and its dependencies as modules and then launch it like this:
String javaHome = System.getProperty("java.home");
ProcessBuilder pb = new ProcssBuilder(
javaHome + File.pathSeparator + "bin" + File.pathSeparator +
"java",
...jvm args...,
"-jar",
"jboss-modules.jar",
"-mp",
"modules",
"org.whatever.cassandra",
...cassandra args...);
...set up I/O redirection here...
Process p = pb.start();
On 09/19/2014 03:12 AM, Heiko Braun wrote:
>
>
> David,
>
> I've been thinking more about your proposal to treat the cassandra daemon as a
subprocess. Currently the cassandra dependencies are installed along side the module. How
would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to
the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules?
>
> /Heiko
>
> On 26 Aug 2014, at 17:36, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>
>> Yeah, you could have a service that controls the cassandra daemon as a
>> service and uses whatever its default network API is for communications.
>> This should be safe and reliable as of JDK 7.
>>
>> Just a suggestion in case embedding becomes an untenable proposition.
>>
>> On 8/26/14, 8:23 AM, Heiko Braun wrote:
>>>
>>>
>>> Not sure I can follow. Do you refer to the System.exit() calls?
>>>
>>> On 26 Aug 2014, at 15:10, David M. Lloyd <david.lloyd(a)redhat.com
>>> <mailto:david.lloyd@redhat.com>> wrote:
>>>
>>>> One possible option might be to run it as a subprocess.
>>>
>>
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9 a.m.
Even if System.exit() isn't called, the process can still terminate for
other reasons. How do you want to handle a Cassandra process
termination? Perhaps log the error and retry starting it a certain
number of times (with maybe a time threshold on how many times to
restart)? Do we have logic like this elsewhere?
IMO, we should also read the Cassandra process output so that it doesn't
stay in memory.
On 09/19/2014 08:57 AM, Heiko Braun wrote:
It's not my preferred solution, but something to explore. At the
same time I talking to the apache folks if we can get rid of the System.exit() call in C*.
Which they seem to consider a good thing too.
But thanks for the pointers, I'll have a look. Bootstrapping modules like we do it
for WF didn't come to my mind.
Regards, Heiko
On 19 Sep 2014, at 14:52, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> Well, I have a bias of course, but it seems to me like you could just
> add Cassandra and its dependencies as modules and then launch it like this:
>
> String javaHome = System.getProperty("java.home");
> ProcessBuilder pb = new ProcssBuilder(
> javaHome + File.pathSeparator + "bin" + File.pathSeparator +
"java",
> ...jvm args...,
> "-jar",
> "jboss-modules.jar",
> "-mp",
> "modules",
> "org.whatever.cassandra",
> ...cassandra args...);
> ...set up I/O redirection here...
> Process p = pb.start();
>
> On 09/19/2014 03:12 AM, Heiko Braun wrote:
>>
>>
>> David,
>>
>> I've been thinking more about your proposal to treat the cassandra daemon as
a subprocess. Currently the cassandra dependencies are installed along side the module.
How would I pass the classpath to the subprocess? Is there a way to get to the CP, similar
to the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules?
>>
>> /Heiko
>>
>> On 26 Aug 2014, at 17:36, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>>
>>> Yeah, you could have a service that controls the cassandra daemon as a
>>> service and uses whatever its default network API is for communications.
>>> This should be safe and reliable as of JDK 7.
>>>
>>> Just a suggestion in case embedding becomes an untenable proposition.
>>>
>>> On 8/26/14, 8:23 AM, Heiko Braun wrote:
>>>>
>>>>
>>>> Not sure I can follow. Do you refer to the System.exit() calls?
>>>>
>>>> On 26 Aug 2014, at 15:10, David M. Lloyd <david.lloyd(a)redhat.com
>>>> <mailto:david.lloyd@redhat.com>> wrote:
>>>>
>>>>> One possible option might be to run it as a subprocess.
>>>>
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:45 a.m.
Indeed, when you define a service to control the process, the lifecycle
of the process should not be tied to the service. Instead, the service
represents the desire to have the process running.
A dedicated reaper thread with a small (32k? maybe less on 32-bit?)
stack should be established to waitFor() and re-create the process (with
a short/configurable delay to avoid overloading the system). If you
want to capture stdout and stderr, one small-stack thread each should be
created for each to capture the process output and feed it to the
logging layer. Alternatively, they can be combined by ProcessBuilder so
you only need one thread (though the output might be intermixed).
Pooled threads generally are not a good fit for this application.
Daemon threads should not be used, as that might provide more
opportunity for the JVM to exit before the child process has been shut
down. In JDK 9, there will likely be options to force child processes
to terminate when the parent terminates, but we do not yet have this
capability available unfortunately, so we must live with this limit of
what we can do to avoid misadventure.
The input stream to the process must be managed so the process never
hangs waiting for input. This could be as simple as closing the stream
immediately on start.
The reaper thread should be cleanly managed to ensure deterministic
shutdown of the process on service stop(). This can be done through the
application of a (volatile) stop flag and thread interruption, combined
with async service stop, which the reaper thread would invoke upon exit.
Because you need an async service stop context to stop the thread, you
could use a field of this type as the stop flag; if null, then no stop
is requested.
Maybe a ProcessManagementService would be a good addition to MSC...
On 09/19/2014 09:00 AM, Scott Marlow wrote:
Even if System.exit() isn't called, the process can still
terminate for
other reasons. How do you want to handle a Cassandra process
termination? Perhaps log the error and retry starting it a certain
number of times (with maybe a time threshold on how many times to
restart)? Do we have logic like this elsewhere?
IMO, we should also read the Cassandra process output so that it doesn't
stay in memory.
On 09/19/2014 08:57 AM, Heiko Braun wrote:
> It's not my preferred solution, but something to explore. At the same
> time I talking to the apache folks if we can get rid of the
> System.exit() call in C*. Which they seem to consider a good thing too.
>
> But thanks for the pointers, I'll have a look. Bootstrapping modules
> like we do it for WF didn't come to my mind.
>
> Regards, Heiko
>
> On 19 Sep 2014, at 14:52, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>
>> Well, I have a bias of course, but it seems to me like you could just
>> add Cassandra and its dependencies as modules and then launch it like
>> this:
>>
>> String javaHome = System.getProperty("java.home");
>> ProcessBuilder pb = new ProcssBuilder(
>> javaHome + File.pathSeparator + "bin" + File.pathSeparator +
"java",
>> ...jvm args...,
>> "-jar",
>> "jboss-modules.jar",
>> "-mp",
>> "modules",
>> "org.whatever.cassandra",
>> ...cassandra args...);
>> ...set up I/O redirection here...
>> Process p = pb.start();
>>
>> On 09/19/2014 03:12 AM, Heiko Braun wrote:
>>>
>>>
>>> David,
>>>
>>> I've been thinking more about your proposal to treat the cassandra
>>> daemon as a subprocess. Currently the cassandra dependencies are
>>> installed along side the module. How would I pass the classpath to
>>> the subprocess? Is there a way to get to the CP, similar to the way
>>> an URLClassLoader exposes it? Or how could it be achieved with JBoss
>>> modules?
>>>
>>> /Heiko
>>>
>>> On 26 Aug 2014, at 17:36, David M. Lloyd <david.lloyd(a)redhat.com>
>>> wrote:
>>>
>>>> Yeah, you could have a service that controls the cassandra daemon as a
>>>> service and uses whatever its default network API is for
>>>> communications.
>>>> This should be safe and reliable as of JDK 7.
>>>>
>>>> Just a suggestion in case embedding becomes an untenable proposition.
>>>>
>>>> On 8/26/14, 8:23 AM, Heiko Braun wrote:
>>>>>
>>>>>
>>>>> Not sure I can follow. Do you refer to the System.exit() calls?
>>>>>
>>>>> On 26 Aug 2014, at 15:10, David M. Lloyd <david.lloyd(a)redhat.com
>>>>> <mailto:david.lloyd@redhat.com>> wrote:
>>>>>
>>>>>> One possible option might be to run it as a subprocess.
>>>>>
>>>>
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
- DML
4:24 p.m.
With Java 7 you can inherit the I/O too so you don't have to consume it.
pb.inheritIO();
On 09/19/2014 05:52 AM, David M. Lloyd wrote:
Well, I have a bias of course, but it seems to me like you could
just
add Cassandra and its dependencies as modules and then launch it like this:
String javaHome = System.getProperty("java.home");
ProcessBuilder pb = new ProcssBuilder(
javaHome + File.pathSeparator + "bin" + File.pathSeparator +
"java",
...jvm args...,
"-jar",
"jboss-modules.jar",
"-mp",
"modules",
"org.whatever.cassandra",
...cassandra args...);
...set up I/O redirection here...
Process p = pb.start();
On 09/19/2014 03:12 AM, Heiko Braun wrote:
>
> David,
>
> I've been thinking more about your proposal to treat the cassandra daemon as a
subprocess. Currently the cassandra dependencies are installed along side the module. How
would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to
the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules?
>
> /Heiko
>
> On 26 Aug 2014, at 17:36, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>
>> Yeah, you could have a service that controls the cassandra daemon as a
>> service and uses whatever its default network API is for communications.
>> This should be safe and reliable as of JDK 7.
>>
>> Just a suggestion in case embedding becomes an untenable proposition.
>>
>> On 8/26/14, 8:23 AM, Heiko Braun wrote:
>>>
>>> Not sure I can follow. Do you refer to the System.exit() calls?
>>>
>>> On 26 Aug 2014, at 15:10, David M. Lloyd <david.lloyd(a)redhat.com
>>> <mailto:david.lloyd@redhat.com>> wrote:
>>>
>>>> One possible option might be to run it as a subprocess.
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
8:32 a.m.
One thing we'll need to sort through is the socket configuration. It
looks like some addresses and ports are being directly configured in the
subsystem. These should be done via references to socket bindings (for
server sockets) and outbound socket bindings (for client sockets).
This will complicate things a bit in terms of wiring up the services,
but it shouldn't be a big deal; we do it lots of places.
On 8/25/14, 4:35 AM, Heiko Braun wrote:
FYI
I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for
integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's
own.
The integration is done as a subsystem, which can be used to run a a single C* node on a
standalone box, but more importantly it allows for launching and managing a complete C*
cluster as part of Wildfly managed domain. I've provided example configuration files
for both options which can be used to play around with it and get going.
The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't
designed to be used an embedded library. In particular the CassandraDaemon and some of the
core services make heavy use 'System.exit()' calls. In order to embed Cassandra as
a managed service, we had to remove some of the code that would otherwise break the
service contracts in Wildfly. But I am confident we can find a way to get these changes
back into the upstream project. But I haven't discussed all the details with the
Apache folks yet.
Overall it's pretty much work in progress, but I think it's good enough to get
your hands dirty. You can find the codebase in my github repository:
https://github.com/heiko-braun/wildfly-cassandra
Thoughts and comments are welcome.
/Heiko
[1] http://cassandra.apache.org/
[2] https://github.com/rhq-project/rhq-metrics
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 a.m.
Yeah, agreed. I already had that on my list of todos.
Am 26.08.2014 um 15:32 schrieb Brian Stansberry
<brian.stansberry(a)redhat.com>:
One thing we'll need to sort through is the socket configuration. It
looks like some addresses and ports are being directly configured in the
subsystem. These should be done via references to socket bindings (for
server sockets) and outbound socket bindings (for client sockets).
This will complicate things a bit in terms of wiring up the services,
but it shouldn't be a big deal; we do it lots of places.
> On 8/25/14, 4:35 AM, Heiko Braun wrote:
>
> FYI
>
> I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for
integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's
own.
>
> The integration is done as a subsystem, which can be used to run a a single C* node
on a standalone box, but more importantly it allows for launching and managing a complete
C* cluster as part of Wildfly managed domain. I've provided example configuration
files for both options which can be used to play around with it and get going.
>
> The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra
isn't designed to be used an embedded library. In particular the CassandraDaemon and
some of the core services make heavy use 'System.exit()' calls. In order to embed
Cassandra as a managed service, we had to remove some of the code that would otherwise
break the service contracts in Wildfly. But I am confident we can find a way to get these
changes back into the upstream project. But I haven't discussed all the details with
the Apache folks yet.
>
> Overall it's pretty much work in progress, but I think it's good enough to
get your hands dirty. You can find the codebase in my github repository:
>
> https://github.com/heiko-braun/wildfly-cassandra
>
> Thoughts and comments are welcome.
>
> /Heiko
>
> [1] http://cassandra.apache.org/
> [2] https://github.com/rhq-project/rhq-metrics
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3751
days inactive
3776
days old
11 comments
5 participants
participants (5)
-
Brian Stansberry -
David M. Lloyd -
Heiko Braun -
James R. Perkins -
Scott Marlow