<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
JBeret currently only supports in-VM multi-threaded job executions.
We are aware of this requirement and is planned in future
iterations, at least after it's well integrated into WildFly.<br>
<br>
I'm glad you brought up that point.<br>
<br>
Cheng<br>
<br>
<div class="moz-cite-prefix">On 7/24/13 5:34 PM, Stuart Douglas
wrote:<br>
</div>
<blockquote
cite="mid:CAAoo=c53f-Vk8UfifgQBWT8cC+CnUS1=2qXrnqAnPx4OSSzM=A@mail.gmail.com"
type="cite">
<div dir="ltr">Something else I thought I should ask, has any
thought been given to how this would work in a clustered
environment?
<div><br>
</div>
<div>I would assume that most customers that would want this
would also want some form of HA for the jobs, if a single node
goes down you would not want all you batch jobs to grind to a
halt. </div>
<div><br>
</div>
<div>Stuart</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jul 24, 2013 at 11:25 PM,
Stuart Douglas <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div class="im">On Wed, Jul 24, 2013 at 8:14 PM, Cheng
Fang <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:cfang@redhat.com" target="_blank">cfang@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
<div>On 7/24/13 12:52 PM, Stuart Douglas
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I have also been looking at
this today, and there are quite a few
things in the code base that worry me
about its quality.
<div><br>
</div>
<div>1) JdbcRepository seems to save jobs
to the database but never seems to
actually load them again or remove them?
[1]</div>
</div>
</blockquote>
</div>
JdbcRepository is still work in progress, and is
currently not used yet.
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>2) Some things seem to be implemented
in a very inefficient manner, using
lists when a map or a set would be more
appropriate. For example <a
moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/JdbcRepository.java#L36"
target="_blank">i</a>n
AbstractJobRepository all jobs are
stored in a list, and as a result every
operation on the repo is O(n) on the
number of jobs. A map would be a far
more suitable data structure here. This
will be a real problem is a customer is
ever trying to scale to even a
moderately sized number of jobs and job
instances. <br>
</div>
</div>
</blockquote>
</div>
See my reply to previous message. Initially I
did implement it as a map, but didn't like
duplicating id as the key so changed it to
list. I don't expect the number of jobs to be
that large, or access to jobs to be a hot spot.
But I'm open to switch it since the feedback so
far has favored a mapping lookup.
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>3) Thread safety</div>
<div>Almost all objects in the code base
are mutable (i.e. no use of final), and
with a few exceptions most of the code
is not synchronized. From what I can see
not much thought has been given to
thread safety, and looking through the
code I think there are quite a few
places where there are the potential to
have threading issues. e.g. In [2],
where a list that is being modified
concurrently is returned to the caller.
The caller cannot safely use the list,
as it may be modified by another thread
as it is being iterated. There are other
places where I think there are the
potential for races, however I don't
know the code well enough to be sure. <br>
</div>
</div>
</blockquote>
</div>
If most of the code is synchronized, I would
also be worried<span><span> ;-) </span></span>.
But I agreeed, thread safety is the area we need
to look more closely as we integrate to
WildFly. In {2], what's your recommendation? to
always return a new list the the caller, which
seems a bit wasteful.</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
</div>
<div>You must either return a new list or use a
concurrent list as the backing data structure.</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Stuart</div>
</font></span>
<div>
<div class="h5">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>4) It looks like it has been
designed as a standalone project to be
embedded into a deployment, and no
thought has been given to how to
actually integrate it into Wildfly. I
know David already mentioned the
statics issue, but this is a big
problem. e.g. only one
jberet.properties will be loaded, so
if two applications have different
properties files then one will leak
into the other app, depending on the
current TCCL when the BatchConfig
class is first accessed. <br>
</div>
</div>
</blockquote>
</div>
jberet.properties is only for standalone
distro. For running in WildFly, all
configuration will be included in subsystem
configuration.<br>
<br>
Appreciate all the feedback!<span><font
color="#888888"><br>
<br>
Cheng</font></span>
<div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Stuart</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/JdbcRepository.java#L36"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/JdbcRepository.java#L36</a></div>
<div>[2] <a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/runtime/JobExecutionImpl.java#L134"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/runtime/JobExecutionImpl.java#L134</a></div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jul
24, 2013 at 6:09 PM, David M. Lloyd
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:david.lloyd@redhat.com"
target="_blank">david.lloyd@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">On initial
review of JBeret we have noticed a
number of issues that need<br>
to be addressed. The culmination
amounts to a series of questions
and<br>
observations here:<br>
<br>
#1) Why did we not choose to just
use the RI? In other words, what<br>
benefit do we get from JBeret that
is not also in the RI? In other,<br>
other words, why should we *use*
this code instead of the RI at
this<br>
point in time?<br>
<br>
#2) Why does JBeret duplicate
facilities already present in the
WildFly<br>
code base and deployer chain -
e.g. annotation indexing,
reflection<br>
indexing, thread management,
parsing facilities, etc.?<br>
<br>
#3) Specific to algorithmic
complexity - it appears that jobs
are keyed<br>
by ID, yet accessed using a
sequential search [1] - this does
not scale<br>
well to large numbers of jobs. Is
there no better approach?<br>
<br>
#4) JAXB seems to be being used to
parse XML, which is a departure
from<br>
all of our other services which
expect parsing to be done during<br>
deployment processing in a more
efficient manner. Is there any
better<br>
way we can integrate this,
preferably not using JAXB?<br>
<br>
#5) There are a number of
resources present that seem
inappropriate for<br>
the production JAR [2] [3]. Is
this intentional?<br>
<br>
#6) This code base makes extensive
use of static state, including
static<br>
fields that seem not to be
adequately protected for
thread-safety, and<br>
at least one static thread pool
[4]. This needs to be fixed, as
these<br>
kinds of things make embedding
difficult or impossible.<br>
<br>
[1]<br>
<a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/AbstractRepository.java#L50"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/AbstractRepository.java#L50</a><br>
[2]<br>
<a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resources/sql"
target="_blank">https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resources/sql</a><br>
[3]<br>
<a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resources/jobXML.xjb"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resources/jobXML.xjb</a><br>
[4]<br>
<a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/util/ConcurrencyService.java#L22"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/util/ConcurrencyService.java#L22</a><br>
<span><font color="#888888"><br>
--<br>
- DML<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org"
target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</font></span></blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
wildfly-dev mailing list
<a moz-do-not-send="true" href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org"
target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<br>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>