Application Maximum Connection Reached

Hi there,
I have installed a new Application Server and I have my forms and reports running on it. My users have receive an error as above. It seems the AS can only allow 20 max concurrent user?
How can i enlarge it? My server should be able to cater to more than that.
Thanks

It was simple to plan a download calendar in the case of exceeding maximum connections.
I think this rerolve.
1-"In this momment isn't not possible too manny connections"
2-Please your type of modem: xpto / xpt1 / xpt2 / etc...
3-Calculating 'tracert time'
3-Calculating time max: x minutes min: y minutes
4-Plan a download time:
TODAY DD1/MM1/YYYY1
-HOURS-
10 -
11 -
12
13 -
DD1/MM1/YYYY1
10
11 -
12 -
13
14
15 -
DD1/MM1/YYYY1
10
11
12
13 -
14 -
15
..

Similar Messages

ORA - Maximum Connections Reached

Dear All
Even after implementing Connection pooling in our Application , we very often get this error "150 process exceede- Maximum Connection reached" ? How do we handle this? Our application is about to GoLive in another month .Please help us.
Thanks
AKS

It was simple to plan a download calendar in the case of exceeding maximum connections.
I think this rerolve.
1-"In this momment isn't not possible too manny connections"
2-Please your type of modem: xpto / xpt1 / xpt2 / etc...
3-Calculating 'tracert time'
3-Calculating time max: x minutes min: y minutes
4-Plan a download time:
TODAY DD1/MM1/YYYY1
-HOURS-
10 -
11 -
12
13 -
DD1/MM1/YYYY1
10
11 -
12 -
13
14
15 -
DD1/MM1/YYYY1
10
11
12
13 -
14 -
15
..

Socket maximum connections reached

hi,
i got this error since fews days. And i do not know what to do with.
java.net.SocketException: No buffer space available (maximum connections reached?): connect
thanks
Herve

How many connections do you need? Are you closing them properly?
file:///D:/Java/jdk1.4.0/docs/api/java/net/ServerSocket.html#ServerSocket(int,%20int)

Maximum connections reached

Hi ,
I got an issue in Performance testing. we are not using connection pooling in clinet side. I want to check how many connections still opened , which class it opened when i got Maximum connectioned reached exception. Kindly let me know if any body have idea to solve this .
Thanks in Advance,
Javamine

javamine wrote:
... Performance testing. We are not using connection pooling on client side.
I want to check how many connections are open, which class it opened when i got Maximum connections reached exception.
... anybody have idea to solve this. In the client add code to keep track of how many connections are open
and display this and a stacktrace when you get Maximum Connections Reached Exception.
Even if you were using connection pooling
the database can still reject connections above a certain number of concurrent connections.

I can't enter a Site. Ihere is only a message: "Maximum number of open connections reached."

If i want to go to a Site, i recive this: "Maximum number of open connections reached.
" other Browser work. I have the Problem only with Firefox.

Check the connection settings.
*Firefox/Tools > Options > Advanced : Network : Connection > Settings
*https://support.mozilla.org/kb/Options+window+-+Advanced+panel
If you do not need to use a proxy to connect to internet then select "Use the system proxy settings" setting or select "No Proxy".
See "Firefox connection settings":
*https://support.mozilla.org/kb/Firefox+cannot+load+websites+but+other+programs+can

ISA 2006 slow response, connections timeout, maximum limit reached?

