Number of tests run: 910
Successful tests: 888
Errors:16
Failures: 6
[time of test: 9 August 2002 2:22 GMT]
[java.version: 1.3.1_03]
[java.vendor: Sun Microsystems Inc
Do you need to buffer a byte[] or can you stream it?
What is the latency issue? Should not have more latency than RMI. Do
you get the same latency with only one connection? If not, then perhaps
you are contending for a shared resource which introduces artificial
latency?
--jason
> -O
Why not.. Right not It creates a byte[] of the invocation before it puts it
on the wire. If it's greater than a certain size, we could do the
compression.
The current status of the "trunk" invoker is that it seems to have better
throughput than RMI, but worse latency. In otherwords, We can pus
> > SwiftMQ doesn't support start(suspend), so they return false for all
calls
> > to isSameRM(). This should cause all connections being enlisted to be
given
> > a unique xid (with different branch qualifiers). I think this is
compliant
> > with the JTA and XA specs.
>
> start(suspend) doesn't
Larry Sandereson wrote:
> I think I may have tracked down the SwiftMQ bug... let me know if this
> sounds right.
This is great. And it sounds right to me.
> SwiftMQ doesn't support start(suspend), so they return false for all calls
> to isSameRM(). This should cause all connections being enlist
Bugs item #592855, was opened at 2002-08-08 15:23
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=592855&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerald Turner (crazyfoam)
Assigned
Hrm... I guess this won't work for JMS though... fuck. Then a wrapper
for JMS connections too?
Bah, write once run everywhere my ass.
--jason
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED]] On Behalf Of Igor Fedorenko
> Sent: Thursday, August 08, 2
Jason Dillon wrote:
> Could some of these problems be solved by using a custom driver layer
> which would resolve these issues at the JDBC layer? Dain was talking
> about doing something like this at the last SF training. Then we would
> have one driver, which would delegate to the db specific d
No idea.
I found it there on HEAD, so I did the same thing for Branch_3_0. Then I
put in a similar directory for Jetty/JBossWeb.
Maybe Sacha or Bill can shed some light on this.
Jules
Scott M Stark wrote:
> Why is the jbossha-httpsession.sar under the docs/examples/clustering/
> directory r
We already have one of these for InformixXA that I can donate.
-Larry
> Could some of these problems be solved by using a custom driver layer
> which would resolve these issues at the JDBC layer? Dain was talking
> about doing something like this at the last SF training. Then we would
> have o
Yeah, but not at the moment, I am way busy right now.
--jason
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED]] On Behalf Of Larry Sanderson
> Sent: Thursday, August 08, 2002 2:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] [ jboss-Bugs-590816
Could some of these problems be solved by using a custom driver layer
which would resolve these issues at the JDBC layer? Dain was talking
about doing something like this at the last SF training. Then we would
have one driver, which would delegate to the db specific driver and
resolve the issues
Only JBossMQ and Informix XA. Not SwiftMQ yet. Do you have a setup where
you can test this?
-Larry
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 08, 2002 2:07 PM
Subject: RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors
Coo, just curious. This is a replacement for remote invocation which is
optimized for connections and data transfer? Do you know if the data is
very large that gets passed back and forth? If so, might want to add
optional compression. I have found that the time/cpu to compress (on
the fly) to
Have these patchs been used and verfified with JBossMQ and SwiftMQ?
--jason
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED]] On Behalf Of Larry Sandereson
> Sent: Thursday, August 08, 2002 2:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] [ jbo
Hi,
Scott M Stark wrote:
> Why do we have to work around driver bugs at the transaction manager
> level? Why not write the TM the way we want and start introducing driver
> specific JCA wrappers to deal with these issues?
Makes sense to me.
Then, we wouldn't have to add extra code in the TM cod
I think I may have tracked down the SwiftMQ bug... let me know if this
sounds right.
SwiftMQ doesn't support start(suspend), so they return false for all calls
to isSameRM(). This should cause all connections being enlisted to be given
a unique xid (with different branch qualifiers). I think th
I think I may have tracked down the SwiftMQ bug... let me know if this
sounds right.
SwiftMQ doesn't support start(suspend), so they return false for all calls
to isSameRM(). This should cause all connections being enlisted to be given
a unique xid (with different branch qualifiers). I think th
Feature Requests item #592807, was opened at 2002-08-08 17:29
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376688&aid=592807&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Emerson Cargnin (echofl
Why do we have to work around driver bugs at the transaction manager
level? Why not write the TM the way we want and start introducing driver
specific JCA wrappers to deal with these issues?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
--
Number of tests run: 896
Successful tests: 887
Errors:6
Failures: 3
[time of test: 8 August 2002 12:55 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[
21 matches
Mail list logo
