Scott M Stark wrote:
There are two layers of integration between web containers
and JSR77 model components I want to implement for 3.2 The
first is the JSR77 WebModule which is handled at the
AbstractWebContainer level. Subclasses of AbstractWebContainer
need to populate the DeploymentInfo.mbeans
Bugs item #685329, was opened at 2003-02-12 15:29
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=685329group_id=22866
Category: JBoss-IDE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr. Domagoj Cosic (domic)
Assigned to:
Bugs item #680951, was opened at 2003-02-05 16:02
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=680951group_id=22866
Category: JBoss-IDE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Poinsard (xpoinsard)
Assigned to: Hans
Bugs item #684080, was opened at 2003-02-10 19:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=684080group_id=22866
Category: JBoss-IDE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan O\'Connor (ninki)
Assigned to: Hans
Bugs item #685329, was opened at 2003-02-12 15:29
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=685329group_id=22866
Category: JBoss-IDE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr. Domagoj Cosic (domic)
Assigned to: Hans
Scott M Stark wrote:
There are two layers of integration between web containers
and JSR77 model components I want to implement for 3.2 The
first is the JSR77 WebModule which is handled at the
AbstractWebContainer level. Subclasses of AbstractWebContainer
need to populate the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Wednesday, February 12, 2003 11:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] TxInterceptor split is really really good
The design goal is to produce a working dtm that
- long minTime in milliseconds
- long maxTime in milliseconds
- long totalTime in milliseconds
These numbers are a given servlet deployments service(HttpServletRequest,
HttpServletResponse)
method execution times. So there does need to be a per servlet deployment level
component to provide this
That is the issue. I would rather the web container not directly create the JSR77
Servlet model. Instead it should create its own management facade that is used
by the JBoss JSR77 layer to present the Servlet model mbean with the correct
naming structure. So there justs needs to be some way to
On 2003.02.13 08:22 Bill Burke wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
David
Jencks
Sent: Wednesday, February 12, 2003 11:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] TxInterceptor split is really really good
Scott M Stark wrote:
That is the issue. I would rather the web container not directly create the JSR77
Servlet model. Instead it should create its own management facade that is used
by the JBoss JSR77 layer to present the Servlet model mbean with the correct
naming structure. So there justs needs
The design goal is to produce a working dtm that does not make
unnecesary
inter-vm calls. The functionality of the client side tx interceptor
appears to be unavailable with the CORBA OTS if we do not write
some client
side stuff.
Here is the sequence of events for a
On 2003.02.13 10:35 Bill Burke wrote:
The design goal is to produce a working dtm that does not make
unnecesary
inter-vm calls. The functionality of the client side tx
interceptor
appears to be unavailable with the CORBA OTS if we do not write
some client
side
This is great stuff David, I will capture this on the forums for
historical
and referencial purposes. David, this whole email thread needed to
happen.
Yes, I was being abrasive somewhat, but I did it to get your attention.
Sometimes questions get ignored if you're nice
I'm putting the finishing touches on the JBossMQ HTTPIL, and one of the
requirements is supporting Basic auth. To support this, I'll need a
Base64 encoder in the client libs. Do we currently have one we use
already? If not, any suggestions? I hate to add a whole JAR just to
support Base64
I have seen this usage construct in a few places in the code and it makes
no sense to me:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
HashMap m = new HashMap(clients);
m.put(dc, cq);
This seems backwards to me. I usually do something like this:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
m.put(dc, cq);
}
...
}
public void someOtherMethod()
{
HashMap
There is a Public Domain Base64 encoder at
http://iharder.sourceforge.net/xmlizable/
The encoder itself is included in a jar somewhere but its
easy to move it into another class structure.
Regards
/Mikael
I'm putting the finishing touches on the JBossMQ HTTPIL, and one of the
requirements is
Hi Scott,
This is copy on write.
It works best when modifications are infrequent
compared to access.
e.g. connecting to a jms topic (modification)
and broadcasting messages to the connections (iteration).
Dain's version would copy on every message, rather than
only when a client
Assuming that iteration in someOtherMethod does not
change the map, ie, that the only updates are in
someMethod then it seems thread safe to me.
When someMethod is called it any ongoing iterations
will still be safe because the iterator is refering
to the old map that was copied, the insert is
If the map is seldom modified, then you can get around synchronization
with techniques like this. It is taking advantage of the fact that
assignement is an atomic operation. If the methods are like this:
public void someMethod()
{
HashMap localMap = null;
synchronized (clients)
{
There is one in org.jboss.security.Base64Encoder in the security module.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Nathan Phelps [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 13,
This is the direction I usually do it in...I use an implementation much like this one
when I want good atomicity on event broadcasting without excessive synchronization.
Generally, on an event listener array or something, I will have small sync blocks
around the critical method calls for
I think you are wrong, although I have trouble understanding all the issues
with this. I think this is a double checked locking idiom and I think it
is just as broken.
The guy who calls someOtherMethod will definitely see the correct hashmap,
but there is no guarantee that its state will match
This one looks to me as if it is not subject to double-checked locking type
problems. I think it is fine, since the copy is made in a synchronized
block and accessed in the same thread.
david jencks
On 2003.02.13 12:35 Dain Sundstrom wrote:
This seems backwards to me. I usually do something
Looks like you might be digging through some mq code
:)
I don't think that construct is too bogus... It
provides a copy write hashmap. Once the hashmap has
been updated, the rest of the read methods can treat
the hashmap as an imutable. No one will update that
hashmap ever again. To update
Yep.. your way is valid too but you take a
synchronization hit on every read. The otherway, the
performace hit is on the write. As I said previously,
if you read the map ALLOT more than you write to it,
then it makes sense to do it backwards.
Regards,
Hiram
--- Dain Sundstrom [EMAIL PROTECTED]
Hiram,
This type of construct creates some trick code. You iterate over the
keys, and I assume somewhere in the code you do clients.get(key). Well
there is no guarantee the the key is associated. I bet there are a ton
of other issues as your iterator in the read phase drifts from reality
of
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
foo = cache.get(cacheLooku);
if
JSR77 wants to provide a top down view of the JMS stats as shown in
the attached pdf page showing the JMSStats interface model:
JMSStats - JMSConnectionStats[] - JMSSessionStats[] - {JMSProduerStats[],
JMSConsumerStats[],
messageCount, pendingMessageCount, expiredMessageCount,
On 2003.02.13 13:40 Larry Sanderson wrote:
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
Ok, but the guarentee is only with respect the object reference, and the construct
still seems subject the the critiques of the double-check idiom made in the
Josuha Block book, in particular:
quote Effective Java, item 48, page 193
That a thread can observe the lazily constructed object in a
No, I don't think you can remove the synchronisation
Assume
Thread Statement
T1 localMap[T1] = new HashMap(clients);
T1 doSomething(localMap[T1]); // Add some stuff
T2 localMap[T2] = new HashMap(clients)
T2 doSomething(localMap[T2]);
T2 clients =
... do a bunch of reading on double checked locking ...
OK - I think I see where you are coming from now. Wow - I have to agree
with Joshua Bloch: wildly counterintuitive. Have you ever experienced
these things failing in the way you describe? How much performance gain
do VM's really
I'd just like to say that I believe David is exactly right here. I've
been following (or rather trying and failing most of the time) the
javaMemoryModel (http://www.cs.umd.edu/~pugh/java/memoryModel/) mailing
list, and this kind of issue is very difficult to analyse correctly.
My advice, FWIW,
Hi all,i'm implementing a system with many
clients and a server.This clients receives messages thought
JMS.
I'm trying that if I disconnect the net cable and
after a while i reconnect the cable i was able to receipt the
messages.
I have a Thread that checks the connection state
and
On 2003.02.13 14:42 Larry Sanderson wrote:
... do a bunch of reading on double checked locking ...
OK - I think I see where you are coming from now. Wow - I have to agree
with Joshua Bloch: wildly counterintuitive. Have you ever experienced
these things failing in the way you describe?
Ok, there we go, a well encapsulated form of the desired pattern. Yes,
let's use this instead as I think we have no guarentees of correct behavior
on multi-processor systems with heirachal memory caches.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
On Thursday, February 13, 2003, at 01:46 PM, Toby Allsopp wrote:
My advice, FWIW, is to stop messing around and just use util.concurrent
by Doug Lea
(http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/
intro.html).
There aren't many people who can prove that their tricky
Is anybody seeing a million errors just booting run -c all? How bad is the
testsuite failing? I'm in the process of getting a clean checkout, but
would appreciate if anybody has any info right now.
Thanks,
Bill
---
This SF.NET email is
Just as a reminder: the uncontended case for a synchronized statement
is VERY fast: about 13 PowerPC instructions. I would argue safety
first, use Java synchronization where possible, or advanced data
structures from the concurrent package if not. If a piece of code turns
out to be a
JBoss daily test results
SUMMARY
Number of tests run: 1026
Successful tests: 1022
Errors:3
Failures: 1
[time of test: 2003-02-13.12-05 GMT]
[java.version:
Bill,
I have been seeing errors since I rebuilt with the latest source about 1 hour ago.
I'm not sure yet what the problem is. When I run -c default, the server crashes after
a few seconds...
- Matt
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Thursday,
good point. I'll have to review the code in more
detail.
--- Dain Sundstrom [EMAIL PROTECTED] wrote:
Hiram,
This type of construct creates some trick code. You
iterate over the
keys, and I assume somewhere in the code you do
clients.get(key). Well
there is no guarantee the the key is
Arhh... It would be simpler if the JMX objects were
updated from client side. But since that is out of
the question for now, I'll just give you a few
sugestions:
- fake the session problem out and say there is
allways 1 session.
- Try to put the JSR77 code in an interceptor (like
the
migrating a small jsp app that uses an oracle database from jboss 2.4.6 to
3.0.6, the following error is recieved from a page that calls commit() after
an insert/update/delete.
You cannot commit with autocommit set!
in 2.4, the commit was required to get any of our pages to work, and now
they
Do I get to update the CachedConnectionManager with the code from jb4
first? :-))
david
On 2003.02.13 15:40 Stefan Reich wrote:
Just as a reminder: the uncontended case for a synchronized statement
is VERY fast: about 13 PowerPC instructions. I would argue safety
first, use Java
Basically, no. 2.4 behavior is wrong, 3.x behavior is according to jca
spec.
In either case you should be able to do:
Connection con = ds.getConnection();
con.setAutocommit(false);
//do work
con.commit();
I don't know if it would work in 2.4 but you could also use UserTransaction
in 3.x
david
doh!
sorry! this should have been sent to the user list!!
-Original Message-
From: Sonnek, Ryan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 5:08 PM
To: '[EMAIL PROTECTED]'
Subject: [JBoss-dev] jboss 2.4 to 3.x migration error
migrating a small jsp app that uses an
JBoss daily test results
SUMMARY
Number of tests run: 1066
Successful tests: 1018
Errors:28
Failures: 20
[time of test: 2003-02-14.01-34 GMT]
[java.version:
Head is building fine for me and the testsuite errors are on the order of what
they have been. Yes they are high, but this how it has been for a while now.
These are the last three runs I have for head
Date:tests failures errors
2003-01-21.02-37: 1048 13 35
For better or for worse I've changed all Interceptors and Invokers to pass
back an InvocationResponse object. This will allow us to piggy back
information back to the client from the server for Interceptors that need
it.
I ran the testsuite and it looks about as good as it was before.
If
Why is this unfortunate? I thought it was a great idea that is long
overdue. I don't see the point in doing it 2 or three times,
so I'd do it
after all the interceptors are based on a common interface/model.
Yes, its long overdue. I'm doing it nowBy unfortunate I meant, this
is a
Hi all,
I'm using JBoss 3.0.4 with
Tomcat 4.1.12. Everything works well, but when I try to connect more than 10
users simultaneously the Tomcat shows the following message:
HttpConnector[8080] No
processor available. Rejecting this connection.
Is there any configuration
which I could set
54 matches
Mail list logo