Hey guys,
I've been having an issue with a client's ISA Server for the past couple of weeks and haven't been able to understand why this is happening.
They have a couple of ISA Servers Enterprise Edition in an array. This ISA Servers give Internet access to the entire company. They have significant amount of traffic through a Cisco Iron Port that all the users proxy settings are configured to this device
and the Iron Port forwards the requests to the ISA Servers.
This implementation have been working fine for months, until a few weeks back that started to have slow response problems from the ISA Servers. Analyzing the reports from the ISA Servers, I've noticed an increased amount of traffic a few times this
has happened and mostly from the Iron Port. The Cisco people says this increase amount is due to the fact that the ISA Server stops responding and new requests are made at the moment from the device. We have configured the Iron port IP in the exceptions of
the Flood Mitigation Settings of the ISA Server, and configure it to take more than 20,000 connections.
Still after this configuration, the same problem raised a couple of days back. The ISA Servers stops responding and they need to be forced shut down and restarted to get them back to work.
There are also some errors from some other internal IPs that it reaches maximum connection limits, but these are about 10 errors like this only. I was thinking maybe there are some infected computers or something but they said that they scanned the ones
that show the errors and nothing is detected.
From the ISA reports of the time of the incident, I saw that it reached more than 15,000 concurrent connections. More than double of what it usually handles throughout the day.
I don't know if there is like a connection limit that the ISA can handle before it hangs of something?
Is there any ideas on what can be happening with this?
Thanks for any replies!
Eduardo Rojas

Hi,
Have you check the Event logs on the ISA Server? Any error?
You could use ISABPA to do some basic troubleshootings.
http://www.microsoft.com/en-hk/download/details.aspx?id=811
Best Regards,
Joyce
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

Maximum Connections required per Application instance?

Hi,
I have an application consisting of 20 BAPIs in its model DC. There is only 1 single JCO connection, implies onyl 1 backend. How do I determine the maximum connections per instance in this case.
Or is it something like this value is mostly 1?
Regards
MK

