[jboss-user] [JCA/JBoss] - Re: Spontaneous undeployment under stress load
Already fixed in http://jira.jboss.com/jira/browse/JBAS-3107 It's due to running out of sockets, not CPU starvation as I thought. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4026259#4026259 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4026259 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Re: Spontaneous undeployment under stress load
I finally got access to the test server logs, and found these lines particularly interesting: | (ScannerThread) WARN [FileURLLister] Could not list directory '/jboss/server/default/farm', reason unknown | (ScannerThread) WARN [FileURLLister] Could not list directory '/jboss/server/default/deploy', reason unknown | (ScannerThread) DEBUG [MainDeployer] Undeploying file:/jboss/server/default/farm/some-app.ear | (ScannerThread) DEBUG [MainDeployer] Undeploying file:/jboss/server/default/deploy/some-other-app.ear | And so on... Spontaneous app undeployment due to the ScannerThread not being able to read the deploy and farm directories, possibly due to the load put on the server. So my conclusion is that CPU starvation is causing the undeployment issue. This is not a problem as we will never hit this kind of load when live, but still looks like odd behaviour and something that might be addressed more gracefully (i.e. issue warning when not able to read farm/deploy dirs, but don't undeploy by default). As this is not directly related to the ResourceAdapter, feel free to move this thread to a more suitable location. I will now investigate if this is something worth raising as a bug. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025428#4025428 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025428 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Spontaneous undeployment under stress load
I'm unsure where to post this, but as this issue manifested itself whilst stress loading a Resource Adapter I though I'd post it here. As anyone ever witnessed the spontaneous undeployment of farmed applications (in a JBoss cluster) when an application is under stress? We're managing this feat when flooding a custom built TCP listening Resource Adapter with concurrent requests (TCP packets). The RA works well with between 50 and 100 concurrent requests, but as soon as we increase the load to 500+ concurrent requests the cluster starts undeploying a number of applications, most totally unrelated to the RA. I've so far been unable to replicate this on my dev machine (stress test client, JBoss and DB all running locally) but it keeps happening on our test setup (stress test client, JBoss and DB on 3 separate machines). We've tried ruling out the cluster, by only running one JBoss instance, and it also undeployed most applications under stress on its own. I'm trying to replicate this on my machine so that I can get some more details, but I thought I'd ask here for any hints in case it rings any bells with anyone. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025352#4025352 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025352 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Re: JCA as a UDP interface (design query)
Having written the UDP RA, is it possible to get any loadbalancing out of running it in a JBoss cluster? After reading http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86104 it looks like not, but I'd like to double check. In my case the RAs don't need to share any data, they are 100% independent. All I need is for the load balancer to distribute the incoming UDP packets (unicast, not broadcast as I stated before) in a round-robin fashion, amongst the all the nodes. No 'sticky-session'-like behaviour required at all. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999880#3999880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999880 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Re: JCA as a UDP interface (design query)
Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995534#3995534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995534 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - JCA as a UDP interface (design query)
Hi all. I'm about to implement a Resource Adaptor to act as a UDP interface between an EIS and a J2EE application. The EIS currently broadcasts UDP packets requesting a service and expects UDP packets with the responses. It is an asynchronous system. Outside a JBoss environment I would implement Java inbound and outbound daemon threads. The former would listen to the UDP socket and delegate any requests to the business tier, and the latter would dispatch responses via UDP back to the EIS. However within JBoss, and according to J2EE 1.4, the best approach to implement this 'daemon' seems to be JCA 1.5. In this case my UDPResourceAdaptor would act as both inbound and outbound interface, delegating requests to MDBs and sending the responses via UDP. I just want a final sanity check before I start cutting the code. Is this the right design? If there is a better (simpler) alternative then I'd really like to hear about it. Regards Dan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995299#3995299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995299 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
