Re: [jboss-user] [Performance Tuning] - Configuration of Datasource: min-pool-size and max-pool-size
by Ruchir Choudhry
Ruchir Choudhry [http://community.jboss.org/people/ruchirc] replied to the discussion
"Configuration of Datasource: min-pool-size and max-pool-size"
To view the discussion, visit: http://community.jboss.org/message/555973#555973
--------------------------------------------------------------
+Hello Emili,+
+
+
+Max and Min connection size can become counter productive if not+ +set properly++, as when the server starts it reserves the connection(Handle) to the DB in active state.Its also consumes resources as more thread is allocated to the server and hence more objects is on the stack and hence it will use more RAM/CPU. You need to also check the max connections allowed in the DB. Please check the timeout for these connections too.+
+
+
+Its a good practice to start with a lowere number, like 10 min and 60 max, see how the system behaves.+
+
+
+You have also mentioned that you have 50 concurrent users: In response to that, the algorithm in the J2EE container dose the hashing and rehashing of the connections, some times it reuses the connections too, its also dependent on DB connection timeout both from J2EE container and from the DB.+
+
+
+Thus you have to check all these before coming to a right configuration.+
+Let me know if you are not cleare with anything
+
+
+
+Thank You,+
+Ruchir+
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/555973#555973]
Start a new discussion in Performance Tuning at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Web Services] - JAXB Error when deploying a JAX-WS WS based on top down
by max tomlinson
max tomlinson [http://community.jboss.org/people/finbarr] created the discussion
"JAXB Error when deploying a JAX-WS WS based on top down"
To view the discussion, visit: http://community.jboss.org/message/555959#555959
--------------------------------------------------------------
Hi All-
I am having a problem trying to deploy a JAX-WS webservice in Jboss 4.2 (Jboss native 2.0.1). I created artifcacts fromt he wsdl, jarred them up and included in the distribution.
My code (built from wsconsume-I had a glitch here BTW; the imported wsdl generated errors on soap fault extensions - I commented them out in order to get the JAX-WS artifacts )
import javax.jws.WebMethod;
import javax.jws.WebService;
import org.oasis_open.docs.wsn.b_2.Notify;
import org.oasis_open.docs.wsn.bw_2.NotificationConsumer;
@Stateless
@WebService(name="PmNotificationConsumerService", serviceName="PmNotificationConsumerService")
public class PmNotificationConsumerService implements PmNotificationConsumerServiceRemote {
@WebMethod
public void notify(Notify notify) {
System.out.println("PmNotificationConsumerService notify received: "
+ notify.getNotificationMessage());
}
When I deploy I get the following: I know the errors concern the document I am working with but am not familair with JAXB to understand them.
One question I do have: do I need to deploy wsdl and schema as well? e.g. in the WEB-INF/wsdl/ dir?
many thanks
Max
07:53:51,429 ERROR [MainDeployer] Could not start deployment: file:/opt/jboss/jboss-4.2.2.GA/server/default/deploy/cps.ear/cps.jar/
java.lang.IllegalStateException: Cannot build JAXB context
at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilder.createJAXBContext(JAXWSMetaDataBuilder.java:925)
at org.jboss.ws.metadata.builder.jaxws.JAXWSWebServiceMetaDataBuilder.buildWebServiceMetaData(JAXWSWebServiceMetaDataBuilder.java:146)
at org.jboss.ws.metadata.builder.jaxws.JAXWSServerMetaDataBuilder.setupProviderOrWebService(JAXWSServerMetaDataBuilder.java:50)
at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderEJB3.buildMetaData(JAXWSMetaDataBuilderEJB3.java:78)
at org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect.create(UnifiedMetaDataDeploymentAspect.java:71)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115)
at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy34.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:595)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
javax.xml.namespace.QName does not have a no-arg default constructor.
this problem is related to the following location:
at javax.xml.namespace.QName
at protected java.util.List org.oasis_open.docs.wsn.b_2.InvalidFilterFaultType.unknownFilter
at org.oasis_open.docs.wsn.b_2.InvalidFilterFaultType
at public org.oasis_open.docs.wsn.b_2.InvalidFilterFaultType org.oasis_open.docs.wsn.b_2.ObjectFactory.createInvalidFilterFaultType()
at org.oasis_open.docs.wsn.b_2.ObjectFactory
at protected java.util.List org.oasis_open.docs.wsn.b_2.TopicExpressionType.content
at org.oasis_open.docs.wsn.b_2.TopicExpressionType
at protected org.oasis_open.docs.wsn.b_2.TopicExpressionType org.oasis_open.docs.wsn.b_2.NotificationMessageHolderType.topic
at org.oasis_open.docs.wsn.b_2.NotificationMessageHolderType
at protected java.util.List org.oasis_open.docs.wsn.b_2.Notify.notificationMessage
at org.oasis_open.docs.wsn.b_2.Notify
at private org.oasis_open.docs.wsn.b_2.Notify com.wwc.cps.webservices.jaxws.Notify.arg0
at com.wwc.cps.webservices.jaxws.Notify
@XmlAttribute/@XmlValue need to reference a Java type that maps to text in XML.
this problem is related to the following location:
at protected java.util.List org.oasis_open.docs.wsn.t_1.TopicType.messageTypes
at org.oasis_open.docs.wsn.t_1.TopicType
at org.oasis_open.docs.wsn.t_1.TopicNamespaceType$Topic
at public org.oasis_open.docs.wsn.t_1.TopicNamespaceType$Topic org.oasis_open.docs.wsn.t_1.ObjectFactory.createTopicNamespaceTypeTopic()
at org.oasis_open.docs.wsn.t_1.ObjectFactory
at protected java.util.List org.oasis_open.docs.wsn.t_1.TopicSetType.any
at org.oasis_open.docs.wsn.t_1.TopicSetType
at protected org.oasis_open.docs.wsn.t_1.TopicSetType org.oasis_open.docs.wsn.b_2.NotificationProducerRP.topicSet
at org.oasis_open.docs.wsn.b_2.NotificationProducerRP
at public org.oasis_open.docs.wsn.b_2.NotificationProducerRP org.oasis_open.docs.wsn.b_2.ObjectFactory.createNotificationProducerRP()
at org.oasis_open.docs.wsn.b_2.ObjectFactory
at protected java.util.List org.oasis_open.docs.wsn.b_2.TopicExpressionType.content
at org.oasis_open.docs.wsn.b_2.TopicExpressionType
at protected org.oasis_open.docs.wsn.b_2.TopicExpressionType org.oasis_open.docs.wsn.b_2.NotificationMessageHolderType.topic
at org.oasis_open.docs.wsn.b_2.NotificationMessageHolderType
at protected java.util.List org.oasis_open.docs.wsn.b_2.Notify.notificationMessage
at org.oasis_open.docs.wsn.b_2.Notify
at private org.oasis_open.docs.wsn.b_2.Notify com.wwc.cps.webservices.jaxws.Notify.arg0
at com.wwc.cps.webservices.jaxws.Notify
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:105)
at com.sun.xml.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:116)
at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilder.createJAXBContext(JAXWSMetaDataBuilder.java:921)
... 82 more
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/555959#555959]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Messaging] - getting "Message to JBossTopic ... not processed"
by ranjix
ranjix [http://community.jboss.org/people/ranjix] replied to the discussion
"getting "Message to JBossTopic ... not processed""
To view the discussion, visit: http://community.jboss.org/message/555912#555912
--------------------------------------------------------------
Ok, after a week of digging, I finally think I understand what's going on and I hacked something to fix the issue.
Short version, IMO is a bug in how JBoss shares JMS messages objects between subscribers on a topic.
Long version:
I have several apps, with MDBs, which subscribe to the same topic. The apps run in the same server (JVM), but obviously each in its own app classloader (the MDBs, when called, have as classloaders the EAR app classloader). This is good. The JMS message object type which I get in the onMessage implementation is +org.jboss.jms.message.BytesMessageProxy+ (the message was supposed to be a BytesMessage). I get different instances of +BytesMessageProxy+ in the different MDBs. This is ok. Here comes the bad part. The +MessageProxy+ (+BytesMessageProxy+ extends this) contains a field +message+ which is a +JBossMessage.+ The bad part is that each of the different instances of proxy class contains same JBossMessage object. So, now, my MDBs start reading from the proxy, which in turn read from the +JBossMessage+. Since I have a quad core, the reading is pretty fast, and the "second" MDB starts reading before the first finished reading and resetting the message. This makes the second MDB make a read after the end of the +payloadByteArray+ (which is a byte array containing the +BytesMessage+), which results in a +MessageEOFException+ thrown from line 169 in method +readByte+ in +JBossBytesMessage+ class.
So, in conclusion, IMO sharing the same JBossMessage object between the subscribers will ALWAYS be a problem.
My hack. In my +onMessage+ method, I can't really put a synchronization block depending on the BytesMessageProxy (since is a new instance for each MDB +onMessage+ call). But I don't have access to the contained shared +JBossMessage+ object, so I put a synchronization block depending on +BytesMessageProxy.getJMSMessageID+ object, which is the string representing the message's id. Since the +JBossMessage+ shared has only one ID, then my readings will wait for the lock on the ID. This, at least, fixed my issues. Not happy at all with the implementation, if someone on JBoss JMS team reads this, please consider it for a possible bug.
thanks/ranjix
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/555912#555912]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years