MK,
all your BAPIs can share the single JCo-Connection. How many instances of this Connection are created during runtime is editable in the WebDynpro-Content Administrator (http://<host>:<port>/webdynpro/dispatcher/sap.com/tcwdtools/Explorer)
there you can change "JCo Pool Configuration" of your JCOs (http://help.sap.com/saphelp_nw2004s/helpdata/en/3a/3b1b40fcdd8f5ce10000000a155106/frameset.htm)
kr, achim

KIMYONG : Applications Database Connection Pool 관련 parameter 설명

Purpose
JVM 이 과도한 CPU / Memory를 사용하게 되어 Application Performance에 영향을 미칠때가 있으며 이럴경우 Connection Pool 관련하여 Parameter Tunning을 해야 할때가 있습니다. 이때 사용되는 Parameter들의 의미를 설명하고자 합니다.
The Applications Database Connection Pool is a pool of JDBC database connections that are shared among java applications. Applications obtain connections from the pool by using the getJDBCConnection(...) methods of AppsContext.
Essentially, each AppsContext has a single database connection associated with it at all times.
The AOL/J layer internally borrows and returns this connection to the pool as needed to maintain connection reference that is properly initialized for the current Java tier AOL security context and NLS state.
FND_MAX_JDBC_CONNECTIONS
============================
The maximum pool size is the maximum allowed sum of the number of available connections and thenumber of locked connections. If the pool reaches the maximum size and all connections are locked, new clients will not be able to borrow a connection until one of the current clients has returned one. The default setting for this parameter is essentially unlimited (about 2 billion).
FND_JDBC_BUFFER_MIN
======================
The buffer minimum is the minimum number of connections that the pool should try to maintain in the available list. When the buffer size falls below the buffer minimum, the pool maintenance thread will be notified to create new connections. When notified, the thread will immediately attempt to create the number of connections to fill the difference. New connections will not be created if the pool is already at its maximum size. When creating new connections the thread uses the attributes of the most recent client request that resulted in a new connection being created.
Setting this parameter to "0" will disable maintenance of the buffer minimum.
However, the buffer maximum will still be maintained.
Setting this parameter to a number greater than the maximum pool size(FND_MAX_JDBC_CONNECTIONS) will disable all buffer maintenance.
FND_JDBC_BUFFER_MAX
======================
The buffer maximum is the maximum number of connections that the pool should try to maintain in the available list. During heavy usage, the buffer may exceed this maximum. However, during periods of low usage, the maintenance thread will decrease the buffer size until the buffer maximum is reached.
If the value of this parameter is an integer, (for example "20") the buffer maximum is static. If the value is a percent (for example, "20%"), the buffer maximum is not constant but instead is calculated dynamically as a percent of total pool size. The buffer minimum is also taken into account when
determining a dynamic buffer maximum.
The exact expression used is:
maximum(t) = buffer minimum + ( (FND_JDBC_BUFFER_MAX/100) * size(t) )
where maximum(t) and size(t) are the buffer maximum and pool size at some time t.
The thread is configured to periodically check the buffer size. If the buffer size is greater than the maximum, the thread will remove either the number of available connections specified by FND_JDBC_BUFFER_DECAY_SIZE or the number of connections in excess of the buffer minimum, whichever is smaller. When connections are removed from the available list, the least recently used ones are removed first.
Setting this parameter to100%, or to a number equal to FND_MAXIMUM_JDBC_CONNECTIONS, or to a number less than or equal to FND_JDBC_BUFFER_MIN will effectively prevent the maintenance thread from ever removing any connections.
FND_JDBC_BUFFER_DECAY_INTERVAL
===================================
The buffer decay interval specifies how often the connection pool maintenance thread should check the buffer size. The thread will check the buffer size at most once every FND_JDBC_BUFFER_DECAY_INTERVAL seconds. The actual time between consecutive thread cycles will vary somewhat depending on the JVM load.
This parameter, along with FND_JDBC_BUFFER_DECAY_SIZE, allows the buffer decay rate to be tuned. For example, if the buffer decay size is 2 and the buffer decay interval is one minute, the buffer decay rate will never exceed two connections per minute. When connections are removed, the least recently used ones are removed first.
FND_JDBC_BUFFER_DECAY_SIZE
=============================
The buffer decay size specifies the maximum number of connections that should be removed during any single thread cycle during which the number of available connections is greater than the buffer size. This parameter, along with FND_JDBC_BUFFER_DECAY_INTERVAL, allows the buffer decay rate to be tuned.
FND_JDBC_MAX_WAIT_TIME
=========================
The maximum wait time specifies how much time a client should spend trying to get a connection. The borrow algorithm, used to borrow an object from the pool, contains check points at which the elapsed time is compared to the maximum wait time. If it exceeds the maximum wait time, then a null object will be returned to the client. The pre-configured value for the maximum wait time is
10 seconds.
FND_JDBC_SELECTION_POLICY
============================
The selection policy determines how a connection is selected from the list of available connections for a particular client. The connection pool is pre-configured to use a cost-based selection algorithm, which selects the connection that will require the smallest amount of initialization to match the
client's context.
FND_JDBC_USABLE_CHECK
===========================
The FND_JDBC_USABLE_CHECK parameter governs whether a pl/sql query is performed before giving a connection to a client. The pool checks whether a connection is usable before handing it to a client. This always involves checking that the connection is not null and is not closed. If FND_JDBC_USABLE_CHECK is set to true, then it also verifies that the connection can be used to perform a simple PL/SQL query. (This parameter may have to be set to "true" in order to clean up
connections to a database that has been restarted.)
FND_JDBC_CONTEXT_CHECK
==========================
The FND_JDBC_CONTEXT_CHECK parameter governs whether the AOL security context and NLS state is obtained from the database when the connection is returned to the pool. If FND_JDBC_CONTEXT_CHECK is "true", when the connection is returned to the pool, the AOL security context and NLS state will be obtained from the database. (This is implemented in the DBConnObj.isReusable() method). This check must be done when the connection is returned (rather than when it is borrowed) so that the selection matching algorithm has access to the actual
session context of the connections in the available list.
FND_JDBC_PLSQL_RESET
========================
The PL/SQL reset flag, set using the variable FND_JDBC_PLSQL_RESET, governs whether the PL/SQL state associated with a connection should be freed before the pool hands the connection to the client. By default this flag is false.
If the flag is set by true, by including the line "FND_JDBC_PLSQL_RESET=true" in the .dbc file, each connection to the database will have its PL/SQL state cleared before the pool returns the connection to the client.
This is how it works. After the pool selects a connection from the available list for a client, it initializes the connection. One of the things initialization does is to set a flag that is later used by SessionManager to determine if the apps initialization routine needs to be performed for the connection. When FND_JDBC_PLSQL_RESET has been set to "true", this flag will always be set to true. After the pool initializes the connection, it also checks whether the connection is usable. In this case, this check will include a call to DBMS_SESSION.RESET_PACKAGE, which frees the PL/SQL state. The table below summaries the affect of FND_JDBC_PLSQL_RESET and the other safety check parameters on borrowing a connection from the pool.
The FND_JDBC_PLSQL_RESET parameter has been added to only to address the case where production PL/SQL global bugs are known to exist. The performance of the pool is reduced by setting this flag to true.
Reference : Note 264599.1

Purpose
JVM 이 과도한 CPU / Memory를 사용하게 되어 Application Performance에 영향을 미칠때가 있으며 이럴경우 Connection Pool 관련하여 Parameter Tunning을 해야 할때가 있습니다. 이때 사용되는 Parameter들의 의미를 설명하고자 합니다.
The Applications Database Connection Pool is a pool of JDBC database connections that are shared among java applications. Applications obtain connections from the pool by using the getJDBCConnection(...) methods of AppsContext.
Essentially, each AppsContext has a single database connection associated with it at all times.
The AOL/J layer internally borrows and returns this connection to the pool as needed to maintain connection reference that is properly initialized for the current Java tier AOL security context and NLS state.
FND_MAX_JDBC_CONNECTIONS
============================
The maximum pool size is the maximum allowed sum of the number of available connections and thenumber of locked connections. If the pool reaches the maximum size and all connections are locked, new clients will not be able to borrow a connection until one of the current clients has returned one. The default setting for this parameter is essentially unlimited (about 2 billion).
FND_JDBC_BUFFER_MIN
======================
The buffer minimum is the minimum number of connections that the pool should try to maintain in the available list. When the buffer size falls below the buffer minimum, the pool maintenance thread will be notified to create new connections. When notified, the thread will immediately attempt to create the number of connections to fill the difference. New connections will not be created if the pool is already at its maximum size. When creating new connections the thread uses the attributes of the most recent client request that resulted in a new connection being created.
Setting this parameter to "0" will disable maintenance of the buffer minimum.
However, the buffer maximum will still be maintained.
Setting this parameter to a number greater than the maximum pool size(FND_MAX_JDBC_CONNECTIONS) will disable all buffer maintenance.
FND_JDBC_BUFFER_MAX
======================
The buffer maximum is the maximum number of connections that the pool should try to maintain in the available list. During heavy usage, the buffer may exceed this maximum. However, during periods of low usage, the maintenance thread will decrease the buffer size until the buffer maximum is reached.
If the value of this parameter is an integer, (for example "20") the buffer maximum is static. If the value is a percent (for example, "20%"), the buffer maximum is not constant but instead is calculated dynamically as a percent of total pool size. The buffer minimum is also taken into account when
determining a dynamic buffer maximum.
The exact expression used is:
maximum(t) = buffer minimum + ( (FND_JDBC_BUFFER_MAX/100) * size(t) )
where maximum(t) and size(t) are the buffer maximum and pool size at some time t.
The thread is configured to periodically check the buffer size. If the buffer size is greater than the maximum, the thread will remove either the number of available connections specified by FND_JDBC_BUFFER_DECAY_SIZE or the number of connections in excess of the buffer minimum, whichever is smaller. When connections are removed from the available list, the least recently used ones are removed first.
Setting this parameter to100%, or to a number equal to FND_MAXIMUM_JDBC_CONNECTIONS, or to a number less than or equal to FND_JDBC_BUFFER_MIN will effectively prevent the maintenance thread from ever removing any connections.
FND_JDBC_BUFFER_DECAY_INTERVAL
===================================
The buffer decay interval specifies how often the connection pool maintenance thread should check the buffer size. The thread will check the buffer size at most once every FND_JDBC_BUFFER_DECAY_INTERVAL seconds. The actual time between consecutive thread cycles will vary somewhat depending on the JVM load.
This parameter, along with FND_JDBC_BUFFER_DECAY_SIZE, allows the buffer decay rate to be tuned. For example, if the buffer decay size is 2 and the buffer decay interval is one minute, the buffer decay rate will never exceed two connections per minute. When connections are removed, the least recently used ones are removed first.
FND_JDBC_BUFFER_DECAY_SIZE
=============================
The buffer decay size specifies the maximum number of connections that should be removed during any single thread cycle during which the number of available connections is greater than the buffer size. This parameter, along with FND_JDBC_BUFFER_DECAY_INTERVAL, allows the buffer decay rate to be tuned.
FND_JDBC_MAX_WAIT_TIME
=========================
The maximum wait time specifies how much time a client should spend trying to get a connection. The borrow algorithm, used to borrow an object from the pool, contains check points at which the elapsed time is compared to the maximum wait time. If it exceeds the maximum wait time, then a null object will be returned to the client. The pre-configured value for the maximum wait time is
10 seconds.
FND_JDBC_SELECTION_POLICY
============================
The selection policy determines how a connection is selected from the list of available connections for a particular client. The connection pool is pre-configured to use a cost-based selection algorithm, which selects the connection that will require the smallest amount of initialization to match the
client's context.
FND_JDBC_USABLE_CHECK
===========================
The FND_JDBC_USABLE_CHECK parameter governs whether a pl/sql query is performed before giving a connection to a client. The pool checks whether a connection is usable before handing it to a client. This always involves checking that the connection is not null and is not closed. If FND_JDBC_USABLE_CHECK is set to true, then it also verifies that the connection can be used to perform a simple PL/SQL query. (This parameter may have to be set to "true" in order to clean up
connections to a database that has been restarted.)
FND_JDBC_CONTEXT_CHECK
==========================
The FND_JDBC_CONTEXT_CHECK parameter governs whether the AOL security context and NLS state is obtained from the database when the connection is returned to the pool. If FND_JDBC_CONTEXT_CHECK is "true", when the connection is returned to the pool, the AOL security context and NLS state will be obtained from the database. (This is implemented in the DBConnObj.isReusable() method). This check must be done when the connection is returned (rather than when it is borrowed) so that the selection matching algorithm has access to the actual
session context of the connections in the available list.
FND_JDBC_PLSQL_RESET
========================
The PL/SQL reset flag, set using the variable FND_JDBC_PLSQL_RESET, governs whether the PL/SQL state associated with a connection should be freed before the pool hands the connection to the client. By default this flag is false.
If the flag is set by true, by including the line "FND_JDBC_PLSQL_RESET=true" in the .dbc file, each connection to the database will have its PL/SQL state cleared before the pool returns the connection to the client.
This is how it works. After the pool selects a connection from the available list for a client, it initializes the connection. One of the things initialization does is to set a flag that is later used by SessionManager to determine if the apps initialization routine needs to be performed for the connection. When FND_JDBC_PLSQL_RESET has been set to "true", this flag will always be set to true. After the pool initializes the connection, it also checks whether the connection is usable. In this case, this check will include a call to DBMS_SESSION.RESET_PACKAGE, which frees the PL/SQL state. The table below summaries the affect of FND_JDBC_PLSQL_RESET and the other safety check parameters on borrowing a connection from the pool.
The FND_JDBC_PLSQL_RESET parameter has been added to only to address the case where production PL/SQL global bugs are known to exist. The performance of the pool is reduced by setting this flag to true.
Reference : Note 264599.1

LDAP "ServerListener" stops responding (Max number of connections reached)

Hi --
The last four work days, in the evening, our OAS 10G server stopped processing portal logon requests. The response to login requests was this message:
Internal error WWC-00006 Unexpected error
encountered in wwsec_app_priv.process)signon
(User-Defined Exception) (WWC-41417)
An exception was raised when accessing the
Oracle Internet Directory 81: Can't contact
LDAP server. Details:
Operation dbms_ldap.simple_bind_s (The message also included other details such as the host, port and DN, and a reference to error message WWC-41743.)
Suspecting an LDAP problem, we looked on the server, and in ORACLE_HOME/LDAP/LOG I found recent log files (oidldapd[instance]s[pid].log) with several megs of messages that look like this:
2005/06/17:17:59:33 * ServerListener :2 * ERROR :
ServerListener : Max numbers of connections reached.
Num Conns = 874, Max Conns = 874, Closing the
connection. These messages repeated, several times per minute, overnight and the next day until I restarted the server. The same thing happened again the next night.
A metalink search pointed to docid "293391.1" which, in part, suggests that the problem may be caused by improper programming, and that the solution may be to, "investigate the applications that connect to OID and where possible modify them to perform an explicit disconnect."
Does anyone have any reference to how an application can perform an explicit disconnect from the OID? We do have a relatively new application which follows the "Java API for Oracle Internet Directory" -- documention found here: http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96577/oid_java.htm -- but in that document we cannot find any reference for how to "perform an explicit disconnect".
The application already calls the "context.close()" method, which according to the documentation closes the connection to the OID, but we cannot find any other "explicit disconnect". And, since the problem happens even though our app is already calling the context.close(), there must be something else.
Opened this up as a Metalink question related to Portal, but they said it's not their problem, and we should ask over here.
Any thoughts?

Looks like that's helped. While the errors persist, OID isn't dieing.
For anyone with similar problems, it looks like docid 437493.1 is useful. Upgrade clients to at least 10.2.0.3 to defeat a sqlnet problem.
Just tried it with the 10.2.0.5 patchset and it seems to be working and not generating the 104 error on the OID server.

Maximum connections allowed for AMS 5.0.1

How can I find out the maximum connection allowed for adobe media server 5.0.1 standard license?

...that would depend on your application.
For a one-way video-on-demand system that streams recorded video at the user's request. Adobe Media Server serves only one stream to each user.
Here are the bandwidth calculations you would make:
Calculating server bandwidth needs (BWs):
BWs = N × S
where N = number of simultaneous users (subscribers)
and S = average bitrate of encoded A/V content
For example to calculate the overall server bandwidth needed to stream video encoded at 500 Kbps to 1000 simultaneous users:
500 Mbps = 1000 × 500 Kbps
The above assumes that content is encoded at a constant bitrate. Most often, however, you will vary the bitrate of the content to suit the viewing audience. This affects your bandwidth needs at both the client and server level.
For example, suppose you estimated that half of the 1000 simultaneous users were going to connect via 350 Kbps DSL modem and the other half via 3 Mbps cable modem. Suppose further that while the video encoded at 500 Kbps was appropriate for the cable viewers, you wanted to encode a separate video at 150 Kbps for the DSL modem users.
In this case, the total bandwidth required of the system is lowered to 325 Mbps:
325 Mbps = (500 Kbps × 500) + (150 Kbps × 500)
This help ?

Maximum Connections Oracle can provide

I have this query, how many maximum connections does oracle provide to any applications server.
I am aware that the number of connections are configurable. But i wanted to know the maximum number of connections after which there is a possibilty of oracle to crash, or after these particular number connectins oracle wont support any more connections.
Please help me with this, as im in desperate need of a solution.
Thanx for your time.
Nikhil

There is no functional limit to the number of connections Oracle can support. There may be some internal limit (i.e. session ID may be an integer, which would limit you to 4 billion connections on a 32-bit system) but I've never heard of anyone actually hitting such a limit. In reality, you will be constrained by your hardware long before you are constrained by Oracle.
Unfortunately, estimating how many connections your particular hardware can support is not trivial. It depends, obviously, on your hardware, but it also depends on your application and on how your database is configured-- shared server vs. dedicated server would be the largest factor here.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Javax.resource.spi.ResourceAdapterInternalException: max connections reache

Hello,
I am writing an application to read messages from queues.
Everything seems to be working fine, but after a number of un-deployments and deployments I start getting the following exception and have no choice but to restart the application server.
Any hint on what the root cause might be?
Exception stack trace:
2008-02-15 14:47:19,095 WARN [org.jboss.system.ServiceController:424] Problem starting service jboss.j2ee:ear=Application-1.0.ear,jar=Application-1.0.jar,name=MDB,service=EJB3
org.jboss.deployment.DeploymentException: Endpoint activation failed ra=jboss.jca:service=RARDeployment,name='wmq.jmsra.rar' activationSpec=javax.jms.Queue:wsmq/Q@@localhost; - nested throwable: (javax.resource.spi.ResourceAdapterInternalException: max connections reached)
     at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:53)
     at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.activate(JBossMessageEndpointFactory.java:310)
     at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.start(JBossMessageEndpointFactory.java:194)
     at org.jboss.ejb3.mdb.MessagingContainer.startProxies(MessagingContainer.java:190)
     at org.jboss.ejb3.mdb.MessagingContainer.start(MessagingContainer.java:156)
     at org.jboss.ejb3.mdb.MDB.start(MDB.java:126)
     at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at org.jboss.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:103)
     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
     at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
     at sun.reflect.GeneratedMethodAccessor5.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 org.jboss.system.ServiceController.start(ServiceController.java:435)
     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 $Proxy361.start(Unknown Source)
     at org.jboss.ejb3.JmxKernelAbstraction.install(JmxKernelAbstraction.java:120)
     at org.jboss.ejb3.Ejb3Deployment.registerEJBContainer(Ejb3Deployment.java:301)
     at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:362)
     at org.jboss.ejb3.Ejb3Module.startService(Ejb3Module.java:91)
     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
     at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
     at sun.reflect.GeneratedMethodAccessor5.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 $Proxy34.start(Unknown Source)
     at org.jboss.ejb3.EJB3Deployer.start(EJB3Deployer.java:512)
     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.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
     at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
     at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
     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 $Proxy35.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.GeneratedMethodAccessor21.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 $Proxy10.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$ScannerThread.loop(AbstractDeploymentScanner.java:274)
     at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
