[JBoss JIRA] Commented: (JBAS-7102) Problem sending large files via farm service
by Brian Stansberry (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-7102?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on JBAS-7102:
----------------------------------------
"The last chunk gets dropped by JGroups so there is no response." -- that's badly worded, so clarification here.
First, JGroups doesn't drop the message; the network does. For point-to-multipoint message JGroups (NAKACK) doesn't detect the last message was lost until there is another message. Since the sender is blocking waiting for an RPC response, it doesn't send another message. Only after the RPC timeout passes and the sender sends messages with the next file chunk is the dropped message detected. JGroups then retransmits the dropped message; i.e. it's not lost, just delayed.
> Problem sending large files via farm service
> --------------------------------------------
>
> Key: JBAS-7102
> URL: https://jira.jboss.org/jira/browse/JBAS-7102
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, ProfileService
> Affects Versions: JBossAS-5.1.0.GA
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: JBossAS-6.0.0.M3
>
>
> Users have reported issues sending large files over the AS 5.1 farming service; see forum thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Updated: (JBAS-7102) Problem sending large files via farm service
by Brian Stansberry (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-7102?page=com.atlassian.jira.plug... ]
Brian Stansberry updated JBAS-7102:
-----------------------------------
Priority: Major (was: Critical)
As noted on the forum thread, this occurred in an environment that was experiencing major multicast packet losses. In this particular case wasn't due to network buffer settings; rather seemed to be an OS virtualization problem. So not really a FarmService problem per se, so reducing from Critical to Major.
I'm leaving this open to see if I can find a way to make the service be a bit more responsive in these situations. What happens is it sends file chunks via HAPartition RPC, then waits for a response. The last chunk gets dropped by JGroups so there is no response. So FarmService waits 60 secs (default HAPartition RPC timeout) then sends the next chunk. The fact that responses weren't received is ignored.
Possible improvement is to send the chunks via async RPCs. The RPCs return null, and non-responses are ignored, so what's the benefit of a synchronous RPC? Even w/ asynch RPCs JGroups ensures lossless, ordered message receipt, and that's all that is really needed for these file chunks. The synchronous RPCs can be reserved for the final commit messages.
Effect of the improvement is there won't be long pauses in the transmission of file chunks. Lossy networks will still be slow, but should be better than what users reported.
> Problem sending large files via farm service
> --------------------------------------------
>
> Key: JBAS-7102
> URL: https://jira.jboss.org/jira/browse/JBAS-7102
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, ProfileService
> Affects Versions: JBossAS-5.1.0.GA
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: JBossAS-6.0.0.M3
>
>
> Users have reported issues sending large files over the AS 5.1 farming service; see forum thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (JBAS-7494) TxConnectionManagerUnitTestCase has poor TransactionTimeout usage
by Jonathan Halliday (JIRA)
TxConnectionManagerUnitTestCase has poor TransactionTimeout usage
-----------------------------------------------------------------
Key: JBAS-7494
URL: https://jira.jboss.org/jira/browse/JBAS-7494
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-6.0.0.M1
Reporter: Jonathan Halliday
Assignee: Shelly McGowan
Fix For: JBossAS-6.0.0.M2
org.jboss.test.jca.test.TxConnectionManagerUnitTestCase.setUp uses mbean lookup of a the TransactionTimeout property. This is not required to be present by the tx integration api, it's an implementation detail of the tx mgr. Hence this tests is unnecessarily fragile, especially since the only use of the value retrieved is to reset it after the test. Probably better to just call setTransactionTimeout(0) in tearDown, which will restore the default timeout.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (JBAS-7495) TestManagedConnection GlobalXID is broken
by Jonathan Halliday (JIRA)
TestManagedConnection GlobalXID is broken
-----------------------------------------
Key: JBAS-7495
URL: https://jira.jboss.org/jira/browse/JBAS-7495
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-6.0.0.M1
Reporter: Jonathan Halliday
Assignee: Shelly McGowan
Fix For: JBossAS-6.0.0.M2
org.jboss.test.jca.adapter.TestManagedConnection uses the GlobalXID class to wrap Xids. Setting aside that this is largely unnecessary abstraction, the implementation of GlobalXID is wrong. It converts a byte[] to a String, an activity which has undefined results where the byte[] contains arbitrary data that does not necessarily map to valid code points in the default charset. In particular, it can cause non-equal Xids to result in equal GlobalXIDs, which breaks the test. Having all methods on GlobalXID delegate to a wrapped Xid is better, or just remove the GlobalXID abstraction completely.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (JBAS-7490) cannot use logback-classic-0.9.17 inside a web application
by Anton Kraev (JIRA)
cannot use logback-classic-0.9.17 inside a web application
----------------------------------------------------------
Key: JBAS-7490
URL: https://jira.jboss.org/jira/browse/JBAS-7490
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: JBossAS-5.1.0.GA
Environment: Windows XP
$ java -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
16:09:30,299 INFO [ServerImpl] Starting JBoss (Microcontainer)...
16:09:30,299 INFO [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
Reporter: Anton Kraev
Assignee: David Lloyd
When bundling logback-classic-0.9.17 in a web application, the following is reported during startup:
2009-11-30 16:11:26,000 ERROR [STDERR] (main) SLF4J: Class path contains multiple SLF4J bindings.
2009-11-30 16:11:26,000 ERROR [STDERR] (main) SLF4J: Found binding in [vfszip:/D:/cw/jboss-5.1.0.GA/server/default/deploy/cwf.war/WEB-INF/lib/logback-classic-0.
9.17.jar/org/slf4j/impl/StaticLoggerBinder.class]
2009-11-30 16:11:26,000 ERROR [STDERR] (main) SLF4J: Found binding in [vfszip:/D:/cw/jboss-5.1.0.GA/common/lib/slf4j-jboss-logging.jar/org/slf4j/impl/StaticLogg
erBinder.class]
2009-11-30 16:11:26,000 ERROR [STDERR] (main) SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
We need access to logback APIs because we configure logging on the fly (change log levels without restarting the app)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months