[JBoss JIRA] Commented: (JBCLUSTER-99) 4.0.4CR2 under Jbento load test numbers
by Tony Starks (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-99?page=comments#action_12348948 ]
Tony Starks commented on JBCLUSTER-99:
--------------------------------------
>>2006-03-20 16:05:18,669 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 72.16.130.57:41887, local_addr=172.16.129.57:49802)
>>message with seqno=3280 not found in sent_msgs ! sent_msgs=[1477 - 3503]
I am having the same problem as above mentioned with JGroups 4rc2(cannot as yet update version to higher).
How can i fix it ?
Tips on how you resolved the above would be welcome.
> 4.0.4CR2 under Jbento load test numbers
> ---------------------------------------
>
> Key: JBCLUSTER-99
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-99
> Project: JBoss Clustering
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Reporter: Ben Wang
> Assigned To: Brian Stansberry
> Fix For: Q2Y6
>
> Attachments: ResultsExtract.pdf
>
> Time Spent: 1 day
> Remaining Estimate: 0 minutes
>
> I have used JBento to perform load test with 2 nodes cluster (dev02, dev03). It only loads dev02 (so not load balanced yet). This is just a simple counter String test.
> 1. 10 clients with 10 ms sleep in between. The tps is 85. No error message produced
> 2. 50 client with 10ms sleep. Lots of errors:
> 2006-03-20 16:05:18,667 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1
> 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3277 not
> found in sent_msgs ! sent_msgs=[1477 - 3502]
> 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1
> 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3278 not
> found in sent_msgs ! sent_msgs=[1477 - 3503]
> 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1
> 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3279 not
> found in sent_msgs ! sent_msgs=[1477 - 3503]
> 2006-03-20 16:05:18,669 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1
> 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3280 not
> found in sent_msgs ! sent_msgs=[1477 - 3503]
> The other node also ran into OOM as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBESB-262) Service dependency - recover capability. (i.e. Gateways -> Listener dependency)
by Kurt Stam (JIRA)
Service dependency - recover capability. (i.e. Gateways -> Listener dependency)
--------------------------------------------------------------------------------
Key: JBESB-262
URL: http://jira.jboss.com/jira/browse/JBESB-262
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ESB Core
Affects Versions: 4.0 RC1
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Blocker
Fix For: 4.0
When a service depends on a resource that can not be discovered at when the service is coming up, the service should log a warning, sleep for a bit and try again, indefinetly, until the missing resource is found.
For example, all gateways depend on a listerner, if the gateway comes up before that listener the current implementation pretty much dies. We should simply put the gateway in a holding pattern.
Similarly, if during execution the JMS provider (ftp server, or any other dependency) goes off line, we should not die, but simply log, sleep and retry.
A nice to have would be that after an n number of retries we send a notification to a place where JBossON can pick it up and notify someone of a problem,
This behavior should be easy to implement, and should take care of the current race condition we experience.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Updated: (JBAS-2939) Make Invocation policies more configurable
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2939?page=all ]
Dimitris Andreadis updated JBAS-2939:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Assignee: Tom Elrod
> Make Invocation policies more configurable
> ------------------------------------------
>
> Key: JBAS-2939
> URL: http://jira.jboss.com/jira/browse/JBAS-2939
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Remoting
> Reporter: Adrian Brock
> Assigned To: Tom Elrod
> Fix For: JBossAS-4.2.1.CR1
>
>
> Since JBAS-1442 it has been possible to change the invocation policies
> like local invocation optimizations.
> This is handled by subclassing the org.jboss.invocation.InvokerInterceptor
> The only one that is direclty supported by simple configuration is whether
> marshalling of invocations should take place.
> This feature request is to deal with the more common polices
> like turning off the local optimization when you want to force load
> balancing to an SLSB even though it is availabe locally.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Updated: (JBAS-1305) JSR77: ServiceModule should have a parent module to define the scope
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1305?page=all ]
Dimitris Andreadis updated JBAS-1305:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
(was: JBossAS-5.0.1.CR1)
Assignee: (was: Dimitris Andreadis)
> JSR77: ServiceModule should have a parent module to define the scope
> --------------------------------------------------------------------
>
> Key: JBAS-1305
> URL: http://jira.jboss.com/jira/browse/JBAS-1305
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.1 Final
> Environment: Java version: 1.5.0,Sun Microsystems Inc.
> Java VM: Java HotSpot(TM) Server VM 1.5.0-b64,Sun Microsystems Inc.
> OS-System: Linux 2.4.21-4.EL,i386
> Reporter: Michael Kopp
> Fix For: JBossAS-4.2.1.CR1
>
>
> If one has two -service.xml files with the same filename in different locations in the ear, there will only ever be one respective ServiceModule in the J2EE Management.
> The reason for this is that there is no scope defined in the name, hence the filename has to be server-wide unique.
> A ServiceModule should have a parent module like the EjbModule, which should make it possible to:
> - have the same file name multiple times
> - on the Server
> - in one Application
> - link the ServiceModule to the Application it belongs to.
> Forum Topic: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862704#3862704
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months