Niky4000найди такой процесс.
Если это СУБД, то боюсь это противоречит её идеологии)))). Тут уже СУБД отвалится по таймауту.
Т.е. найди жизненный пример.
Формирование сложного отчёта с кучей join'ов, например, Jasper Report --> xls.
Может выполняться довольно-таки долго.
А почему это СУБД отвалится. Я, например, как-то писал хранимую процедуру, которая может неделю работать. Ничего не отваливалось.
Кстати, вот, поэкспериментировал:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
INFO: Hello!
INFO: Sat Nov 17 20:11:03 SAMT 2012 Hello World! 0
INFO: Hello!
INFO: Sat Nov 17 20:11:14 SAMT 2012 Hello World! 1
INFO: Sat Nov 17 20:11:20 SAMT 2012 Hello World! 0
INFO: Sat Nov 17 20:11:26 SAMT 2012 Hello World! 2
INFO: Sat Nov 17 20:11:32 SAMT 2012 Hello World! 1
INFO: Sat Nov 17 20:11:38 SAMT 2012 Hello World! 3
INFO: Sat Nov 17 20:11:42 SAMT 2012 Hello World! 2
INFO: Sat Nov 17 20:11:50 SAMT 2012 Hello World! 3
INFO: Hello!
INFO: Hello!
INFO: Server shutdown initiated
SEVERE: service exception
java.lang.RuntimeException: ClientAbortException: java.nio.channels.ClosedChannelException
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:246)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Caused by: ClientAbortException: java.nio.channels.ClosedChannelException
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:243)
... 18 more
Caused by: java.nio.channels.ClosedChannelException
at java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:194)
at java.nio.channels.SelectableChannel.register(SelectableChannel.java:277)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:141)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:417)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:489)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:467)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1276)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
... 21 more
INFO: JMX002: JMXStartupService: Stopped JMXConnectorServer: null
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
@Stateless
public class NewSessionBean implements NewSessionBeanLocal {
@Override
@Asynchronous
public void some() {
System.out.println("Hello!");
for(int j=0;j<4;j++){
for(int k=0;k<400;k++){
for(int i=0;i<10000000;i++){
String gg="";
}
}
System.out.println((new Date()).toString()+" Hello World! "+j);
}
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
newSessionBean.some();
...
....
...
...
} finally {
out.close();
}
}
Есть сервлет, который вызывает асинхронный newSessionBean.some(). Если убрать @Asynchronous, то вызов станет синхронным и браузер висит до тех пор, пока newSessionBean.some() не отпустит сервлет.
Что интересно, браузер сразу же отображает страничку, а в логах сервер идут "Hello World".
Я зашёл на страничку с сервлетом 2 раза и запустил 2 асинхронных потока, что видно в логах, которые независимо друг от друга выполняются, потом я запустил ещё 2 потока и тормознул сервер, как видно, мне это, в отличие от Message Driven Bean, ничто сделать не помешало!
Надо бы ещё поэкспериментировать с TimeOut'ами. Есть ли какие-то TimeOut'ы у этих асинхронных бинов.
Ну, вообще выглядит это всё проще. Вызов проще, работает как демон и не надо прописывать никаких ресурсов на сервере, в отличие от Message Driven Bean.
Ну и что будет если сеть отвалится?возьми дергани сетевой шнурок). Вообще я так и не понял что вам в итоге надо. Могу рассказать как сделано у нас нечть подобное, и может дам вам пищу для размышлений.
Во-первых такого понятия как стандартный таймаут в EJB и JMS-спеках нет, все это сугубо специфично для сервера, и обычно конфигурируемо. Если у вас приложение под определенный сервер(у нас WebLogic) - то сконфигурируйте jms b все ок - такой подход вполне нормален.
Во-вторых долгие асинхронные операции в рамках jms -это вполне нормальный подход.
В-третьих, я не понимаю что значит mdb мешает перестартовать сервер. Речь не может идти о продакшен сервере - так как на продакшен недопустиммо пускать непротестированный код, а если речь идет о локальном сервере или тестовом - команда kill вам всегда поможет. Тут есть один момент - чтобы не терять проделанную работу, надо проаналзировать задачу(долгий процесс) и определить safe-pointы, и когда процесс заработает то он должен с некоторым интервалом достигать этих сейфпоинтов, чтобы при следующем перезапуске начинать не с начала а с последенго сейфпоинта. А теперь кратко как это работает у нас -
Само приложение - это система по наблюдению за здоровьем людей. У нас есть огромное количество юзеров, которые постоянно ходят на фитнесс, проходят медобследования, проходят курсы по питанию и тп - все это приходит к нам в базу асинхронно через ESB, иногда с опозданием. Так вот ночью, когда самая маленькая загрузка у нас шедулится процесс -RecommendationProcess - именно как MDB, он делает следующее - подымает всех юзеров, у которых есть необработанные события. И в цикле анализирует каждого юзера и в итоге ставит ему диагноз или дает рекомендации. В данном случае сейфпоинт - это обработка одного конкретного юзера. То есть если даже вырубится электричество и тп - то мы рестартуем процесс и он обрабатывает только необработанных пользователей. Система работает уже 3 года - полет нормальный. Процесс длится 3-4 часа,завели специальную очередь для него.
