Q : Membuat background process di start melalui web app ?

[ardi_online]

guys...is this possible,

jadi aq bikin aplikasi background process not web app, but pas cari
hostingan eatj.com, tuh kan bisa nya web app or war....

ada g cara bikin supaya ni applikasi jadi web based...jad di UI web
pas di kilik start...seolah2 ngarah ke main method nya....jalan deh
background process nya...


is this silly question ?

sorry...just curious


dwi ardi irawan

[Suhendra Arianto]

Di eatj.com pake tomcat ya? Berarti ga ada service macem2, cuman
servlet & JSP doang.
Mungkin bisa coba kek gini:
Bikin class singleton yang extend thread, taruh task background nya di
method run.
Trus bikin JSP atau servlet sederhana aja buat mengontrol & memonitor
thread tsb.

Hendra.

--- In jug-indonesia@..., "ardi_online" <dwi.irawan@...>
wrote:

>
> guys...is this possible,
>
> jadi aq bikin aplikasi background process not web app, but pas cari
> hostingan eatj.com, tuh kan bisa nya web app or war....
>
> ada g cara bikin supaya ni applikasi jadi web based...jad di UI web
> pas di kilik start...seolah2 ngarah ke main method nya....jalan deh
> background process nya...
>

[wiradikusuma]

begitu klik start, langsung bikin thread. not silly :-)
(anda mungkin harus menyediakan flag untuk mencegah pembuatan thread  
lebih dari satu kali, misalnya karena tombolnya kepencet lebih dari 1x)

----
salam hangat,
Thomas Wiradikusuma
Follow me in Twitter! http://www.twitter.com/wiradikusuma
http://wiradikusuma.blogspot.com/2008/07/malikat-pencabut-nyawanya-thomas.html 
  <-- ternyata gw punya musuh :D




On 21 Jul 08, at 17:35, ardi_online wrote:

> guys...is this possible,
>
> jadi aq bikin aplikasi background process not web app, but pas cari
> hostingan eatj.com, tuh kan bisa nya web app or war....
>
> ada g cara bikin supaya ni applikasi jadi web based...jad di UI web
> pas di kilik start...seolah2 ngarah ke main method nya....jalan deh
> background process nya...
>
>
> is this silly question ?

[Frans Thamura-2]

setahu gue bisa pake quartz, CMIIW

F

[Suhendra Arianto]

Makanya, thread nya dibikin singleton. Trus pas mo ada yang mo start
thread lagi, dia ngecek apakah sudah ada thread yang lagi jalan dan
masih aktif (belum mati).

Quartz bukannya buat timer yah? keknya agak beda tujuannya.

--- In jug-indonesia@..., Thomas Wiradikusuma
<wiradikusuma@...> wrote:
>
> begitu klik start, langsung bikin thread. not silly :-)
> (anda mungkin harus menyediakan flag untuk mencegah pembuatan thread  
> lebih dari satu kali, misalnya karena tombolnya kepencet lebih dari 1x)
>

[wiradikusuma]

harus singleton ya.. trus bagaimana kalau maunya beda user bisa create thread?
(assuming business req change)

2008/7/22 Suhendra Arianto <suhe_arie@...>:
>
> Makanya, thread nya dibikin singleton. Trus pas mo ada yang mo start
> thread lagi, dia ngecek apakah sudah ada thread yang lagi jalan dan
> masih aktif (belum mati).


--
salam hangat,
Thomas Wiradikusuma
Follow me in Twitter! http://www.twitter.com/wiradikusuma
http://wiradikusuma.blogspot.com/2008/07/malikat-pencabut-nyawanya-thomas.html

[Arif Rachim]

Membuat thread dalam container itu sangat sangat sangat tidak dianjurkan.
Walaupun bisa tetapi dalam context servlet/ejb container, container lah yg
akan me manage thread lifecycle. Nah untuk mensolve kasus yg sama ini kita
bisa menggunakan alternatif lain, misalnya menggunakan jms atau menggunakan
quartz.

Kenapa sangat tidak dianjurkan,
1. Bisa membuka kemungkinan system tidak scalable.
2. Bisa membuka kemungkinan system tidak performant (orphan thread bisa
membuat server down)
dll ...

Regards,

2008/7/22 Thomas Wiradikusuma <wiradikusuma@...>:

