From dev-return-1202-archive-asf-public=cust-asf.ponee.io@batchee.incubator.apache.org Wed Mar 21 17:01:16 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 30F1E180651 for ; Wed, 21 Mar 2018 17:01:16 +0100 (CET) Received: (qmail 99582 invoked by uid 500); 21 Mar 2018 16:01:15 -0000 Mailing-List: contact dev-help@batchee.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@batchee.incubator.apache.org Delivered-To: mailing list dev@batchee.incubator.apache.org Received: (qmail 99555 invoked by uid 99); 21 Mar 2018 16:01:14 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Mar 2018 16:01:14 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 23CF1C0144 for ; Wed, 21 Mar 2018 16:01:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.de Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id bjkajaxTM-E6 for ; Wed, 21 Mar 2018 16:01:10 +0000 (UTC) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id E76A45FD71 for ; Wed, 21 Mar 2018 16:01:09 +0000 (UTC) X-YMail-OSG: yQwLZbwVM1k8JobOh5RudFXrh4NYrBvWjrq4RasCkG8y5fweOntcJ6vc0JqhF5A w.WPfeX18D2wwFwVU.B2U_IO6ITD0N2LQicVC5kj5b.TcpWeP9sp13kEYp7uXw0GdeJeypJ_b09l BeIYQLdZw8pvFLAaFiRJPDyqL54dgrMzsagS4.HvH9dQFsTSoh6qdD.1WDeA9.DqRQdjAfFyGYfL mLVcx8Pf5OiJVTIhN4zikZ7n6TTnYOv0tzjXMI5fHpGt2T31q_LR4fr47IzYnBt.gVGfeVAPyS40 ImSCmtoG0ogLPeJuJ8gd4Hnp.rfjUGUaoM342MxbAsPT2zrypvS997UOB3Q80Ncu02CS.hc2AtkI 3Z0z4DMJX0E0d8MAUf6VHWdrGNls0ZyiMUuNobTnZCO9my0LSNK5imKmjTJ5iVv_fYZPY8qRyft7 SOy2JHpHxzUsL04uXp9gjhzeNX2WZTXzAR617wDUsVbParxzXM8FiDJjNR1cuvEIDf2W1kfPqg8R fh8U- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Wed, 21 Mar 2018 16:01:09 +0000 Date: Wed, 21 Mar 2018 16:00:59 +0000 (UTC) From: Mark Struberg To: BatchEE Dev BatchEE Dev Message-ID: <1393531522.4790777.1521648059367@mail.yahoo.com> In-Reply-To: References: <1219865623.4615849.1521635558050.ref@mail.yahoo.com> <1219865623.4615849.1521635558050@mail.yahoo.com> <52f86955-0bee-a0a0-a0a7-93ba764b7067@gmail.com> <1168585458.4657677.1521636274079@mail.yahoo.com> <682325482.4699357.1521641650515@mail.yahoo.com> Subject: Re: Java7? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4790776_1642672909.1521648059363" X-Mailer: WebService/1.1.11588 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 ------=_Part_4790776_1642672909.1521648059363 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Previous impl was shutdown the executor, wait a bit and > kill. Yes, and exactly that caused some troubles in production ;) Think about having a long running Batchlet. If you're lucky and do some DB = reads or other IO which checks for Threads then you will get an Interrupted= Exception and fall on your noose the bloody way.If not it might simply refu= se to stop. And then the container might do a hard kill after 5 minutes. The idea is that our Container integration could notify all actively runnin= g Batches to gracefully stop() before going forward to kill them. And while we have the container integration in TomEE and WebSphere it might= be good to have a portable way to do the same on standalone containers, ma= nually started batches, etc. LieGrue,strub =20 On Wednesday, 21 March 2018, 16:46:32 CET, Romain Manni-Bucau wrote: =20 =20 There are a few cases we can handle ourself probably: 1. standalone -> shutdown hook (ensuring we remove it properly if we shutdo= wn manually before the end)2. webapp -> we already do our job3. container -= > container should handle it for you and not batchee4. OSGi -> we don't hav= e an integration but the activator should do it So I think we are not bad and dont need to make JobOperator which is a prot= otype/request scope instancesomething which can impact the application (sco= pe). @Scott: idea from mark is to propagate stop to batchlets etc to try a grace= ful shutdown. Previous impl was shutdown the executor, wait a bit and kill. 2018-03-21 16:43 GMT+01:00 Scott Kurz : This is the first I can remember ever anyone mentioning standardizing a "stop" or "shutdown" of the batch runtime. I don't have much of an opinion at this point on whether it should be taken forward in the standard. Since we're talking about it, I am curious what does BatchEE do here? Does it issue stop() on all running jobs?=C2=A0 Does it wait for them to fi= nish? =C2=A0 Would you expect some exception for any JobOperator call after shutd= own (is it different depending on whether stop completes or not)?=C2=A0 (Presum= ably non-standard). Don't go through any great trouble answering..just throwing out some thoughts that might need to be answered. Scott On Wed, Mar 21, 2018 at 10:14 AM, Mark Struberg wrote: > Well, it's a design decision. This is about BATCHEE-131. > > With calling BatchRuntime.getJobOperator() we lazily start the > BatchRuntime. > > But currently there is no way to do a proper shutdown in a portable way! > The current shutdown relies on calling our _internal_ ThreadPoolService > SPI shutdown() method. > > Having the BatchRuntime implement AutoCloseable might be a good solution. > That means someone can code - in a totally portable way - the following t= o > stop the batch runtime: > > JobOperator jobOperator =3D BatchRuntime.getJobOperator(); > > if (jobOperator instanceof AutoCloseable) { >=C2=A0 =C2=A0((AutoCloseable) jobOperator).close(); > } > > Will commit that improvement soon. > > @Scott, do you think we should put this feature up for inclusion into the > JBatch-1.1 specification? > > LieGrue, > strub > > > On Wednesday, 21 March 2018, 13:48:56 CET, Romain Manni-Bucau < > rmannibucau@gmail.com> wrote: > > > +1 for java 8 as well today > > side note: we dont need it on job operator right? > > > Romain Manni-Bucau > @rmannibucau |=C2=A0 Blog > | Old Blog > | Github rmannibucau> | > LinkedIn | Book > ee-8-high-performance> > > 2018-03-21 13:44 GMT+01:00 Mark Struberg : > > > Hi Ioan! > > > > Also an option. But there are still servers with Java7 around.And we > still > > need to support it for TomEE7. > > We might add Java8 soon but then we'd also revisit the whole API I gues= s. > > We could probably drive this for an upcoming JBatch-1.1 specification. > > Anyway, thanks for your feedback, always welcome! > > > > LieGrue,strub > >=C2=A0 =C2=A0 On Wednesday, 21 March 2018, 13:37:14 CET, Ioan Eugen Stan= < > > stan.ieugen@gmail.com> wrote: > > > >=C2=A0 Hi, > > > > I'm a bit more progresist and move to Java 8 as baseline. > > > > https://plumbr.io/blog/java/ java-version-and-vendor-data- > > analyzed-2017-edition > > > > http://www.baeldung.com/java- in-2017 > > > > > > On 21.03.2018 14:32, Mark Struberg wrote: > > > Hi folks! > > > I just figured that BatchEE is still baseline 1.6. > > > Do we want to raise this to at least Java7? ^^ > > > Reason is that I want to use the AutoCloseable interface for proper > > shutdown of the JobOperator. > > > Any thoughts? > > > Going for TLP and batchee-1.0?well new thread ;) > > > LieGrue,strub > > > > > > > > > > =20 ------=_Part_4790776_1642672909.1521648059363--