When doing a commit on AIO, I'm waiting 90 seconds until everything is committed on the transaction or it would then throw a timeout exception.
Should this timeout be configurable?
I don't foresee any situation (besides a bug) where a transaction would take more than 90 seconds to complete or receive a failure callback in case of a hardware failure, so maybe the hardcoded timeout is fine.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152168#4152168
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152168
When doing a commit on AIO, I'm waiting 90 seconds until everything is committed on the transaction or it would then throw a timeout exception.
Now a question.. should this timeout be configurable?
I don't foresee any situation (besides a bug) where a transaction would take more than 90 seconds to complete or receive a failure callback in case of a hardware failure, so maybe the hardcoded timeout is fine.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152168#4152168
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152168
Hmm... I would think JCR maybe not the right persistence mechanism for large amounts of transactional data - it certainly is suited for heterogenous message payloads, but it is generally more about content then billions of little messages.
Of course, with DNA implemeneting JCR, it can have "fast" modes where the versioning features and so on do not get in the way so it can cope with a deluge of data, but most other implementations I have seen would not cope that well with the number of messages. They cope well with large messages, however.
Just my 2c.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152167#4152167
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152167
anonymous wrote :
|
| This will fix JBMETA-42, but cause regression in ResolvedJndiNameUnitTestCase, which looks like it's testing for wrong resolved JNDI Names anyway. Base should be the EJB Name, not the Default JNDI Name, right?
|
No, if there is a given jndi name, it should be the unique root context for any other derivative jndi bindings. We are always given a jndi name in the tck tests, so this is what we are focusing on. The only time an ejb name should come into the picture is when there is no explicit jndi-name/mapped-name given.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152160#4152160
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152160
Hi,
we have similar implementation requirements for a fat client szenario.
1. The client part should get the TGT from cache
2. TGT should be send to JBoss
3. JBoss should get a Service Ticket from the AS Server with the aid of GSS-API
4. Service execution is secured
the first i have get working with the Krb5LoginModule, the second i should get work, but currently id dont know how i could get the third to work.
generelly i dont know whether its possible.
Is there a example how i can obtain the service Ticket from the AS Server with the aid from GSS-API?
@carstenKlein
can you give an example how it works?
it would be very helpfull
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152132#4152132
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152132
We've now got ejb3-deployers-beans.xml both in jbossas/trunk/ejb3 and projects/ejb3/trunk/core.
Revision 73509 removed the EJBStage2Deployer from the configuration in AS, leading to:
java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.EJBStage2Deployer
..when installing via the Plugin.
What's our plan for these files? Surely not to maintain 2 active versions?
To use the configs from Core is to put deployer code in AS with config elsewhere; to remove the configs from Core loses our ability to have the Plugin patch them correctly.
Predictably, my solution would be to extract the EJB3 deployers from AS. See (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135505).
In the meantime, I'll look at fixing up the Plugin using the diffs Scott made within AS.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152130#4152130
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152130