[Installation, Configuration & DEPLOYMENT] - JBoss 4.2.2 + Hibernate 3 + OpenLaszlo
by gigsvoo
Hi there,
When I deploy Hibernate 3 into JBoss AS 4.2.2 I had set using JBoss classloader instead of Tomcat classloader as described http://opensource.atlassian.com/projects/hibernate/browse/HHH-579as follows:
$JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml
from Java2ClassLoadingCompliance of "UseJbossWebLoader"
After done that Openlaszlo refuse to run and providing the following exception:
| 10:36:04,997 INFO [[/URESDemoWeb]] LPS: throwable: (class: org/openlaszlo/data/
| HTTPDataSource, method: getDataOnce signature: (Ljavax/servlet/http/HttpServletR
| equest;Ljavax/servlet/http/HttpServletResponse;JLjava/lang/String;II)Lorg/openla
| szlo/data/HTTPDataSource$HttpData;) Incompatible object argument for function ca
| ll
| 10:36:05,001 INFO [[/URESDemoWeb]] LPS: javax.servlet.ServletException: java.la
| ng.VerifyError: (class: org/openlaszlo/data/HTTPDataSource, method: getDataOnce
| signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServl
| etResponse;JLjava/lang/String;II)Lorg/openlaszlo/data/HTTPDataSource$HttpData;)
| Incompatible object argument for function call
| at org.openlaszlo.servlets.LZServlet.getResponder(Unknown Source)
| at org.openlaszlo.servlets.LZServlet.initLPS(Unknown Source)
| at org.openlaszlo.servlets.LZServlet.doGet(Unknown Source)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
| icationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
| ilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
| lter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
| icationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
| ilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
| alve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
| alve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
| yAssociationValve.java:179)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
| e.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
| ava:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
| ava:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
| onnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
| ve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
| a:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
| :844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
| ss(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
| 6)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: java.lang.VerifyError: (class: org/openlaszlo/data/HTTPDataSource, me
| thod: getDataOnce signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/serv
| let/http/HttpServletResponse;JLjava/lang/String;II)Lorg/openlaszlo/data/HTTPData
| Source$HttpData;) Incompatible object argument for function call
| at org.openlaszlo.servlets.responders.ResponderCache.init(Unknown Source
| )
| at org.openlaszlo.servlets.responders.ResponderMEDIA.init(Unknown Source
| )
| ... 23 more
|
Any ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148720#4148720
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148720
16 years, 4 months
[Clustering/JBoss] - Providing Safe Buddly Replication Failover
by dmurphy
Hi - these question relate to establishing the safe operation of buddy replication under AS 4.0.5.
Selection of Buddies
Say we have nodes a1, a2 and a3 and they are booted in that order. What we see is that when a2 starts it forms a buddy pair with a1. Then when a3 starts a1 becomes the backup for a3. So in this scenario a1 is backing up two nodes and a3 is backing up zero nodes.
So the memory utilization across the nodes is unbalanced. (we now have logging around the session replication listener to analyse this behaviour)
This seems to be broken. Is this the way buddy replication should select buddies or do we have a config problem somewhere? What we need is that each node has the same amount of backup work (memory, cpu etc) overhead to even the load of providing replication across the cluster.
Failover Operation
Having read the JBOSS doc I still need to understand more about the basic operation of failover. Currently we have no replication so if an app server node goes down we loose ~25% of users but the other 75% stays pretty operational. In practice, we will have a cluster of 6 app servers and during peak times we would see 2000-3000 users per node. 18K concurrent users in all.
What I am concerned about using buddy replication is that if a node goes down we could send other nodes down as well as they have to rapidly take over the work of the node that failed (a sort of domino affect). After reading the doc I still dont have a solid understanding of how this process works or the risks we might have.
Assume a2 backs up a1, a3 backs up a2 and a1 backs up a3. This is buddy replication with one backup buddy. All nodes are fronted by an F5 load balancer that provides sticky sessions and will redirect a user to a random node if the node with its original session fails.
So what, in detail, happens if a1 goes down? After the failure of a1 the F5 will direct Some of a1's users to a2 and some to a3.
1) How does the cluster determine who is the new primary owner of a1's session data? Hopefully it will decide to use a2 since it already has a copy of a1's session cache.
2) For users directed to a3 by the F5 - how does a3 now populate its session cache to service those newly arriving users.
3) I assume the cluster also now picks a new buddy for a3 since it lost its buddy a1. In this case it will have to be a2 since there are no other nodes. So question is - what is the impact (network, cpu etc) on a2 and a3 to establish a2 as the new buddy relationship is established. What we are worried about is that both a2 and a3 now suddenly have a large group of new users to support as well as taking the resource hit to replicate each others session state.
Failover Best Practices
What are the buddy replicatoon 'best practices' that we should follow to provide safe and reliable failover in a heavily loaded cluster?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148704#4148704
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148704
16 years, 4 months
[Messaging, JMS & JBossMQ] - Re: Monitoring the number of messages in a queue from the co
by pgbossi
Replying to myself for the benefit of others: I can't make it to work over the net, at least between windows and linux machines, but the following works perfectly fine if run directly on the server.
[root@fakehost bin]# ./twiddle.sh -u admin -p XXXXX get "jboss.mq.destination:service=Queue,name=QUEUE-XXX" QueueDepth
| QueueDepth=0
| [root@fakehost bin]# ./twiddle.sh -u admin -p XXXXX get "jboss.mq.destination:service=Queue,name=QUEUE-YYY" QueueDepth
| QueueDepth=0
| [root@fakehost bin]# ./twiddle.sh -u admin -p XXXXX get "jboss.mq.destination:service=Queue,name=QUEUE-YYY" SubscribersCount
| SubscribersCount=10
| [root@fakehost bin]# ./twiddle.sh -u admin -p XXXXX get "jboss.mq.destination:service=Queue,name=QUEUE-XXX" SubscribersCount
| SubscribersCount=10
The attribute SubscribersCount tells you how many subscribers are listening on the queue, while QueueDepth tells you how many messages are currently in the queue.
HTH
Giuliano
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148694#4148694
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148694
16 years, 4 months
jboss multiple instances - error
by Sailaja Janaswamy
Hi
I tried to create a second instance of jboss(v4.0.5 GA) on a Unix server.
When I try to deploy my application, I get the following errors -
--- Packages waiting for a deployer ---org.jboss.deployment.DeploymentInfo@1fb71ed8 { url=file:/opt/local/jboss-4.0.5.GA/server/CARP2/deploy/http-invoker.sar/invoker.war/ } deployer: null status: Starting state: INIT_WAITING_DEPLOYER watch: file:/opt/local/jboss-4.0.5.GA/server/CARP2/deploy/http-invoker.sar/invoker.war/ altDD: null lastDeployed: 1209923732269 lastModified: 1209472720000 mbeans:
org.jboss.deployment.DeploymentInfo@6cbd34c7 { url=file:/opt/local/jboss-4.0.5.GA/server/CARP2/deploy/jbossweb-tomcat55.sar/ROOT.war/ } deployer: null status: Starting state: INIT_WAITING_DEPLOYER watch: file:/opt/local/jboss-4.0.5.GA/server/CARP2/deploy/jbossweb-tomcat55.sar/ROOT.war/ altDD: null lastDeployed: 1209923732273 lastModified: 1209472717000 mbeans:
org.jboss.deployment.DeploymentInfo@f1e170c5 { url=file:/opt/local/jboss-4.0.5.GA/server/CARP2/deploy/jbossws14.sar/jbossws-context.war } deployer: null status: Starting state: INIT_WAITING_DEPLOYER watch: file:/opt/local/jboss-4.0.5.GA/server/CARP2/deploy/jbossws14.sar/jbossws-context.war altDD: null lastDeployed: 1209923732277 lastModified: 1209923731000 mbeans:
org.jboss.deployment.DeploymentInfo@4e66f758 { url=file:/opt/local/jboss-4.0.5.GA/server/CARP2/deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/ } deployer: null
.
.
.
Can anyone tell me what the problem could be ...
Thanks
Sailaja
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
16 years, 4 months
[JBoss Portal] - 2.6.4 bundle : resp.signOut() raise an exception
by PMN
Version used : 2.6.4 bundle
resp.signOut();
resp is a JBossActionResponse
Question : How to sign out then?
| exception
|
| javax.servlet.ServletException: java.lang.IllegalArgumentException
| org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:276)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
|
|
| cause mère
|
| java.lang.IllegalArgumentException
| org.jboss.portal.core.controller.command.response.SignOutResponse.<init>(SignOutResponse.java:45)
| org.jboss.portal.core.controller.portlet.ControllerResponseFactory.createResponse(ControllerResponseFactory.java:124)
| org.jboss.portal.core.controller.portlet.ControllerResponseFactory.createActionResponse(ControllerResponseFactory.java:87)
| org.jboss.portal.core.model.portal.command.action.InvokePortletWindowActionCommand.execute(InvokePortletWindowActionCommand.java:177)
| org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
| org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:56)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:133)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:78)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:56)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
| org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
| org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:134)
| org.jboss.portal.core.controller.Controller.processCommand(Controller.java:235)
| org.jboss.portal.core.controller.Controller.handle(Controller.java:217)
| org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
| org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:246)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
| org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
| org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
| org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
| org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
| org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
| org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
| org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
| org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
| org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
| org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:250)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148689#4148689
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148689
16 years, 4 months