[EJB 3.0] - Re: 10,000 Recorc Per Second (In EJB 3.0)
by grdzeli_kaci
hi all,
great tnx for your posts,
yesterday i tried to count real amount of records and i got i need 2000 operation in one second, (operation means some selects and 5 insert into separate tables)
fhh
anonymous wrote :
| If all you want to do is to insert 10.000 meaningless records than write a stored procedure.
| If not - well, tell us what you want to do.
|
i thought on this idea, but i don't need business logic into database, it is business request.
genman
anonymous wrote :
| Let me just say that you first need to understand what it takes to get Oracle to insert 10,000 records per second
|
i tried to insert 10 000 record into oracle database from pl/sql developer over network and it takes 5 minutes.
oskar.carlstedt Post
anonymous wrote :
| Using EJBs here is probably not the best way to go. Doing so will cause the container to create a lot of insert statements - too many to get the performance you want. If I'm wrong here, let me know.
|
you are right, it is not correct way to persist 2000 record using entity beans and hibernate,
but i thought, maybe is there any performance configuration which can increase performance,
anonymous wrote :
| Make sure you are using the native Oracle driver
|
[url]
http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc... [/url]
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039128#4039128
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039128
19 years
[Clustering/JBoss] - Wrong targets come to LoadBalancePolicy
by kkrivopustov
Hello
I'm using cluster on JBoss 4.0.4.GA and I want to implement a custom load-balancing policy. Unfortunately I faced a problem with the wrong list of targets in FamilyClusterInfo. Below I'll try to explain the situation.
I have 2 EJB3 stateless beans FooBean and BarBean annotated with @Clustered(partition = "ShamrockPartition", loadBalancePolicy = MyLoadBalancePolicy.class)
The policy is simple:
| public class MyLoadBalancePolicy extends FirstAvailableIdenticalAllProxies {
|
| public Object chooseTarget(FamilyClusterInfo clusterFamily) {
| return super.chooseTarget(clusterFamily);
| }
|
| public Object chooseTarget(FamilyClusterInfo clusterFamily, Invocation routingDecision) {
| System.out.println("Family: " + clusterFamily.getFamilyName()
| + ", View: " + clusterFamily.getCurrentViewId() + ", Targets: " + clusterFamily.getTargets());
| return super.chooseTarget(clusterFamily, routingDecision);
| }
| }
I deploy application onto 2 servers and then start them. A client is simply invokes each bean many times consequently. Here is the output:
| Family: FooBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| Family: BarBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/]]
| iteration 0 success
| Family: FooBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| Family: BarBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/]]
| iteration 1 success
| Family: FooBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| Family: BarBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/]]
| iteration 2 success
|
As you can see, there is always wrong targets for bean BarBean. If I restart servers, the situation changes, but usually one of the beans or both have wrong targets.
The only thing which help is hot redeploy of the application, after that all beans have correct targets.
I've investigated a little and found that method FamilyClusterInfoImpl.updateClusterInfo() is executed with correct targets after each bean invocation and it updates the FamilyClusterInfo.
But when FamilyClusterInfo is obtained from ClusteringTargetsRepository, it is updated again by old incorrect values. If I comment out the line (comment "should not happen: possible if redeploy after undeploy fails" is not mine)
| family.updateClusterInfo (targets, viewId); // should not happen: possible if redeploy after undeploy fails
|
everithing works fine and client output looks correct:
| Family: FooBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| Family: BarBeansocketShamrockPartition, View: 0, Targets: [InvokerLocator [socket://192.168.3.71:3873/]]
| iteration 0 success
| Family: FooBeansocketShamrockPartition, View: -1211536571, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| Family: BarBeansocketShamrockPartition, View: -1211536571, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| iteration 1 success
| Family: FooBeansocketShamrockPartition, View: -1211536571, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| Family: BarBeansocketShamrockPartition, View: -1211536571, Targets: [InvokerLocator [socket://192.168.3.71:3873/], InvokerLocator [socket://192.168.3.65:3873/]]
| iteration 2 success
|
I will appreciate very much any information regarding this...
Konstantin
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039124#4039124
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039124
19 years
[EJB/JBoss] - Re: Accessing properties from jboss
by veeseekay
I could finally access the props specified in jboss-service.xml through an MBean, initially I had mentioned that I did not want to do it through MBean, but now due to a change, I have to do this, and here is an FYI on how to do it :
1) specify your key-value pairs in jboss-service.xml
Ex :
<!-- Additional properties required by the environment -->
<![CDATA[
Key1=11111
Key2=22222
.....
2)Now in your management bean, put an @Depends
Ex:
package com.abc.xyz;
// your import statements
/**
* @author somebody
*
*/
@LocalBinding(...)
@Service(...)
@Management(...)
@Depends("jboss.util:type=Service,name=SystemProperties")
public class MBeanClass implements MBeanInterface {
...
}
3)Now in your Mbean you can access the props with a System.getProperty() call.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039122#4039122
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039122
19 years
[Security & JAAS/JBoss] - Bug in security cache - 4.0.4.GA
by sim-smith
Hi All,
I've found (I think) a reasonably serious problem with JaasSecurityManager in JBoss 4.0.4.GA around caching. It doesn't happen very often but it can result in a logged-out Subject on the stack.
The root of the problem appears to be JaasSecurityManager.authenticate(), where it logs on first via defaultLogin() which results in a new SubjectContext on the stack. Authenticate() makes a subsequent call to updateCache(), which replaces the old cache entry with the new Subject, which in turn causes the LoginContext associated with the old cache entry to log out. This results in ClientLoginModule.logout() to be called, which logs out the expired Subject (by removing the Principal). It then pops the stack, which unfortunately does not result in the expired and logged-out Subject to get removed, but the recently-added Subject from defaultLogin().
This particular chain of events I would guess is mostly harmless, except in a particular situation that I find myself in:
1/ The security cache for the principal must timeout out before the web request is processed - thus we at the beginning of the request we get a Subject in the cache that has a LoginContext that is associated with a "live" Subject - it is on the stack.
2/ The security cache lookup must fail in a subsequent call within the same request where credentials do not match. Thus the getCacheInfo() call in isValid() succeeds, but validateCache() then returns false, which triggers the call to authenticate(). This happens for me when the credentials get mixed up between Strings and char[]. I've made another post on this point, but essentially ClientLoginModule generates char[] credentials, while FormAuthenticator generates Strings.
The result of this unlikely combination of events is that a Subject on the stack gets logged-out so all its Principals get removed, but it remains on the stack, causing the application to fail when trying to work out who is logged in.
I would love to suggest here an obvious and simple solution, but I can't see one at this stage.
I think that this is worthy of a JIRA issue, but I thought I would discuss it on this forum first.
I apologise - I haven't checked the source code for later versions of JBoss, but I have checked JIRA, and I couldn't find anything there.
Let me know if you need any more information.
Many thanks,
Mark
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039117#4039117
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039117
19 years
[Security & JAAS/JBoss] - Credentials - String or char[]
by sim-smith
Hi All,
I think that I have found an issue with the representations of Credentials in JBoss - sometimes they are java.lang.String, and other times char[]. (This is for JBoss 4.0.4.GA). In particular, org.jboss.web.tomcat.security.SecurityAssociationValve uses Strings (actually the root class is probably FormAuthenticator?), and org.jboss.security.ClientLoginModule uses char[] (because it comes in from the UsernamePasswordHandler).
This causes a problem with the caching, because the credentials are stored initially as a String (because of the SecurityAssociationValve), and when accessing an EJB the ClientLoginModule pushes onto the SecurityContext stack with char[] credentials, and so the cache lookup fails (org.jboss.security.plugins.JaasSecurityManager.validateCache()).
As it turns out this is of little conseqence in itself because it just results in another authentication, and hits the login modules again. It happens to trigger another problem though, but I'll save that for another post.
I would suggest though that this is a minor bug - JBoss should be consistent here to avoid the additional hit on the credential cache. Probably the best approach would be to modify either the ClientLoginModule to use a String, or SecurityAssociationValve/FormAuthenticator to use a char[].
I am thinking of raising a JIRA issue about this - does anybody have any comments?
Let me know if you want more information.
Many thanks,
Mark
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039115#4039115
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039115
19 years