[jBPM] New message: "Re: Unable to set the mail configuration properties in JBPM 4.0"
by Anand Kumar
User development,
A new message was posted in the thread "Unable to set the mail configuration properties in JBPM 4.0":
http://community.jboss.org/message/520980#520980
Author : Anand Kumar
Profile : http://community.jboss.org/people/akstifr
Message:
--------------------------------------------------------------
Still i am unable to send the mail from my application as the configuration file settings are not able to find it
it is giving the following error message:
12:47:04,875 INFO [DefaultCommandService] exception while executing command org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd@253bbd
org.jbpm.api.JbpmException: could not send email: javax.mail.internet.MimeMessage@1d8bad2
at org.jbpm.pvm.internal.email.impl.MailSessionImpl.send(MailSessionImpl.java:60)
at org.jbpm.jpdl.internal.activity.MailActivity.perform(MailActivity.java:44)
at org.jbpm.jpdl.internal.activity.JpdlAutomaticActivity.execute(JpdlAutomaticActivity.java:15)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:637)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:597)
at org.jbpm.pvm.internal.model.ExecutionImpl.start(ExecutionImpl.java:201)
at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:64)
at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:37)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceByKey(ExecutionServiceImpl.java:66)
at com.LeaveController.startNewProcessInstance(LeaveController.java:35)
at com.Leave.doPost(Leave.java:56)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.mail.MessagingException: Could not connect to SMTP host: localhost, port: 25;
nested exception is:
java.net.ConnectException: Connection refused: connect
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1282)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:370)
at javax.mail.Service.connect(Service.java:275)
at javax.mail.Service.connect(Service.java:156)
at javax.mail.Service.connect(Service.java:105)
at org.jbpm.pvm.internal.email.impl.MailSessionImpl.send(MailSessionImpl.java:50)
... 37 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:232)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:189)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1250)
... 42 more
12:47:04,875 INFO [STDOUT] could not send email: javax.mail.internet.MimeMessage@1d8bad2
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520980#520980
16 years, 3 months
[JBoss Remoting] New message: "Re: Client hangs when get JMS connection factory"
by mingjun jiang
User development,
A new message was posted in the thread "Client hangs when get JMS connection factory":
http://community.jboss.org/message/520979#520979
Author : mingjun jiang
Profile : http://community.jboss.org/people/mjjiangbhr
Message:
--------------------------------------------------------------
> mailto:ron.sigal@jboss.com 编写:
>
> > mjjiangbhr wrote:
> >
> >
> > If we set the timeout value to a non-zero value, and if there is no message in topic/queue in server side, then the remote client (message listener) won't receive any message, that mean the connection between client and server is idle, if the idle duration exceeds the non-zero "timeout" value, then the JBM will forcibly close the connection, so the remoting client won't receive any subsequent messages from server any more......
>
> Like I said, I don't know enough about JBossMessaging to comment. Why does JBM close the connection? And if JBM closes the connection, why should the Remoting client continue to receive messages?
>
> Maybe you should move this discussion back to the Messaging forum.
>
> -Ron
Actually I had already posted the same article on JBoss Messaging Forum: http://community.jboss.org/thread/129740?tstart=0, but nobody commented on it so far. I had also submitted a JIRA issue on JBossMessage: https://jira.jboss.org/jira/browse/JBMESSAGING-1763, but no any comments as well.
I thought this issue should be caused by either JBoss Remoting or JBoss Messaging, so I post the same question onto 2 forums. Anyway, Ron, thanks for your kindly help.
http://community.jboss.org/thread/129740?tstart=0
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520979#520979
16 years, 3 months
[JBoss Remoting] New message: "Re: Client hangs when get JMS connection factory"
by Ron Sigal
User development,
A new message was posted in the thread "Client hangs when get JMS connection factory":
http://community.jboss.org/message/520975#520975
Author : Ron Sigal
Profile : http://community.jboss.org/people/ron.sigal@jboss.com
Message:
--------------------------------------------------------------
> mjjiangbhr wrote:
>
>
> If we set the timeout value to a non-zero value, and if there is no message in topic/queue in server side, then the remote client (message listener) won't receive any message, that mean the connection between client and server is idle, if the idle duration exceeds the non-zero "timeout" value, then the JBM will forcibly close the connection, so the remoting client won't receive any subsequent messages from server any more......
Like I said, I don't know enough about JBossMessaging to comment. Why does JBM close the connection? And if JBM closes the connection, why should the Remoting client continue to receive messages?
Maybe you should move this discussion back to the Messaging forum.
-Ron
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520975#520975
16 years, 3 months
[JBoss Remoting] New message: "Re: Client hangs when get JMS connection factory"
by mingjun jiang
User development,
A new message was posted in the thread "Client hangs when get JMS connection factory":
http://community.jboss.org/message/520969#520969
Author : mingjun jiang
Profile : http://community.jboss.org/people/mjjiangbhr
Message:
--------------------------------------------------------------
> mailto:ron.sigal@jboss.com 编写:
>
> Hi guys,
>
> I've done some experimentation and it looks like we're both right. I was right that ConnectionValidator correctly detects and reports a connection failure when the ethernet cable is pulled. That should be true for any recent version of Remoting, either 2.2.x or 2.5.x. When ConnectionValidator tells JBossMessaging about the failure, JBM should close the connection, which should lead to a call to MicroSocketClientInvoker.handleDisconnect() in Remoting. Now, MicroSocketClientInvoker.handleDisconnect() closes all inactive sockets, but it doesn't close sockets that are currently involved in an invocation. That's why the number of sockets doesn't go to zero when "timeout" is set to 0. But if "timeout" is set to a non-zero value, these active sockets will time out and get closed.
>
> By the way, there has been some discussion about changing the default "timeout" configuration in remoting-bisocket-service.xml to a non-zero value.
>
> -Ron
Ron, yes, in the original post, my colleague Li Lin had already said a non-zero timeout value will close the failure sockets. If you keep the timeout value as 0 (default value), the number of sockets won't go to zero. But if we change the timeout to a non-zero value, it will cause other issue just what I said previously
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520969#520969
16 years, 3 months
[JBoss Remoting] New message: "Re: Client hangs when get JMS connection factory"
by mingjun jiang
User development,
A new message was posted in the thread "Client hangs when get JMS connection factory":
http://community.jboss.org/message/520968#520968
Author : mingjun jiang
Profile : http://community.jboss.org/people/mjjiangbhr
Message:
--------------------------------------------------------------
> mjjiangbhr 编写:
>
> Hello Rakesh.
>
> According to your description of test procedure, you are using the kill client appliction using Task Manager, instead of pulling the network cable. Just as what I said in previous post, the connectionValidator could work correctly when killing client application, but it cannot work well when pulling network cable, the two test result (killing client application via Task manager vs. pulling network cable) is different! Could you test the scenario of pulling network cable?
>
> Regards
Oops，Rakesh, please ignore my message above. I made a mistake, I wrongly treat you as Ron, sorry
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520968#520968
16 years, 3 months
[JBoss Remoting] New message: "Re: Client hangs when get JMS connection factory"
by Ron Sigal
User development,
A new message was posted in the thread "Client hangs when get JMS connection factory":
http://community.jboss.org/message/520966#520966
Author : Ron Sigal
Profile : http://community.jboss.org/people/ron.sigal@jboss.com
Message:
--------------------------------------------------------------
> mjjiangbhr wrote:
>
> actually, the changing of timeout value doesn't solve our problem, the changing of timeout value incurred another issue: you know, if there is no message in topic/queue in server side, then the remote client (message listener) won't receive any message, that mean the connection is idle, if the idle duration exceeds the "timeout" value, then the JBM will forcibly close the connection, so the remoting client won't receive any subsequent messages any more, it's a serious problem!
>
I don't know enough about JBossMessaging to comment. Can you elaborate?
-Ron
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520966#520966
16 years, 3 months
[JBoss Remoting] New message: "Re: Client hangs when get JMS connection factory"
by Ron Sigal
User development,
A new message was posted in the thread "Client hangs when get JMS connection factory":
http://community.jboss.org/message/520965#520965
Author : Ron Sigal
Profile : http://community.jboss.org/people/ron.sigal@jboss.com
Message:
--------------------------------------------------------------
Hi guys,
I've done some experimentation and it looks like we're both right. I was right that ConnectionValidator correctly detects and reports a connection failure when the ethernet cable is pulled. That should be true for any recent version of Remoting, either 2.2.x or 2.5.x. When ConnectionValidator tells JBossMessaging about the failure, JBM should close the connection, which should lead to a call to MicroSocketClientInvoker.handleDisconnect() in Remoting. Now, MicroSocketClientInvoker.handleDisconnect() closes all inactive sockets, but it doesn't close sockets that are currently involved in an invocation. That's why the number of sockets doesn't go to zero when "timeout" is set to 0. But if "timeout" is set to a non-zero value, these active sockets will time out and get closed.
By the way, there has been some discussion about changing the default "timeout" configuration in remoting-bisocket-service.xml to a non-zero value.
-Ron
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520965#520965
16 years, 3 months