[JBoss Portal] - Hibernate Open Session In View (in Portlet)
by EricML
Hey. I'm using JBoss AS 4.2.2 GA with Portal 2.6.4 and running into problems with accessing objects in the view:
"Caused by: org.hibernate.LazyInitializationException: could not initialize proxy - no Session"
I am using the HibernateService deployed as HAR to retrieve objects in the processAction-Method of the GenericPortlet. The configuration of the Service is as follows (jboss-service.xml):
| <server>
| <mbean code="org.jboss.hibernate.jmx.Hibernate"
| name="ebal:name=SessionFactory">
| <attribute name="DatasourceName">java:/PortalDS</attribute>
| <attribute name="Dialect">
| org.hibernate.dialect.MySQLDialect
| </attribute>
| <attribute name="SessionFactoryName">
| java:/hibernate/SessionFactory
| </attribute>
| <attribute name="Hbm2ddlAuto">update</attribute>
| <attribute name="ShowSqlEnabled">true</attribute>
| <attribute name="ScanForMappingsEnabled">true</attribute>
| </mbean>
| </server>
|
The service uses the standard PortalDS which is bound to a transaction:
| <datasources>
| <local-tx-datasource>
| <jndi-name>PortalDS</jndi-name>
| <connection-url>jdbc:mysql://localhost:3306/jbossportal?useServerPrepStmts=false</connection-url>
| <driver-class>org.gjt.mm.mysql.Driver</driver-class>
| <user-name></user-name>
| <password></password>
| </local-tx-datasource>
| </datasources>
|
In the init()-Method of my Portlet I am retrieving the HibernateService:
| public void init(javax.portlet.PortletConfig config)
| throws PortletException {
| super.init(config);
| try {
| InitialContext ctx = new InitialContext();
| sessionFactory = (SessionFactory) ctx
| .lookup("java:/hibernate/SessionFactory");
| } catch (NamingException e) {
| throw new PortletException(e.getMessage());
| }
| };
|
and later in the processAction-Method I am retrieving some objects through sessionFactory.getCurrentSession() and store them in the PortalSession. This works fine for I retrieve the current session bound to the transaction. Btw, I have also included the transattribute in the jboss-portlet.xml:
| <portlet>
| <portlet-name>TestPortlet</portlet-name>
| <trans-attribute>Required</trans-attribute>
| </portlet>
|
Everything works fine so far until I try to access properties from objects in the portletSession in the view (jsp, through jstl) which are proxied through hibernate (lazy initialized). The session is already closed in the view and so is the transaction. Normally I would set a HibernateSession filter in the web.xml and open/close the session before/after the request in a standard struts/spring mvc webapplication and have the session open in view but I fear this will not work in a portlet environment.
I did browse through this forum and the web all the day but did not come to a conclusion how to achieve to hold the session/transaction open (and closed after the entire request).
Is there anyone who was running into the same problem? Maybe I miss something substantial because I could not find any solution to this very common problem? Is there a way to span the transaction around the view-rendering as well? Every help or hints are appreciated!
Regards,
Eric
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138913#4138913
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138913
18 years, 1 month
[JBoss jBPM] - Problem sending mails
by rodosa
Hello!!
I'm trying sending mails but I don't get it. I've tried two differents ways to do it.
1) Mail-node. It's code is:
| <mail-node name="Enviar notificacion" to="xxx(a)hotmail.com">
| <subject>
| Prueba
| </subject>
| <text>
| Prueba Jbpm
| </text>
| <transition to="Fin" name="t2"></transition>
| </mail-node>
|
and jbpm.cgf is
| <jbpm-configuration>
|
| <!--
| The default configurations can be found in org/jbpm/default.jbpm.cfg.xml
| Those configurations can be overwritten by putting this file called
| jbpm.cfg.xml on the root of the classpath and put in the customized values.
| -->
|
| <string name="jbpm.mail.smtp.host" value="smtp.xxx.es" />
| <bean name="jbpm.mail.address.resolver" class="org.jbpm.identity.mail.IdentityAddressResolver" singleton="true" />
|
| <string name="jbpm.mail.user" value="xxx" />
| <string name="jbpm.mail.pass" value="xxx" />
| <string name="jbpm.mail.from.address" value="xxx(a)gmail.com"/>
| <string name="jbpm.mail.port" value="25" />
| <string name="jbpm.mail.smtp.auth" value="true" />
| <string name="jbpm.mail.debug" value="true" />
|
|
| </jbpm-configuration>
|
|
It doesn't work. If I put the jbpm.mail.smtp.auth a true the authentication fail, and if I put it to false the error is this:
| Recipient address rejected: Access denied 554 + "Invalid Addresses"
|
2) The second way is declare a node in which handler I try to send a mail. But occurs the similar problem:
| package handlers;
|
| import java.util.ArrayList;
| import java.util.List;
| import java.util.Properties;
|
| import org.jbpm.JbpmConfiguration;
| import org.jbpm.graph.def.ActionHandler;
| import org.jbpm.graph.exe.ExecutionContext;
| import org.jbpm.mail.Mail;
|
|
| public class MyMailAction implements ActionHandler {
|
| private static final long serialVersionUID = 1L;
|
| public void execute(ExecutionContext context) throws Exception {
| System.out.println("---->>>Estoy en execution context");
|
| try {
| JbpmConfiguration.Configs.getObject("jbpm.mail.smtp.host");
| Properties p = new Properties();
| p.put("mail.smtp.host", JbpmConfiguration.Configs.getObject("jbpm.mail.smtp.host"));
| //p.put("mail.smtp.port", JbpmConfiguration.Configs.getObject("jbpm.mail.port"));
| p.put("mail.smtp.auth", JbpmConfiguration.Configs.getObject("jbpm.mail.smtp.auth"));
| p.put("mail.smtp.user", JbpmConfiguration.Configs.getObject("jbpm.mail.user"));
| p.put("mail.smtp.password", JbpmConfiguration.Configs.getObject("jbpm.mail.pass"));
| p.put("mail.debug", JbpmConfiguration.Configs.getObject("jbpm.mail.debug"));
| p.put("mail.from.address", JbpmConfiguration.Configs.getObject("jbpm.mail.from.address"));
| p.put("mail.class.name", JbpmConfiguration.Configs.getObject("mail.class.name"));
| List l = new ArrayList();
| l.add("xxxx(a)hotmail.com");
| Mail.send(p, "sss(a)gmail.com",l, "The subject", "The text");
| } catch (Exception e ) {
| e.printStackTrace();
| }
| System.out.println("---->>>Estoy en execution context");
| }
|
|
| }
|
I realized that exist mail-service.xml ... It's using this file. How can I dolve this?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138905#4138905
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138905
18 years, 1 month
[JBoss Messaging] - Failover on clustered queues causes thread leak
by lerdek
Hi,
We have a setup of 2 clustered JBoss servers with clustered messaging with ~150 clustered queues (including EQs and DLQs). If we 'kill -9' one of the nodes, the failover mechanism kicks in, but it creates ~200 new threads which are all in a WAITING state. These threads keep waiting forever, and on every failover this happens again (thus, every failover increases the active thread count of the surviving node by ~200).
Since we still run on a Linux 2.4 kernel, with a practical upper thread count limit of ~600, this is a big problem because if a single node fails for 1 or 2 times, the 'surviving' node dies as a consequence, basically eliminating the concept of a failover mechanism.
We would be very thankful for suggestions on how we can fix this, what appears to be a thread leak.
We have observed already the following things:
| Active thread count before failover: ~150
| Active thread count after 1 failover: ~350
| Active thread count after 2 failovers: ~550
| The active thread count does not decrease over time (it seems the threads are blocked forever)
| Failover scenario without clustered JBoss Messaging is without any apparent thread leak problem
| Failover scenario with only 3 clustered queues is with the thread leak problem, but at a much lower rate (~5 threads per failover) so it appears that the thread leak is linear with the number of clustered queues.
|
|
| At the moment it is not an option to upgrade our kernel to 2.6, which would in fact only reduce the frequency of the symptoms, but not fix the problem. Also, we cannot use a multicast protocol stack because it is not supported on our production environment.
|
| Here's our configuration for both clsutered messaging nodes, which are dedicated messaging servers (thus, no other custom applications have been deployed):
|
|
| | JBoss AS 4.2.2.GA
| | JBoss Messaging 1.4.0sp3
| | JGroups 2.4.1 SP-4
| |
|
| After a failover, a lot of increasingly numbered threads are lying around that look like this (only the thread-name-number differs, e.g. after 1 failover it goes to Thread-274, after 2 failovers to Thread-473):
|
|
| | Thread: Thread-50 : priority:5, demon:true, threadId:268, threadState:WAITING, lockName:java.lang.Object@62685f
| |
| | java.lang.Object.wait(Native Method)
| | java.lang.Object.wait(Object.java:474)
| | EDU.oswego.cs.dl.util.concurrent.LinkedQueue.take(LinkedQueue.java:122)
| | EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:83)
| | java.lang.Thread.run(Thread.java:595)
| |
| |
|
| Here's the output of the JMX bean jboss.system/ServerInfo of the surviving node after 2 consequetive failovers:
|
|
| | HostAddress java.lang.String R 192.168.86.9 MBean Attribute.
| | AvailableProcessors java.lang.Integer R 1 MBean Attribute.
| | OSArch java.lang.String R i386 MBean Attribute.
| | OSVersion java.lang.String R 2.4.27-vmware-k7-nosmp MBean Attribute.
| | HostName java.lang.String R xxx MBean Attribute.
| | JavaVendor java.lang.String R Sun Microsystems Inc. MBean Attribute.
| | JavaVMName java.lang.String R Java HotSpot(TM) Server VM MBean Attribute.
| | FreeMemory java.lang.Long R 87777680 MBean Attribute.
| | ActiveThreadGroupCount java.lang.Integer R 10 MBean Attribute.
| | TotalMemory java.lang.Long R 166629376 MBean Attribute.
| | JavaVMVersion java.lang.String R 1.5.0_07-b03 MBean Attribute.
| | ActiveThreadCount java.lang.Integer R 548 MBean Attribute.
| | JavaVMVendor java.lang.String R Sun Microsystems Inc. MBean Attribute.
| | OSName java.lang.String R Linux MBean Attribute.
| | JavaVersion java.lang.String R 1.5.0_07 MBean Attribute.
| | MaxMemory java.lang.Long R 265486336 MBean Attribute.
| |
|
| Our JGroups protocol stack is the following (for both JBoss cluster, and JBoss Messaging cluster Post-office data and control channel):
|
|
| | STATE_TRANSFER
| | use_flush=false
| | up_thread=false
| | down_thread=false
| |
| | GMS
| | shun=true
| | print_local_addr=true
| | up_thread=false
| | view_bundling=true
| | join_timeout=3000
| | join_retry_timeout=2000
| | down_thread=false
| |
| | STABLE
| | max_bytes=400000
| | up_thread=false
| | stability_delay=1000
| | desired_avg_gossip=50000
| | down_thread=false
| |
| | NAKACK
| | max_xmit_size=60000
| | up_thread=false
| | retransmit_timeout=300,600,1200,2400,4800
| | use_mcast_xmit=false
| | discard_delivered_msgs=true
| | down_thread=false
| | gc_lag=0
| |
| | VERIFY_SUSPECT
| | up_thread=false
| | timeout=1500
| | down_thread=false
| |
| | FD
| | max_tries=5
| | shun=true
| | up_thread=false
| | timeout=10000
| | down_thread=false
| |
| | FD_SOCK
| | up_thread=false
| | down_thread=false
| |
| | MERGE2
| | max_interval=10000
| | up_thread=false
| | down_thread=false
| | min_interval=2000
| |
| | TCPPING
| | port_range=3
| | num_initial_members=13
| | up_thread=false
| | initial_hosts=j2msgtest1[8800],j2msgtest2[8800]
| | timeout=3000
| | down_thread=false
| |
| | TCP
| | discard_incompatible_packets=true
| | sock_conn_timeout=300
| | enable_bundling=false
| | bind_addr=192.168.86.201
| | max_bundle_size=64000
| | use_outgoing_packet_handler=false
| | use_send_queues=false
| | down_thread=false
| | start_port=8800
| | recv_buf_size=20000000
| | skip_suspected_members=true
| | send_buf_size=640000
| | use_incoming_packet_handler=true
| | loopback=true
| | up_thread=false
| | tcp_nodelay=true
| | max_bundle_timeout=30
| |
|
| Thank you in advance!
|
| With regards,
|
| Thijs Reus
| Click&Buy Services AG
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138904#4138904
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138904
18 years, 1 month