[JBoss JIRA] Assigned: (JBAS-2695) LRUStatefulContextCachePolicy implementation of maxBeanLife removal is flawed
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2695?page=all ]
Dimitris Andreadis reassigned JBAS-2695:
----------------------------------------
Assignee: Ben Wang
We have deferred this issue for some time now, maybe Ben can give it a try now.
> LRUStatefulContextCachePolicy implementation of maxBeanLife removal is flawed
> -----------------------------------------------------------------------------
>
> Key: JBAS-2695
> URL: http://jira.jboss.com/jira/browse/JBAS-2695
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB2
> Affects Versions: JBossAS-3.2.8RC1, JBossAS-4.0.3 SP1
> Reporter: Scott M Stark
> Assigned To: Ben Wang
> Priority: Critical
> Fix For: JBossAS-4.0.5.CR1
>
>
> The RemoverTask of the org.jboss.ejb.plugins.LRUStatefulContextCachePolicy performs removal of passivated beans based on a maxBeanLife - maxBeanAge diff. This is invalid for beans passivated due to size. The calculation should be maxBeanLife - (the per bean instance time of inactivity). The reason is a bean may be passivated very quickly due to cache size constraints and if the maxBeanLife - maxBeanAge == 0, just a quickly thrown away.
--
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
20 years
[JBoss JIRA] Commented: (JBAS-1180) bi-pass JacORB interceptors for purely local invocations
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1180?page=comments#action_12339594 ]
Dimitris Andreadis commented on JBAS-1180:
------------------------------------------
Again, we need to see if this will be solved in JacORB somehow. I just checked in their bugzilla database and there is no progress at all on the 2 issues submitted by Kevin.
> bi-pass JacORB interceptors for purely local invocations
> --------------------------------------------------------
>
> Key: JBAS-1180
> URL: http://jira.jboss.com/jira/browse/JBAS-1180
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP service
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assigned To: Francisco Reverbel
> Fix For: JBossAS-4.0.5.CR1
>
>
> SourceForge Submitter: marklittle .
> I registered the following issue
> (http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?
> id=526) with JacORB bugzilla a couple of weeks ago, but
> no response so far. I think it's sufficiently important to
> register here too in case you are able to do something
> for JBoss.
> In the current implementation of JacORB (2.2), if I
> register an interceptor with the ORB, then
> it appears that all invocations to all objects go through
> that interceptor,
> even if they are co-located with the invoker. I
> understand that rational given
> the PI specification and the original intention behind
> that work: to make
> local invocations and remote invocations similar.
> However, most ORBs provide a way of doing a local, no-
> interceptor
> optimization. The JDK 1.4 ORB is one example (though
> that takes the other
> extreme and won't invoke interceptors on any local
> object).
> Orbix 2000, for example, supports multiple ORBs and
> POAs within the same VM,
> and interceptors are registered on a per-ORB basis, not
> a per VM basis as
> appears to be the case with JacORB. You can also turn
> on local optimizations
> for the individual ORBs.
> The reason for asking for this optimization is
> performance. With a very simple
> test, where the interceptor does nothing, we see a 66%
> degredation in
> performance for local calls. For example, with no
> interceptors we can get > 3000 invocations, whereas
> with a "null" interceptor this is around 1000.
--
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
20 years
[JBoss JIRA] Updated: (JBAS-1180) bi-pass JacORB interceptors for purely local invocations
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1180?page=all ]
Dimitris Andreadis updated JBAS-1180:
-------------------------------------
Comment: was deleted
> bi-pass JacORB interceptors for purely local invocations
> --------------------------------------------------------
>
> Key: JBAS-1180
> URL: http://jira.jboss.com/jira/browse/JBAS-1180
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP service
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assigned To: Francisco Reverbel
> Fix For: JBossAS-4.0.5.CR1
>
>
> SourceForge Submitter: marklittle .
> I registered the following issue
> (http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?
> id=526) with JacORB bugzilla a couple of weeks ago, but
> no response so far. I think it's sufficiently important to
> register here too in case you are able to do something
> for JBoss.
> In the current implementation of JacORB (2.2), if I
> register an interceptor with the ORB, then
> it appears that all invocations to all objects go through
> that interceptor,
> even if they are co-located with the invoker. I
> understand that rational given
> the PI specification and the original intention behind
> that work: to make
> local invocations and remote invocations similar.
> However, most ORBs provide a way of doing a local, no-
> interceptor
> optimization. The JDK 1.4 ORB is one example (though
> that takes the other
> extreme and won't invoke interceptors on any local
> object).
> Orbix 2000, for example, supports multiple ORBs and
> POAs within the same VM,
> and interceptors are registered on a per-ORB basis, not
> a per VM basis as
> appears to be the case with JacORB. You can also turn
> on local optimizations
> for the individual ORBs.
> The reason for asking for this optimization is
> performance. With a very simple
> test, where the interceptor does nothing, we see a 66%
> degredation in
> performance for local calls. For example, with no
> interceptors we can get > 3000 invocations, whereas
> with a "null" interceptor this is around 1000.
--
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
20 years
[JBoss JIRA] Commented: (JBAS-1182) Thread creation during deactivate_object
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1182?page=comments#action_12339593 ]
Dimitris Andreadis commented on JBAS-1182:
------------------------------------------
Again, we need to consider whether the issue will be fixed in JacORB, for incorporation into JBoss 4.0.5
> Thread creation during deactivate_object
> ----------------------------------------
>
> Key: JBAS-1182
> URL: http://jira.jboss.com/jira/browse/JBAS-1182
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP service
> Reporter: SourceForge User
> Assigned To: Francisco Reverbel
> Fix For: JBossAS-4.0.5.CR1
>
>
> SourceForge Submitter: kevinconner .
> This is a duplicate of bug 527 in the JacORB database.
> It is being submitted here so that a patch may be
> applied to the JBoss patched version of JacORB.
> http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527
> The deactiviation of an object causes Thread creation
> in AOM.remove. Would it
> be possible to use a thread pool instead of creating
> new threads?
> A possible solution could be to have the
> RequestController provide a
> notification mechanism (instead of a thread waiting on
> object completion) and
> have the notification request work from the thread pool.
> The attached patch uses a threadpool to prevent the
> thread creation but I don't
> believe it is the best solution.
> Index: AOM.java
> ===================================================================
> RCS file:
> /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v
> retrieving revision 1.29
> diff -u -r1.29 AOM.java
> --- AOM.java 6 May 2004 12:40:00 -0000 1.29
> +++ AOM.java 21 Oct 2004 14:38:11 -0000
> @@ -27,6 +27,9 @@
> import org.jacorb.poa.util.ByteArrayKey;
> import org.jacorb.poa.util.POAUtil;
> import org.jacorb.poa.util.StringPair;
> +import org.jacorb.util.threadpool.Consumer;
> +import org.jacorb.util.threadpool.ConsumerFactory;
> +import org.jacorb.util.threadpool.ThreadPool;
>
> import
> org.omg.PortableServer.POAPackage.ObjectAlreadyActive;
> import org.omg.PortableServer.POAPackage.ObjectNotActive;
> @@ -69,6 +72,23 @@
> /** a lock to protect two consecutive operations
> on the list, used
> in remove() */
> private Object deactivationListLock =
> new Object();
> +
> + private Consumer deactivationConsumer = new
> Consumer() {
> + public void doWork(final Object job) {
> + try {
> + ((Runnable)job).run() ;
> + } catch (final Throwable th) {
> + logger.info("Unhandled exception
> during deactivation", th);
> + }
> + }
> + } ;
> + private ConsumerFactory
> deactivationConsumerFactory = new ConsumerFactory() {
> + public Consumer create() {
> + return deactivationConsumer ;
> + }
> + } ;
> +
> + private ThreadPool deactivationPool = new
> ThreadPool(deactivationConsumerFactory) ;
>
> private AOM()
> {
> @@ -348,8 +368,7 @@
> final POA poa_ = poa;
> final boolean cleanupInProgress_ =
> cleanupInProgress;
>
> - Thread thread = new Thread("AOM_RemovalThread")
> - {
> + final Runnable job = new Runnable() {
> public void run()
> {
> _remove(
> @@ -361,8 +380,8 @@
> );
> }
> };
> -
> - thread.start();
> +
> + deactivationPool.putJob(job) ;
> }
--
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
20 years
[JBoss JIRA] Updated: (JBAS-1182) Thread creation during deactivate_object
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1182?page=all ]
Dimitris Andreadis updated JBAS-1182:
-------------------------------------
Comment: was deleted
> Thread creation during deactivate_object
> ----------------------------------------
>
> Key: JBAS-1182
> URL: http://jira.jboss.com/jira/browse/JBAS-1182
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP service
> Reporter: SourceForge User
> Assigned To: Francisco Reverbel
> Fix For: JBossAS-4.0.5.CR1
>
>
> SourceForge Submitter: kevinconner .
> This is a duplicate of bug 527 in the JacORB database.
> It is being submitted here so that a patch may be
> applied to the JBoss patched version of JacORB.
> http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527
> The deactiviation of an object causes Thread creation
> in AOM.remove. Would it
> be possible to use a thread pool instead of creating
> new threads?
> A possible solution could be to have the
> RequestController provide a
> notification mechanism (instead of a thread waiting on
> object completion) and
> have the notification request work from the thread pool.
> The attached patch uses a threadpool to prevent the
> thread creation but I don't
> believe it is the best solution.
> Index: AOM.java
> ===================================================================
> RCS file:
> /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v
> retrieving revision 1.29
> diff -u -r1.29 AOM.java
> --- AOM.java 6 May 2004 12:40:00 -0000 1.29
> +++ AOM.java 21 Oct 2004 14:38:11 -0000
> @@ -27,6 +27,9 @@
> import org.jacorb.poa.util.ByteArrayKey;
> import org.jacorb.poa.util.POAUtil;
> import org.jacorb.poa.util.StringPair;
> +import org.jacorb.util.threadpool.Consumer;
> +import org.jacorb.util.threadpool.ConsumerFactory;
> +import org.jacorb.util.threadpool.ThreadPool;
>
> import
> org.omg.PortableServer.POAPackage.ObjectAlreadyActive;
> import org.omg.PortableServer.POAPackage.ObjectNotActive;
> @@ -69,6 +72,23 @@
> /** a lock to protect two consecutive operations
> on the list, used
> in remove() */
> private Object deactivationListLock =
> new Object();
> +
> + private Consumer deactivationConsumer = new
> Consumer() {
> + public void doWork(final Object job) {
> + try {
> + ((Runnable)job).run() ;
> + } catch (final Throwable th) {
> + logger.info("Unhandled exception
> during deactivation", th);
> + }
> + }
> + } ;
> + private ConsumerFactory
> deactivationConsumerFactory = new ConsumerFactory() {
> + public Consumer create() {
> + return deactivationConsumer ;
> + }
> + } ;
> +
> + private ThreadPool deactivationPool = new
> ThreadPool(deactivationConsumerFactory) ;
>
> private AOM()
> {
> @@ -348,8 +368,7 @@
> final POA poa_ = poa;
> final boolean cleanupInProgress_ =
> cleanupInProgress;
>
> - Thread thread = new Thread("AOM_RemovalThread")
> - {
> + final Runnable job = new Runnable() {
> public void run()
> {
> _remove(
> @@ -361,8 +380,8 @@
> );
> }
> };
> -
> - thread.start();
> +
> + deactivationPool.putJob(job) ;
> }
--
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
20 years
[JBoss JIRA] Resolved: (JGRP-247) Change semantics of viewChange() on MuxChannel
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-247?page=all ]
Bela Ban resolved JGRP-247.
---------------------------
Resolution: Done
fixed, and update documentation, plus 2 unit tests (MultiplexerTest and MultiplexerViewTest)
> Change semantics of viewChange() on MuxChannel
> ----------------------------------------------
>
> Key: JGRP-247
> URL: http://jira.jboss.com/jira/browse/JGRP-247
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9.2, 2.2.9.1, 2.2.8, 2.2.9, 2.3
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.4
>
>
> Multiplexer needs to override viewChange(), where the the view is the view of all hosts which have the application ! Example: H1:A1,A2,A3; H2:A3, then A3 gets a viewChange(H1,H2) and the others, A1 and A2 just get a viewChange(H1).
> This is a semantic change to MuxChannel. A view received this way basically means "a list of all hosts on which *my* application (e.g. A1) is currently running. When an application goes down, or is started, then a new view change will be sent to the applications of the same type, e.g. all A1's.
> This also affects the determination of a coordinator:
> * Issue: H1:A2,A3; H2:A1,A2, coord for A1 is H2, and for A2 it is H1. This is different from the JGroups coord, so we have to tweak MuxChannel?.getState() if and only if the address of the coord is null, then we determine the coord to be the application level coord.
> If a client wants to get a list of *all* nodes in the current cluster, we may have to provide a new method in MuxChannel.
--
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
20 years
[JBoss JIRA] Created: (JGRP-261) The return
by Serhiy Yevtushenko (JIRA)
The return
-----------
Key: JGRP-261
URL: http://jira.jboss.com/jira/browse/JGRP-261
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1
Environment: Windows XP, Sun
Reporter: Serhiy Yevtushenko
Assigned To: Bela Ban
Attachments: jgroupsbug.zip
This bug was revealed by the unit testing, when trying to update to the version 2.3 SP1 from 2.2.9.1
The call to the PpcDispatcher in the version 2.2.9.1 works properly.
When performing the test example, it can be seen, that in version 2.3 SP1 the methods are being called on the server, but the results of the call are not delivered to the client.
The output of the test example for the version 2.2.9.1 is the following:
--not significant part skipped
JGroupsSendingModeTest$ServerASkeleton.getConnectionPoint192.168.33.113:1914
JGroupsSendingModeTest$ServerBSkeleton.getConnectionPoint111.111.111.111:5000
rspList = [sender=192.168.33.113:1926, retval=111.111.111.111:5000, received=true, suspected=false]
[sender=192.168.33.113:1914, retval=192.168.33.113:1914, received=true, suspected=false]
ipAdressesList = [111.111.111.111:5000, 192.168.33.113:1914]
--not significant part skipped
The output of the example for the version 2.3 SP1 is the following one:
--not significant part skipped
JGroupsSendingModeTest$ServerASkeleton.getConnectionPoint192.168.33.113:1956
JGroupsSendingModeTest$ServerBSkeleton.getConnectionPoint111.111.111.111:5000
rspList = [sender=192.168.33.113:1959, retval=null, received=true, suspected=false]
[sender=192.168.33.113:1956, retval=null, received=true, suspected=false]
ipAdressesList = []
--not significant part skipped
The investigation of the logs has shown, that in log for the version 2.3 SP1 the following message is being present :
[ERROR] thread [UpHandler (QUEUE)] class [org.jgroups.blocks.GroupRequest] exception=java.lang.IllegalArgumentException: java.io.StreamCorruptedException: invalid stream header
This exception is thrown in the method GroupRequest.receiveResponse(Message m) , in the following block of code:
if(m.getLength() > 0) {
try {
val=m.getObject();
}
catch(Exception e) {
if(log.isErrorEnabled()) log.error("exception=" + e);
}
}
--
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
20 years