Caused by: javax.resource.spi.ResourceAdapterInternalException: max connections reached
     at com.ibm.mq.connector.ResourceAdapterConnectionPool.allocateConnection(ResourceAdapterConnectionPool.java:231)
     at com.ibm.mq.connector.ResourceAdapterImpl.endpointActivation(ResourceAdapterImpl.java:333)
     at org.jboss.resource.deployment.RARDeployment.endpointActivation(RARDeployment.java:271)
     at org.jboss.resource.deployment.RARDeployment.internalInvoke(RARDeployment.java:226)
     at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156)
     at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
     at org.jboss.ejb3.JmxClientKernelAbstraction.invoke(JmxClientKernelAbstraction.java:44)
     at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.activate(JBossMessageEndpointFactory.java:305)
     ... 101 more
ObjectName: jboss.j2ee:ear=Application-1.0.ear,jar=Application-1.0.jar,name=MDB,service=EJB3
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Endpoint activation failed ra=jboss.jca:service=RARDeployment,name='wmq.jmsra.rar' activationSpec=javax.jms.Queue:wsmq/Q@@localhost; - nested throwable: (javax.resource.spi.ResourceAdapterInternalException: max connections reached)My current configuration is:
- JBoss 4.2.2-GA (linux)
- WS MQ 6.0.2.2 (linux)
I have configured JBoss the following way:
- added wmq.jmsra.rar to the $JBOSS_SERVER/deploy directory
- added com.ibm.mqetclient.jar to the $JBOSS_SERVER/lib directory
- created $JBOSS_SERVER/deploy/wmq.jmsra-ds.xml as follows
<?xml version="1.0" encoding="UTF-8"?>
<connection-factories>

