Mailing list for the Jakarta Hivemind services microkernel

Rob Harrop (JIRA | 26 Nov 2008 03:20

[jira] Created: (HIVEMIND-213) MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle

MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle
-------------------------------------------------------------------------------------

                 Key: HIVEMIND-213
                 URL: https://issues.apache.org/jira/browse/HIVEMIND-213
             Project: HiveMind
          Issue Type: Bug
          Components: framework
    Affects Versions: 1.1.1
            Reporter: Rob Harrop

MessageFormatter always ignores the ClassLoader of referenceClass when loading resource bundles. This
makes using HiveMind in OSGi very difficult.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

headers

Rob Harrop (JIRA | 27 Nov 2008 00:40

[jira] Updated: (HIVEMIND-213) MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle


     [
https://issues.apache.org/jira/browse/HIVEMIND-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Harrop updated HIVEMIND-213:
--------------------------------

    Attachment: MessageFormatter.java

Updated version of MessageFormatter that passes the test case

> MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle
> -------------------------------------------------------------------------------------
>
>                 Key: HIVEMIND-213
>                 URL: https://issues.apache.org/jira/browse/HIVEMIND-213
>             Project: HiveMind
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 1.1.1
>            Reporter: Rob Harrop
>         Attachments: HIVEMIND-213.zip, MessageFormatter.java
>
>
> MessageFormatter always ignores the ClassLoader of referenceClass when loading resource bundles.
This makes using HiveMind in OSGi very difficult.

--

-- 
This message is automatically generated by JIRA.
-

(Continue reading)

headers

Rob Harrop (JIRA | 27 Nov 2008 00:38

[jira] Updated: (HIVEMIND-213) MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle


     [
https://issues.apache.org/jira/browse/HIVEMIND-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Harrop updated HIVEMIND-213:
--------------------------------

    Attachment: HIVEMIND-213.zip

Test case in driver project. You'll need to munge the classpath a little bit.

I created a version of MessageFormatter against 1.1.1 that passes the test - I'll submit that next.

> MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle
> -------------------------------------------------------------------------------------
>
>                 Key: HIVEMIND-213
>                 URL: https://issues.apache.org/jira/browse/HIVEMIND-213
>             Project: HiveMind
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 1.1.1
>            Reporter: Rob Harrop
>         Attachments: HIVEMIND-213.zip
>
>
> MessageFormatter always ignores the ClassLoader of referenceClass when loading resource bundles.
This makes using HiveMind in OSGi very difficult.

--

--

(Continue reading)

headers

Rob Harrop (JIRA | 26 Nov 2008 17:34

[jira] Commented: (HIVEMIND-213) MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle


    [
https://issues.apache.org/jira/browse/HIVEMIND-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651048#action_12651048
] 

Rob Harrop commented on HIVEMIND-213:
-------------------------------------

If you are happy to accept something like that then that won't be a problem. I'll try and get on that today.

Rob

> MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle
> -------------------------------------------------------------------------------------
>
>                 Key: HIVEMIND-213
>                 URL: https://issues.apache.org/jira/browse/HIVEMIND-213
>             Project: HiveMind
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 1.1.1
>            Reporter: Rob Harrop
>
> MessageFormatter always ignores the ClassLoader of referenceClass when loading resource bundles.
This makes using HiveMind in OSGi very difficult.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

(Continue reading)

headers

Ilya Zverev (JIRA | 16 Feb 2007 16:52

[jira] Commented: (HIVEMIND-200) Hivemind configuration injection always produces a List


    [
https://issues.apache.org/jira/browse/HIVEMIND-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473735
] 

Ilya Zverev commented on HIVEMIND-200:
--------------------------------------

Suddenly I found this bug in Hivemind project, but actually it's bug in Tapestry framework, not in hivemind.
The problem is that Tapestry always sends Object.class as required object type to hivemind, instead of
using actual property type from the component template.

> Hivemind configuration injection always produces a List
> -------------------------------------------------------
>
>                 Key: HIVEMIND-200
>                 URL: https://issues.apache.org/jira/browse/HIVEMIND-200
>             Project: HiveMind
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 1.1.1
>            Reporter: Ilya Zverev
>
> Suppose we need to create <configuration> in hivemodule.xml which holds a simple map. As the
documentation states, all we need is to specify key-attribute parameter and write a simple translating rule.
> Then in .jwc we write something like this:
> <inject property="map" object="configuration:somemodule.ConfigMap"/>
> <component id="test" type="Insert">
>     <binding name="value" value="map.get('someKey')"/>
> </component>

(Continue reading)

headers

Howard M. Lewis Ship (JIRA | 19 Dec 2005 16:39

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12360831 ] 

Howard M. Lewis Ship commented on HIVEMIND-162:
-----------------------------------------------

Just finished adding a type cache to ModuleImpl.

It's always interesting to see the law of unintended consequences. I didn't add a type map to ModuleImpl
initially because the class loader will cache results.  Later, we added partial class names, which should
have forced a re-evaluation of the ModuleImpl decision ... but, alas, it required a dilligent user to spot
the bug.

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin
>     Assignee: Howard M. Lewis Ship
>  Attachments: hivemind-1.2-alpha-1.jar
>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible

(Continue reading)

headers

Jeff Lubetkin (JIRA | 12 Dec 2005 20:37

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12360245 ] 

Jeff Lubetkin commented on HIVEMIND-162:
----------------------------------------

I should note, in addition, that our application has a fairly long and complex classpath, which could
theoretically be contributing to the problem.

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin
>  Attachments: hivemind-1.2-alpha-1.jar
>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were
bottlenecked on a synchronized method in HiveMind

(Continue reading)

headers

Howard Lewis Ship | 19 Dec 2005 15:25

Re: [jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

Well, I'm glad I haven't closed the bug yet; I'll look into adding a
class cache to ModuleImpl.

On 12/12/05, Jeff Lubetkin (JIRA) <hivemind-dev <at> jakarta.apache.org> wrote:
>     [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12360245 ]
>
> Jeff Lubetkin commented on HIVEMIND-162:
> ----------------------------------------
>
> I should note, in addition, that our application has a fairly long and complex classpath, which could
theoretically be contributing to the problem.
>
> > Performance bottleneck with threaded services
> > ---------------------------------------------
> >
> >          Key: HIVEMIND-162
> >          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
> >      Project: HiveMind
> >         Type: Bug
> >   Components: framework
> >     Versions: 1.1
> >  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> > Quad Xeon 3.2GHz, 1GB RAM
> >     Reporter: Jeff Lubetkin
> >  Attachments: hivemind-1.2-alpha-1.jar
> >
> > Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> > We've been running some perf tests using the Grinder (with 20 threads) generating as much load as
possible on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have

(Continue reading)

headers

Jeff Lubetkin (JIRA | 12 Dec 2005 20:27

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12360242 ] 

Jeff Lubetkin commented on HIVEMIND-162:
----------------------------------------

I believe I have found the underlying issue.  The synchronization was something of a red herring.  What's
really going on is that Hivemind is spending a large amount of time failing to load classes.  From org.apache.hivemind.impl.ModuleImpl:

    public Class resolveType(String type)
    {
        Class result = _resolver.checkForClass(type);

        if (result == null)
            result = _resolver.checkForClass(_packageName + "." + type);

        if (result == null)
            throw new ApplicationRuntimeException(ImplMessages.unableToConvertType(
                    type,
                    _packageName));

        return result;
    }

If, in your hivemodule, you have a threaded service that doesn't fully specify its class package, every
request for it causes a classloader failure before the classloader success.  These classloader failures
seem to not be entirely cheap.  By simply changing the "class" attribute of "RequestGlobals" in
tapestry.globals.xml from "impl.RequestGlobalsImpl" to
"org.apache.tapestry.services.impl.RequestGlobalsImpl", we saw throughput double to over 1000 TPS
with 85% CPU utilization.  This continued even with hivemind.jar returned to 1.1 from the 1.2-alpha-1
that Howard provided, so it seems the classloader issue was the underlying cause of the synch issue.  I even

(Continue reading)

headers

Johan Lindquist (JIRA | 10 Dec 2005 10:49

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12360038 ] 

Johan Lindquist commented on HIVEMIND-162:
------------------------------------------

Having poked around a little I saw that the pooled service model is using the same pattern as the threaded
model - should this also be have the same changes applied to it? 

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin
>  Attachments: hivemind-1.2-alpha-1.jar
>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were
bottlenecked on a synchronized method in HiveMind

(Continue reading)

headers

Johan Lindquist (JIRA | 8 Dec 2005 11:08

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359721 ] 

Johan Lindquist commented on HIVEMIND-162:
------------------------------------------

A possibly naive comment - what if the DefaultClassResolver would cache some instances of classes?  If the
create instance forces a forName for each instance created, this could help?

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin
>  Attachments: hivemind-1.2-alpha-1.jar
>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were
bottlenecked on a synchronized method in HiveMind

(Continue reading)

headers

Jeff Lubetkin (JIRA | 7 Dec 2005 19:56

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359617 ] 

Jeff Lubetkin commented on HIVEMIND-162:
----------------------------------------

Well, this is an improvement, but not a huge one (510 TPS now, still about 45% cpu).  We seem to now be hitting a
sync bottleneck on the classloader.  Of 22 http daemon threads, 17 are blocked on
java.lang.Class.forName0, a native method (see Stack #1).  One is actually inside that lock (see Stack
#2) and the rest are either waiting for a request to handle, or handling an actual request.

Given that the thread inside the lock is doing filesystem stuff, could we be I/O bound here?

=========== STACK #1 ============
    [java] "http-0.0.0.0-8080-22" daemon prio=1 tid=0x8ae379d8 nid=0x38c4 waiting for monitor entry [0x8a91f000..0x8a9204c0]
    [java]     at java.lang.Class.forName0(Native Method)
    [java]     at java.lang.Class.forName(Class.java:242)
    [java]     at org.apache.hivemind.impl.DefaultClassResolver.lookupClass(DefaultClassResolver.java:101)
    [java]     at org.apache.hivemind.impl.DefaultClassResolver.checkForClass(DefaultClassResolver.java:108)
    [java]     at org.apache.hivemind.impl.ModuleImpl.resolveType(ModuleImpl.java:191)
    [java]     at org.apache.hivemind.util.InstanceCreationUtils.createInstance(InstanceCreationUtils.java:50)
    [java]     at org.apache.hivemind.impl.CreateClassServiceConstructor.constructCoreServiceImplementation(CreateClassServiceConstructor.java:35)
    [java]     at org.apache.hivemind.impl.servicemodel.AbstractServiceModelImpl.constructCoreServiceImplementation(AbstractServiceModelImpl.java:108)
    [java]     at org.apache.hivemind.impl.servicemodel.ThreadedServiceModel.constructInstanceForCurrentThread(ThreadedServiceModel.java:164)
    [java]     at org.apache.hivemind.impl.servicemodel.ThreadedServiceModel.getServiceImplementationForCurrentThread(ThreadedServiceModel.java:155)
    [java]     at $RequestGlobals_108065173f1._service($RequestGlobals_108065173f1.java)
    [java]     at $RequestGlobals_108065173f1.store($RequestGlobals_108065173f1.java)
    [java]     at $RequestGlobals_108065173f2.store($RequestGlobals_108065173f2.java)
    [java]     at org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.java:49)
    [java]     at $ServletRequestServicer_108065173d7.service($ServletRequestServicer_108065173d7.java)
    [java]     at org.apache.tapestry.request.DecodedRequestInjector.service(DecodedRequestInjector.java:55)

(Continue reading)

headers

Jeff Lubetkin (JIRA | 7 Dec 2005 17:58

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359602 ] 

Jeff Lubetkin commented on HIVEMIND-162:
----------------------------------------

I've picked up the new jar and we'll re-run our tests with it as soon as our load tester arrives for the day. 
Should have results by noon (Pacific).

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin
>  Attachments: hivemind-1.2-alpha-1.jar
>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were
bottlenecked on a synchronized method in HiveMind

(Continue reading)

headers

James Carman (JIRA | 7 Dec 2005 15:55

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359584 ] 

James Carman commented on HIVEMIND-162:
---------------------------------------

Also, the backport is for JDK 1.4.  Our source is supposed to adhere to 1.3 and the target is 1.1 (at least
that's what it says in the hivebuild/module.properties file.  So, even if we could add a dependency, I
don't think our target VMs could support it.

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin

>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were

(Continue reading)

headers

James Carman (JIRA | 7 Dec 2005 15:41

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359582 ] 

James Carman commented on HIVEMIND-162:
---------------------------------------

Good point, but we can't use it.  HiveMind tries to avoid dependencies (and thus "jar hell") as much as
possible.  I believe we can get by on the core (pre-JDK5) Java API in this case.

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin

>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were
bottlenecked on a synchronized method in HiveMind

(Continue reading)

headers

Jesse Kuhnert (JIRA | 7 Dec 2005 15:37

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359580 ] 

Jesse Kuhnert commented on HIVEMIND-162:
----------------------------------------

Using some of the concurrent API to do these synchronizations may also help quite a bit. It's part of 1.5
already but still downloadable seperately. 

Using more efficient "Monitors" and such to synchronize access will make the threading infrastructure
much more scalable. I've personally done a lot of work in the area of multi-cpu environment appserver-ish
threading management and think the concurrent api has answers to most of your needs..

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin

>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some

(Continue reading)

headers

James Carman (JIRA | 7 Dec 2005 14:55

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359577 ] 

James Carman commented on HIVEMIND-162:
---------------------------------------

We may still have trouble with synchronization (assuming this is the real culprit) since the getService()
method is also synchronized.  I think we can maybe make that one non-synchronized also, since everything
is based on a ThreadLocal variable.

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin

>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were

(Continue reading)

headers

Jeff Lubetkin (JIRA | 7 Dec 2005 04:46

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359531 ] 

Jeff Lubetkin commented on HIVEMIND-162:
----------------------------------------

I'm kinda curious about that myself.  If by " I believe we can make that method non-synchronized" you mean
that simply removing the synchronized keyword will be fine, I'd be happy to rebuild hivemind with that
change and throw it on our test box.  If you have other changes in mind, I'd be happy to pre-flight them.

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin

>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were

(Continue reading)

headers

Howard M. Lewis Ship (JIRA | 7 Dec 2005 04:04

[jira] Commented: (HIVEMIND-162) Performance bottleneck with threaded services

    [ http://issues.apache.org/jira/browse/HIVEMIND-162?page=comments#action_12359523 ] 

Howard M. Lewis Ship commented on HIVEMIND-162:
-----------------------------------------------

I believe we can make that method non-synchronized.  What I'm not sure about is why having that one method
synchronized is causing such a large performance hit.

> Performance bottleneck with threaded services
> ---------------------------------------------
>
>          Key: HIVEMIND-162
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-162
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Linux 2.6.14.2, JBoss 4.0.3, Tomcat 5.5
> Quad Xeon 3.2GHz, 1GB RAM
>     Reporter: Jeff Lubetkin

>
> Note: This may be better classified as a Hivemind issue, but it's affecting Tapestry throughput so I'm
putting it here.
> We've been running some perf tests using the Grinder (with 20 threads) generating as much load as possible
on a single non-trivial page.  The page doesn't touch many of our biz logic services, but does have some
complex componentry to render.
> We were seeing performance ramp just fine until we reached about 200TPS, using only 50% CPU.  No matter how
many clients we threw at it, we couldn't get it any higher.   A thread dump showed that most threads were
bottlenecked on a synchronized method in HiveMind

(Continue reading)

headers

Steve Gibson | 28 Jun 2004 19:05

RE: [jira] Commented: (HIVEMIND-14) Add a new model named "new" to constuct the class

When I first saw this, it sounded like something you would use
BeanFactory for.

Steve Gibson

-----Original Message-----
From: hivemind-dev <at> jakarta.apache.org
[mailto:hivemind-dev <at> jakarta.apache.org] 
Sent: Monday, June 28, 2004 1:05 PM
To: hivemind-dev <at> jakarta.apache.org
Subject: [jira] Commented: (HIVEMIND-14) Add a new model named "new" to
constuct the class

The following comment has been added to this issue:

     Author: Howard M. Lewis Ship
    Created: Mon, 28 Jun 2004 10:03 AM
       Body:
You can implement this yourself, today, by defining your own
ServiceModel and ServiceModelFactory.

However, the call to getRegistry() would return the same instance ...
invoking a method on that instance would, inside some form of proxy,
create an instance of the service.

I would like to know *why* you feel you need this feature. What is your
use case and why does the threaded and pooled service models not meet
it?
---------------------------------------------------------------------
View this comment:

(Continue reading)

headers

Hensley, Richard | 21 May 2005 02:31

RE: [jira] Commented: (HIVEMIND-124) Report a proper message when a constructor argument in BuilderFactory is invalid

Knut,

Can you make a patch that does what you are talking about with the
ErrorHandler? I would like to see what you are talking about in my
environment. I'm most concerned about a typing error being very hard to
track down because the error message in misleading. We are still talking
about the case where SmartTranslator is not being used, the actual
translator being used is the ServiceTranslator, which should complain loudly
when it fails.

Richard

-----Original Message-----
From: Knut Wannheden (JIRA) [mailto:hivemind-dev <at> jakarta.apache.org] 
Sent: Friday, May 20, 2005 4:45 PM
To: Hensley, Richard
Subject: [jira] Commented: (HIVEMIND-124) Report a proper message when a
constructor argument in BuilderFactory is invalid

     [
http://issues.apache.org/jira/browse/HIVEMIND-124?page=comments#action_65899
]

Knut Wannheden commented on HIVEMIND-124:
-----------------------------------------

Yes, SmartTranslator is special because HiveMind uses it as the default. But
what also makes it special, which I think is what is most relevant in this
discussion, is the fact that it uses the passed 'propertyType' argument to
decide on how to parse the 'inputValue'. I think it would be unfortunate if

(Continue reading)

headers

Hensley, Richard | 20 May 2005 17:35

RE: [jira] Commented: (HIVEMIND-124) Report a proper message when a constructor argument in BuilderFactory is invalid

So, could you apply the special case SmartTranslator patch I sent in? 

-----Original Message-----
From: Knut Wannheden (JIRA) [mailto:hivemind-dev <at> jakarta.apache.org] 
Sent: Thursday, May 19, 2005 11:42 PM
To: Hensley, Richard
Subject: [jira] Commented: (HIVEMIND-124) Report a proper message when a
constructor argument in BuilderFactory is invalid

     [
http://issues.apache.org/jira/browse/HIVEMIND-124?page=comments#action_65824
]

Knut Wannheden commented on HIVEMIND-124:
-----------------------------------------

Whoops, seems like I didn't quite remember all of this.  Thanks for
refreshing my memory 

I agree with you, adding isAssignableToType() to Translator (and then also
ObjectProvider) is not a good idea.  It gets too hairy.

As an alternative to a special treatment of SmartTranslator (using
instanceof) we could plainly let the BuilderPropertyFacet log the error it
catches before returning false.  Then you should at least see what's going
on if you wade through the logs...

> Report a proper message when a constructor argument in BuilderFactory is
invalid
>

(Continue reading)

headers

James Carman (JIRA | 26 Nov 2008 17:22

[jira] Commented: (HIVEMIND-213) MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle


    [
https://issues.apache.org/jira/browse/HIVEMIND-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651045#action_12651045
] 

James Carman commented on HIVEMIND-213:
---------------------------------------

You may not need OSGI.  Just set up your own classloader and assert that it's used somehow?

> MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle
> -------------------------------------------------------------------------------------
>
>                 Key: HIVEMIND-213
>                 URL: https://issues.apache.org/jira/browse/HIVEMIND-213
>             Project: HiveMind
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 1.1.1
>            Reporter: Rob Harrop
>
> MessageFormatter always ignores the ClassLoader of referenceClass when loading resource bundles.
This makes using HiveMind in OSGi very difficult.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

(Continue reading)

headers

Rob Harrop (JIRA | 26 Nov 2008 17:16

[jira] Commented: (HIVEMIND-213) MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle


    [
https://issues.apache.org/jira/browse/HIVEMIND-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651044#action_12651044
] 

Rob Harrop commented on HIVEMIND-213:
-------------------------------------

James,

I'll do my best. Getting a simple case to show this is going to be difficult because it needs to run in OSGi.
I'll see what I can do about providing a really simple Equinox app that highlights this problem.

Rob

> MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle
> -------------------------------------------------------------------------------------
>
>                 Key: HIVEMIND-213
>                 URL: https://issues.apache.org/jira/browse/HIVEMIND-213
>             Project: HiveMind
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 1.1.1
>            Reporter: Rob Harrop
>
> MessageFormatter always ignores the ClassLoader of referenceClass when loading resource bundles.
This makes using HiveMind in OSGi very difficult.

--

--

(Continue reading)

headers

James Carman (JIRA | 26 Nov 2008 04:26

[jira] Commented: (HIVEMIND-213) MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle


    [
https://issues.apache.org/jira/browse/HIVEMIND-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650851#action_12650851
] 

James Carman commented on HIVEMIND-213:
---------------------------------------

Do you have a test case patch?  The developers of this library don't have much time to devote to it these days,
but I'd be willing to tackle it if you give me a test case that I need to make work. :)

> MessageFormatter should use ClassLoader of referenceClass when loading ResourceBundle
> -------------------------------------------------------------------------------------
>
>                 Key: HIVEMIND-213
>                 URL: https://issues.apache.org/jira/browse/HIVEMIND-213
>             Project: HiveMind
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 1.1.1
>            Reporter: Rob Harrop
>
> MessageFormatter always ignores the ClassLoader of referenceClass when loading resource bundles.
This makes using HiveMind in OSGi very difficult.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

(Continue reading)

headers

Thibault Cuvilleir (JIRA | 16 Jun 2005 15:31

[jira] Created: (HIVEMIND-132) <set-servive> and interface inheritence

<set-servive> and interface inheritence
---------------------------------------

         Key: HIVEMIND-132
         URL: http://issues.apache.org/jira/browse/HIVEMIND-132
     Project: HiveMind
        Type: Bug
  Components: framework  
    Versions: 1.1    
 Environment: Windows XP, Hivemind 1.1 beta, JDK 1.4
    Reporter: Thibault Cuvilleir

Hi !

=> A is not a service interface
Interface A { ...}

=> B is a Hivemind service interface
interface B extends A {...}

=> BService is a service-id  declared in the module desriptor. BService implents B

class BServiceImpl implements B {...}

=> CService has a dependance to B, but wants to use the interface A:

class public MyServiceImpl  implements C {
     private A _otherService;

     public void setOtherService(A service) { ... }

(Continue reading)

headers

Howard M. Lewis Ship (JIRA | 16 Jun 2005 16:24

[jira] Commented: (HIVEMIND-132) <set-servive> and interface inheritence

    [ http://issues.apache.org/jira/browse/HIVEMIND-132?page=comments#action_12313829 ] 

Howard M. Lewis Ship commented on HIVEMIND-132:
-----------------------------------------------

This would be difficult to to using the current system, which is very loath to instantiate even the service
interface (if this was not so, then Spring would become a required dependency when using hivemind-lib,
for example). It also adds a lot of ambiguities ... do you mean exact match or best match?  What is a best match?

> <set-servive> and interface inheritence
> ---------------------------------------
>
>          Key: HIVEMIND-132
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-132
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Windows XP, Hivemind 1.1 beta, JDK 1.4
>     Reporter: Thibault Cuvilleir

>
> Hi !
> => A is not a service interface
> Interface A { ...}
> => B is a Hivemind service interface
> interface B extends A {...}
> => BService is a service-id  declared in the module desriptor. BService implents B
> class BServiceImpl implements B {...}
> => CService has a dependance to B, but wants to use the interface A:

(Continue reading)

headers

Knut Wannheden (JIRA | 16 Jun 2005 16:13

[jira] Commented: (HIVEMIND-132) <set-servive> and interface inheritence

    [ http://issues.apache.org/jira/browse/HIVEMIND-132?page=comments#action_12313827 ] 

Knut Wannheden commented on HIVEMIND-132:
-----------------------------------------

Thibault,

This should work. I just tried the following which works.

public interface A {...}
public interface B extends A {...}
public class BImpl implements B {...}

public interface C {...}
public class CImpl implements C {
 public void setA(A a) {...}
 ...
}

<module id="test" version="1.0.0">

 <service-point id="B" interface="B">
  <create-instance class="BImpl"/>
 </service-point>

 <service-point id="C" interface="C">
  <invoke-factory>
   <construct class="CImpl">
    <set-service service-id="B" property="a"/>
   </construct>

(Continue reading)