>   begitu klik start, langsung bikin thread. not silly :-)
> (anda mungkin harus menyediakan flag untuk mencegah pembuatan thread
> lebih dari satu kali, misalnya karena tombolnya kepencet lebih dari 1x)
>
> ----
> salam hangat,
> Thomas Wiradikusuma
> Follow me in Twitter! http://www.twitter.com/wiradikusuma
>
> http://wiradikusuma.blogspot.com/2008/07/malikat-pencabut-nyawanya-thomas.html
> <-- ternyata gw punya musuh :D
>
>
> On 21 Jul 08, at 17:35, ardi_online wrote:
>
> > guys...is this possible,
> >
> > jadi aq bikin aplikasi background process not web app, but pas cari
> > hostingan eatj.com, tuh kan bisa nya web app or war....
> >
> > ada g cara bikin supaya ni applikasi jadi web based...jad di UI web
> > pas di kilik start...seolah2 ngarah ke main method nya....jalan deh
> > background process nya...
> >
> >
> > is this silly question ?
>  
>

[Suhendra Arianto]

Dibikin ga singleton.
Tiap thread dikasi nama (misal, pake userId). Bikin pool deh.
Tetep pake private constructor. Kalo udah ada thread dengan nama yang
sama lagi jalan, ga boleh create thread baru.

--- In jug-indonesia@..., "Thomas Wiradikusuma"
<wiradikusuma@...> wrote:
>
> harus singleton ya.. trus bagaimana kalau maunya beda user bisa
create thread?

> (assuming business req change)
>
> 2008/7/22 Suhendra Arianto <suhe_arie@...>:
> >
> > Makanya, thread nya dibikin singleton. Trus pas mo ada yang mo start
> > thread lagi, dia ngecek apakah sudah ada thread yang lagi jalan dan
> > masih aktif (belum mati).
>
>
> --
> salam hangat,
> Thomas Wiradikusuma
> Follow me in Twitter! http://www.twitter.com/wiradikusuma
>

http://wiradikusuma.blogspot.com/2008/07/malikat-pencabut-nyawanya-thomas.html
>

[Suhendra Arianto]

Ini mo dipasang di tomcat, yang ga ada JMSnya.
Kalo quartz, bukannya itu juga bikin thread sendiri. Cuman dia
bikinnya lebih rapi, jadi resiko kena deadlock atau server down lebih
kecil. Quartz juga keliatannya schedule based (mesti dijadwalin dulu),
bukan on-request gitu.

CMIIW...


--- In jug-indonesia@..., "Arif Rachim" <a.arif.r@...> wrote:
>
> Membuat thread dalam container itu sangat sangat sangat tidak
dianjurkan.
> Walaupun bisa tetapi dalam context servlet/ejb container, container
lah yg
> akan me manage thread lifecycle. Nah untuk mensolve kasus yg sama
ini kita
> bisa menggunakan alternatif lain, misalnya menggunakan jms atau
menggunakan

> quartz.
>
> Kenapa sangat tidak dianjurkan,
> 1. Bisa membuka kemungkinan system tidak scalable.
> 2. Bisa membuka kemungkinan system tidak performant (orphan thread bisa
> membuat server down)
> dll ...
>
> Regards,
>
> 2008/7/22 Thomas Wiradikusuma <wiradikusuma@...>:
>
> >   begitu klik start, langsung bikin thread. not silly :-)
> > (anda mungkin harus menyediakan flag untuk mencegah pembuatan thread
> > lebih dari satu kali, misalnya karena tombolnya kepencet lebih

dari 1x)
> >
> > ----
> > salam hangat,
> > Thomas Wiradikusuma
> > Follow me in Twitter! http://www.twitter.com/wiradikusuma
> >
> >
http://wiradikusuma.blogspot.com/2008/07/malikat-pencabut-nyawanya-thomas.html

> > <-- ternyata gw punya musuh :D
> >
> >
> > On 21 Jul 08, at 17:35, ardi_online wrote:
> >
> > > guys...is this possible,
> > >
> > > jadi aq bikin aplikasi background process not web app, but pas cari
> > > hostingan eatj.com, tuh kan bisa nya web app or war....
> > >
> > > ada g cara bikin supaya ni applikasi jadi web based...jad di UI web
> > > pas di kilik start...seolah2 ngarah ke main method nya....jalan deh
> > > background process nya...
> > >
> > >
> > > is this silly question ?
> >  
> >
>

[edward.yakop]

2008/7/22 Suhendra Arianto <suhe_arie@...>:
> Kalo quartz, bukannya itu juga bikin thread sendiri. Cuman dia
> bikinnya lebih rapi, jadi resiko kena deadlock atau server down lebih
> kecil.

This is correct.

> Quartz juga keliatannya schedule based (mesti dijadwalin dulu),
> bukan on-request gitu.

