[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
"ron.si...@jboss.com" wrote : I'll fix it in the next release. Thanks! Good thing is that I can wait :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205211#4205211 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205211 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Thanks for the suggestion, I've incorporated the changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204191#4204191 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204191 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
"vink" wrote :
| ... can we use the local fixed version in our product where
org.jboss.remoting.Client class is working with static invokerDestructionTimer
instance & other places instantiating timer object in disconnect() is
commented.
|
That may be a two part question.
1. If you have a support contract and are using an EAP product, then there's no
support for a nonstandard library.
2. Technically, it's not enough to just create a static Timer, because, in the
absence of TimerTasks, a Timer can turn itself off and become unusable. I do
something like this:
|private static Timer timer;
|private static Object timerLock = new Object();
|...
|
|{
| ...
|synchronized (timerLock)
|{
| if (timer == null)
| {
| timer = new Timer(true);
| }
| try
| {
| timer.schedule(pingTimerTask, pingFrequency,
pingFrequency);
| }
| catch (IllegalStateException e)
| {
| log.debug("Unable to schedule TimerTask on existing
Timer", e);
| timer = new Timer(true);
| timer.schedule(pingTimerTask, pingFrequency,
pingFrequency);
| }
|}
|...
|}
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204142#4204142
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204142
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Hello Ron, Since, the release date of 2.5.0.SP3 is not yet known; can we use the local fixed version in our product where org.jboss.remoting.Client class is working with static invokerDestructionTimer instance & other places instantiating timer object in disconnect() is commented. private static final Timer invokerDestructionTimer = new Timer(true); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203180#4203180 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203180 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
"vink" wrote : | the JIRA issue created by you don't talk about its fix in 2.4.x, | Remoting 2.5 is essentially the same as 2.4. I jumped to 2.5 when I dropped support for Apache Tomcat. [Note that we still support JBossWeb, which is descended from Tomcat.] So, there won't be any more 2.4 releases, just 2.5 releases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201977#4201977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201977 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Extremely sorry, seems browser issue with temporary files or cookies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201802#4201802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201802 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
You have addressed my problem in other thread; http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147397 But, the JIRA issue created by you don't talk about its fix in 2.4.x, whereas you have exposed invokerDestructionDelay in this version. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201800#4201800 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201800 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Sorry, for the other post View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201786#4201786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201786 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
You have addressed my problem in other thread; http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147397 But, the JIRA issue created by you don't talk about its fix in 2.4.x, whereas you have exposed invokerDestructionDelay in this version. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201785#4201785 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201785 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
You have addressed my problem in other thread; http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147397 But, the JIRA issue created by you don't talk about its fix in 2.4.x, whereas you have exposed invokerDestructionDelay in this version. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201781#4201781 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201781 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Hello Ron, Can we expect this fix for Remoting 2.4.x. I migrated to this version with a hope of better stability as visible from release notes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201778#4201778 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201778 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
"ImmortAlex" wrote : | invokerDestructionTimer in org.jboss.remoting.Client, which is created and started in disconnect() | Good catch, Alexey. EJB3 creates a new Client with each invocation, so there you are. I've created JIRA issue JBREM-1083 "Each Client creates a new invokerDestructionTimer", and I'll fix it in the next release. "ron.si...@jboss.com" wrote : | Well, I don't think this is a Remoting problem, because the socket transport doesn't create new threads on the client side. | Ah, my mistake. org.jboss.remoting.Client does. Thanks, Alexey. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201587#4201587 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201587 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
"vink" wrote : | Issue 1: | On providing invokerDestructionDelay=1, my system run out of threads. I mean my client side. Every call results in the creation of new thread, it seems old invoker thread is not getting reused. | I have the same issue. I think reason is invokerDestructionTimer in org.jboss.remoting.Client, which is created and started in disconnect() but isn't stopped in connect(). My situation is not artifically created stress test (but, of course, not every day working scheme). Worst thing is that I can't remove invokerDestructionDelay from Connector configuration. I'm using SSL, and without destruction delay every remote call works so slow... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201584#4201584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201584 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Hi Vinay, "vink" wrote : | Issue 1: | On providing invokerDestructionDelay=1, my system run out of threads. I mean my client side. Every call results in the creation of new thread, it seems old invoker thread is not getting reused. | Well, I don't think this is a Remoting problem, because the socket transport doesn't create new threads on the client side. My conjecture is that there is some other problem, and setting "invokerDestructionDelay=1" is just reducing the consumption of Remoting resources enough to allow this other problem to show up. What kind of threads are you seeing on the client side? "vink" wrote : | The best use case for SLSB is to open a socket for a request & close it after finish. | Actually, that is the default behavior, but it's expensive to recreate sockets. The "invokerDestructionDelay" parameter is meant to prevent the closing of existing sockets when they are likely to be reused in the near future. By the way, if a socket is in the TIME_WAIT state, then it *has* been closed. "vink" wrote : | n the meanwhile, I tried overnight tests on my system with invokerDestructionDelay=1, & I face this exception on server. I cannot understand what it means, but it is linked with socket; so I thought it may be worth to share; | | Caused by: javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: could not execute query | This problem is somewhere between hibernate and your database. Definitely not a Remoting issue. -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201580#4201580 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201580 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
In the meanwhile, I tried overnight tests on my system with invokerDestructionDelay=1, & I face this exception on server. I cannot understand what it means, but it is linked with socket; so I thought it may be worth to share; Caused by: javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: could not execute query at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:629) at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:73) at com.barco.cms.eventmgt.EventQueuePoolImpl.createEventQueue(EventQueuePoolImpl.java:163) at com.barco.cms.openapi.sessionmgt.SessionManager.createSession(SessionManager.java:109) at com.barco.cms.openapi.OpenAPIImpl.startSession(OpenAPIImpl.java:148) at com.barco.cms.openapi.PerspectiveMgtAPIImpl.startSession(PerspectiveMgtAPIImpl.java:426) at sun.reflect.GeneratedMethodAccessor229.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112) at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166) at com.barco.cms.openapi.PerspectiveMgtAPIImpl.initialSteps(PerspectiveMgtAPIImpl.java:269) ... 32 more Caused by: org.hibernate.exception.JDBCConnectionException: could not execute query at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:74) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.loader.Loader.doList(Loader.java:2223) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) at org.hibernate.loader.Loader.list(Loader.java:2099) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:64) ... 42 more Caused by: org.postgresql.util.PSQLException: An I/O error occured while sending to the backend. at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:218) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:254) at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeQuery(CachedPreparedStatement.java:90) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:236) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186) at org.hibernate.loader.Loader.getResultSet(Loader.java:1787) at org.hibernate.loader.Loader.doQuery(Loader.java:674) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.doList(Loader.java:2220) ... 50 more Caused by: java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:78) at org.postgresql.core.PGStream.SendChar(PGStream.java:174) at org.postgresql.core.v3.QueryExecutorImpl.sendBind(QueryExecutorImpl.java:829) at org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1053) at org.postgresql.core.v3.QueryExecutorImpl.sendQueryPreamble(QueryExecutorImpl.java:373) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:189) ... 60 more View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200238#4200238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200238 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Issue 3: Stream corrupted exception, it is very hard to reproduce. Last time when I change the log level of remoting to TRACE, after sometime my client faces disconnects with server. It normally appears when I run my client overnight, where a call is being placed every 5 seconds. It appears as if server releases sockets slowly & many calls are hitting & then server is unable to process their requests. If there is some way either to restrict the logs, or to provide extra information; I would welcome to support it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199780#4199780 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199780 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Issue 2: Using default configuration, i.e no extra parameter to ejb3 connector configuration, many tcp connections on my system shows TIME_WAIT state. If you create a very simple RMI client & place invocation at an interval of 100 ms. And, you like to stress your server with several clients (in my case it extends upto 64). I can understand the socket limit on windowsbased computer. But, if we see one time input which is 64 clients making 64 simultaneous requests then an efficient server must not consume more than 64 sockets. The other sockets has no caller for which it will wait. The best use case for SLSB is to open a socket for a request & close it after finish. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199758#4199758 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199758 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Hello Ron, Please find my comments below. Issue 1: On providing invokerDestructionDelay=1, my system run out of threads. I mean my client side. Every call results in the creation of new thread, it seems old invoker thread is not getting reused. Secondly, even if I'm working on windows; I'm not creating new sockets. I'm just placing a call to SLSB, now if it creates new socket or thread for each & every request, I think can only be treated as design issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199669#4199669 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199669 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
Hi Vinay, You have described problems on this thread and two other threads, which is making it hard for me to get a unified picture of what's going on. To try to clarify things, I'm consolidating the discussions on this thread. Here, I believe, are the phenomena you have experienced: 1. This thread: "vink" wrote : | On increasing timeout value of ejb3 connector, this exception is not coming. But, on running my stress tests, my application is throwing java.lang.OutOfMemoryError: unable to create new native thread | Is it on the client side or the server side where you can't create a new thread? I believe the thread dumps you've shown me are from the server side, and I don't see anything particularly unusual. "vink" wrote : | And, number of such sockets increases as time passes by & it finally results into the following exception; | ... | java.net.BindException: Address already in use: connect | ... | If you're running on a Windows machine, you could be running up against a configurable limit Windows puts on the number of open sockets. For example, the parameter "MaxUserPort", which defaults to 5000, limits the user ports to values between 1024 and 5000. You can read more at, for example, "Microsoft Windows 2000 TCP/IP Implementation Details" - http://technet.microsoft.com/en-us/library/bb726981.aspx#EDAA. 2. "JBREM-877: New Socket Connection is being Created for Every" - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=126382&start=10 "vink" wrote : | On using invokerDestructionDelay in ejb3 connector configuration, my system goes slow & slow and run out of resources(native threads) in few minutes. | Again, client side or server side? "vink" wrote : | When removing this attribute, the system don't run out of resources, but many sockets are visible in TIME_WAIT state. As a result of this, my system run out of sockets & after a while I get sporadic disconnects. | Client side or server side? And, could you describe "sporadic disconnects" more precisely? 2. "Stream Corrupted Exception on Server side" - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147905 "vink" wrote : | After several hours of running I'm getting following exception | ... | Caused by: java.io.StreamCorruptedException: invalid stream header: 77011679 | Clearly, this exception is occurring on the server side, but the actual problem might be occurring on the client side. Do you see anything unusual happening on the client side when this exception is thrown? === I have a couple of general questions. 1. Am I right in inferring that you're running a stress test and you're seeing performance deteriorating on the client side? 2. Can you create a simple version of your application that demonstrates the same problems and that I can run for myself? Thanks, Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199374#4199374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199374 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
I've commented this, becqause of following behaviour; - On running my client which is requesting SLSB, the netstat tool is showing several sockets going in TIME_WAIT state. And, number of such sockets increases as time passes by & it finally results into the following exception; org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://NOICLT13407:3873/] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:771) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:160) at org.jboss.remoting.Client.invoke(Client.java:1708) at org.jboss.remoting.Client.invoke(Client.java:612) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107) at $Proxy0.getSourcesInfo(Unknown Source) at com.barco.cmstest.dependency.MarshalTest.call(MarshalTest.java:82) at com.barco.cmstest.dependency.MarshalTest.main(MarshalTest.java:51) Caused by: java.net.BindException: Address already in use: 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 org.jboss.remoting.util.SecurityUtility.connect(SecurityUtility.java:969) at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:203) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1084) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:757) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:160) at org.jboss.remoting.Client.invoke(Client.java:1708) at org.jboss.remoting.Client.invoke(Client.java:612) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107) at $Proxy0.getSourcesInfo(Unknown Source) at com.barco.cmstest.dependency.MarshalTest.call(MarshalTest.java:82) at com.barco.cmstest.dependency.MarshalTest.main(MarshalTest.java:51) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74) ... 11 more N:\>netstat -a | findstr 3873 TCPnoiclt13407:1472 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:1782 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:1790 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2055 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2219 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2256 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2289 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2296 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2336 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2351 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2373 noiclt13407.barco.com:3873 TIME_WAIT TCPnoiclt13407:2375 noicl
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
"vink" wrote : | But, on running my stress tests, my application is throwing java.lang.OutOfMemoryError: unable to create new native thread | | Is there any place, where we can specify number of sockets, which can be closed by our application. | Why do you think the OOM problem is related to the number of sockets? Is it an org.jboss.remoting.transport.socket.ServerThread that can't be created? In any case, you can specify the number of open sockets on the server with the parameter "maxPoolSize": each ServerThread in the thread pool manages a single socket. "vink" wrote : | If I'm running only 4 clients on my machine, why it is complaining about sockets. Why it doesn't reuse the same socket? | Again, why do you think it's complaining about sockets? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198498#4198498 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198498 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket Read Timeout on stressing calls for validating pr
On increasing timeout value of ejb3 connector, this exception is not coming. But, on running my stress tests, my application is throwing java.lang.OutOfMemoryError: unable to create new native thread Is there any place, where we can specify number of sockets, which can be closed by our application. If I'm running only 4 clients on my machine, why it is complaining about sockets. Why it doesn't reuse the same socket? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197342#4197342 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197342 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