<mbean code="org.jboss.resource.deployment.AdminObject" name="jca.wmq:name=wsmqQ">
    <attribute name="JNDIName">wsmq/Q</attribute>
    <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'</depends>
    <attribute name="Type">javax.jms.Queue</attribute>
    <attribute name="Properties">
      baseQueueManagerName=QM1
      baseQueueName=Q
    </attribute>
</mbean>

<tx-connection-factory>
    <jndi-name>MQCF</jndi-name>
    <xa-transaction />
    <rar-name>wmq.jmsra.rar</rar-name>
   <connection-definition>javax.jms.ConnectionFactory</connection-definition>
    <config-property name="channel" type="java.lang.String">SYSTEM.DEF.SVRCONN</config-property>
    <config-property name="hostName" type="java.lang.String">127.0.0.1</config-property>
    <config-property name="port" type="java.lang.String">1414</config-property>
    <config-property name="queueManager" type="java.lang.String">QM1</config-property>
    <config-property name="transportType" type="java.lang.String">CLIENT</config-property>
</tx-connection-factory>My java MDB (EJB3) is:
@MessageDriven(name = "MDB", activationConfig = {
        @ActivationConfigProperty(propertyName = "destination", propertyValue = "wsmq/Q"),
        @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "transportType", propertyValue = "CLIENT"),
        @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "true"),
        @ActivationConfigProperty(propertyName = "maxPoolDepth", propertyValue = "1") }, messageListenerInterface = MessageListener.class)