Kamu bisa schedule task to be executed now.
Untungnya kalo jumlah task > jumlah allocated thread, quartz bakal
execute the next task
as soon as threadnya available.

Regards,
Edward Yakop

[wiradikusuma]

ga juga.
ada beberapa kasus dimana penggunaan thread lebih baik (dan cepat)
ketimbang pakai solusi messaging atau quartz.
apalagi untuk environment yg sangat constrained seperti shared hosting.

2008/7/22 Arif Rachim <a.arif.r@...>:
> Membuat thread dalam container itu sangat sangat sangat tidak dianjurkan.
> Walaupun bisa tetapi dalam context servlet/ejb container, container lah yg
> akan me manage thread lifecycle. Nah untuk mensolve kasus yg sama ini kita
> bisa menggunakan alternatif lain, misalnya menggunakan jms atau menggunakan
> quartz.
>
> Kenapa sangat tidak dianjurkan,
> 1. Bisa membuka kemungkinan system tidak scalable.

kalau setiap node "bikin anak sendiri" (baca: mengelola threadnya
sendiri, ga distributable) untuk keperluan processing internalnya dan
tiap node tersebut saling independen, dimana ga salablenya?

> 2. Bisa membuka kemungkinan system tidak performant (orphan thread bisa
> membuat server down)

btw, contoh orphan thread itu seperti apa? dan bagaimana caranya
membuat server down?

--
salam hangat,
Thomas Wiradikusuma
Follow me in Twitter! http://www.twitter.com/wiradikusuma
http://wiradikusuma.blogspot.com/2008/07/malikat-pencabut-nyawanya-thomas.html

[ardi_online]

wow response nya bikin kaget...
thnx u guys for the information


bakal dicoba...semua opsi solution

thnx

dwi ardi irawan

[Arif Rachim]

2008/7/22 Thomas Wiradikusuma <wiradikusuma@...>:
> ga juga.
> ada beberapa kasus dimana penggunaan thread lebih baik (dan cepat)
> ketimbang pakai solusi messaging atau quartz.
> apalagi untuk environment yg sangat constrained seperti shared hosting.
>

Banyak issues yg terkadang bisa membuat problem misal kita membangun
aplikasi ShoppingCart, nah pada saat checkout kita memanggil thread
untuk menyelesaikan proses transaksi. thread tersebut akan validasi
Credit Card, dan sending message ke web service inventory. Nah
problemnya bisa muncul karena apa bila node tersebut down, pada saat
thread akan sending message ke web service inventory ini bisa
mengakibatkan problem. Karena di satu sisi user pikir dia sudah submit
request, servlet checkout sudah confirm tinggal menunggu status.
Tetapi statusnya ga pernah berubah, entah karena validasi CC gagal,
atau apapun ??. Nah design seperti ini sangat rentan, dan tidak
scalable. Ya bisa sih kalau developernya hati2 lagi, misalnya dia
simpen semua data kedalam database terlebih dahulu, nanti kalau node
itu down, dibuatkan lagi listener untuk melakukan proses update dengan
thread baru lagi. Atau berbagai macam cara lainnya, tetapi kan
objectivenya kita ingin dia scalable, kenapa kita pusing dengan
mencari2 solusi padahal sudah ada alternatifnya.

Kasus lainnya bisa jadi orphan thread, yaitu thread listening sesuatu
yg tdk kunjung sampai. Misal, kasus ShoppingCart diatas, servlet
checkout mengcreate thread, nah tetapi thread tersebut kemudian akan
mengirim message ke inventory jika proses validasi sukses. Nah karena
kita ingin aplikasi lebih cepat, kita buat 2 thread, 1 thread untuk
validasi CC, thread lainnya untuk sending message ke inventory. Nah
sending message ke inventory menunggu sampai status dari object
shopping cart confirmed dari database (* bukan design yg baik tetapi
banyak orang melakukan ini) nah karena status nya engga pernah update
thread sending inventory bisa jadi terus listening status dari
shopping cart object. Lagi2 ini bisa di cari solusinya misalkan si
thread 1 me lock object dari shopping cart, dan sehingga thread 2
tidak akan listening dari database. Tapi balik lagi cara ini bisa
mengakibatkan tidak scalable, balik ke point 1 diatas.

Best Regards

[sm96]

quartz bisa dibikin jalan on request.

2008/7/22 ardi_online <dwi.irawan@...>:

> wow response nya bikin kaget...
> thnx u guys for the information
>
> bakal dicoba...semua opsi solution
>
> thnx
>
> dwi ardi irawan
>
>

--
syaiful.mukhlis
gtalk:syaiful.mukhlis@...