@ResourceAdapter("wmq.jmsra.rar")
public class MDB implements MessageListener {
    public void onMessage(Message message) {
        return;
}Thanks in advance for any information!
cheers!

hi
this is known to IBM as APAR IC54346 - fixed in pack 6.0.2.3

How many users from an application can connect to a SQL server at a time?

HI,
I need to know , How many users from an application can connect to a SQL server at a time? Do we have any settings for this in SQL server for limiting the users?

This is a difficult question, since it is both technical and legal.
The absolute maximum number of connections is around 32700, but unless your server is very beefy, it will choke long before that. A connection is not a user - an application can have many connections for the same user. Depending on your license
model, you may be legally limited to a certain number of users, but this number is not enforced technially.
Erland Sommarskog, SQL Server MVP, [email protected]

Maximum Connections exceeds

i have a html page that contains 6 dynamically created URL's one of them is mentioned bellow
<b>http://hercules.keells.lk:8000/sap/bw/BEx?sap-language=%20&bsplanguage=%20&cmd=ldoc&TEMPLATE_ID=ZL1TACH</b>
The problem is everytime the page is loaded it creates 6 sessions (user connections) & after i refresh the page a few times.. it will give me the maximum connections exceeded error...
How can i use only one session (connection) for this page & display 6 web queries /??????

append the following to your URL
<b>&STATELESS=X</b>
where is this html page (which contains the 6 webtemplate) running from - is it a BSP application?
Regards
Raja

Looks like we are running out of the maximum connections IAS 6.0 SP4 can open with the database. Where is the setting and how can we change it?

We are using IAS 6 SP4. We have 4 kjs engines and we see total 112 jre threads being spawned to database. The code is not able to open connection with the database when we go beyond 60 users (approx)
Any clues?
Thanks in advnace
Sangeeta

Hi,
Fine,Its always better to increase the Max pool Size settings to a large value corresponding to KJS's max thread value. Sometimes i had faced problems with Asynchronous database queries eventhough i increased the Max thread value of the Driver to a good maximum value.
If an application has a very large number of users who access the same data, then Setting the Database Cache's Maximum Connections to a large value will surely help.
I think its always better to have a clear database connection settings strategy ,considering your Complexity of your Application 'We are using IAS 6 SP4. We have 4 kjs engines and we see total 112 jre threads being spawned to database'.
Regards,
T.Raghulan.

Application Maximum Connection Reached

Similar Messages

Maybe you are looking for