August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-3183) Integration with WebSphere MQ 5.x

by Luc Texier (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3183?page=comments#action_12340845 ] Luc Texier commented on JBAS-3183: ---------------------------------- Hi Weston, Thanks for all your efforts to make it happen What we need now is very simple. We need a standalone test case that we can provide IBM support with. Would you be able to produce such code or does it have to be executed within JBossAS? > Integration with WebSphere MQ 5.x > --------------------------------- > > Key: JBAS-3183 > URL: http://jira.jboss.com/jira/browse/JBAS-3183 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Environment: WebSphereMQ 5.3 with Extended TX client > Reporter: Luc Texier > Assigned To: Weston Price > Priority: Blocker > Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.1.CR1 > > > http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossA... > we need to make some changes to StdServerSession and StdServerSessionPool to integrate two workarounds in order to properly integrate with WSMQ 5.x and support their XA resource implementation and transaction handling -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-715) Invalidation fails with region based marshalling enabled

by Brian Stansberry (JIRA)

Invalidation fails with region based marshalling enabled -------------------------------------------------------- Key: JBCACHE-715 URL: http://jira.jboss.com/jira/browse/JBCACHE-715 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0 Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 1.4.0.SP1 Invalidation requires making a remote _evict command. This fails with region-based marshalling enabled because TreeCacheMarshaller140 doesn't know how to extract the Fqn from the evict methods. A simple fix is to include the evict methods in MethodDeclarations.crud_methods. If for some reason that's no good, the methods can be specially handled in TreeCacheMarshaller140.extractFqnAsString() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

2
3
0 / 0

[JBoss JIRA] Updated: (JGRP-236) Combine join and state transfer

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-236?page=all ] Bela Ban updated JGRP-236: -------------------------- Priority: Major (was: Critical) > Combine join and state transfer > ------------------------------- > > Key: JGRP-236 > URL: http://jira.jboss.com/jira/browse/JGRP-236 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9.2, 2.2.9.1, 2.2.8, 2.2.9, 2.3 > Reporter: Bela Ban > Assigned To: Vladimir Blagojevic > Fix For: 2.5 > > > Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase. > The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener. > - The JOIN_REQ contains the boolean > - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending > the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK), > we send it back to the joining member(s), and the RESUME sending messages -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JGRP-246) FD_SOCK thread "leak"

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-246?page=all ] Bela Ban resolved JGRP-246. --------------------------- Resolution: Done applied patch > FD_SOCK thread "leak" > --------------------- > > Key: JGRP-246 > URL: http://jira.jboss.com/jira/browse/JGRP-246 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2 > Environment: SLES 9 > Reporter: Bruce Schuchardt > Assigned To: Bela Ban > Priority: Minor > Fix For: 2.4 > > > While investigating a startup problem in an application that has one long-running group member and four other VMs that frequently close their channels and create new ones, I found that the long-running member was piling up a lot of FD_SOCK ClientConnectionHandler threads. When a channel is closed, FD_SOCK closes the socket that ClientConnectionHandler's socket is connected to, but on some operating systems (SLES 9 in this case) this doesn't always cause a socket.read() to exit. All of the ClientConnectionHandler sockets were stuck in this state. > I added a write(NORMAL_TERMINATION) before closing the socket, and changed ClientConnectionHandler to look for NORMAL_TERMINATION, and that seems to correct the problem. > > void stopPingerThread() { > if(pinger_thread != null && pinger_thread.isAlive()) { > regular_sock_close=true; > sendPingTermination(); // PATCH > teardownPingSocket(); > } > pinger_thread=null; > } > > // PATCH: send something so the connection handler can exit > synchronized void sendPingTermination() { > if (ping_sock != null) { > try { > ping_sock.getOutputStream().write(NORMAL_TERMINATION); > ping_sock.getOutputStream().flush(); > } > catch (java.io.IOException ie) { > if (trace) > log.trace("FD_SOCK io exception sending ping termination", ie); > } > } > } > void interruptPingerThread() { > if(pinger_thread != null && pinger_thread.isAlive()) { > regular_sock_close=true; > sendPingTermination(); // PATCH > teardownPingSocket(); // will wake up the pinger thread. less elegant than Thread.interrupt(), but does the job > } > } > ClientConnectionHandler > public void run() { > try { > synchronized(mutex) { > if(client_sock == null) > return; > in=client_sock.getInputStream(); > } > // PATCH STARTS HERE > int b = 0; > do { > b = in.read(); > } > while ( b != ABNORMAL_TERMINATION && b != NORMAL_TERMINATION); > // END OF PATCH > } > catch(IOException io_ex1) { > } > finally { > Socket sock = client_sock; // PATCH: avoid race condition causing NPE > if (sock != null && !sock.isClosed()) > closeClientSocket(); > synchronized(clients) { > clients.remove(this); > } > } > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3439) DelegatingPolicy: another preload required for jrockit

by Ralph Apel (JIRA)

DelegatingPolicy: another preload required for jrockit ------------------------------------------------------ Key: JBAS-3439 URL: http://jira.jboss.com/jira/browse/JBAS-3439 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.0.4.GA Environment: # java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) BEA JRockit(R) (build R26.4.0-63-63688-1.5.0_06-20060626-2259-linux-ia32, ) Reporter: Ralph Apel Assigned To: Scott M Stark org.jboss.security.jacc.DelegatingPolicy already contains certain special actions in its constructor to preload certain classes (see this constructor's extensive comments). For DelegatingPolicy to work with jrockit and not have all jacc+securitymgr tests failing with java.lang.NoClassDefFoundError: org/jboss/security/jacc/ContextPolicy ContextPolicy must also be preloaded within the constructor (just like PolicyContext.class is already). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-729) Notifications not received in Listeners when using Optimistic Locking

by Manik Surtani (JIRA)

Notifications not received in Listeners when using Optimistic Locking --------------------------------------------------------------------- Key: JBCACHE-729 URL: http://jira.jboss.com/jira/browse/JBCACHE-729 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0 Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Critical Fix For: 1.4.0.SP1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-501) Race with removallReferences

by Tim Fox (JIRA)

Race with removallReferences ---------------------------- Key: JBMESSAGING-501 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-501 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox There is a race condition whereby ChannelSupport::removeAllReferences can be called when delivery is in progress resulting in all refs being deleted before the delivery had returned resulting in a delivery remaining in the deliveries list -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-500) Intermittent race in BrowserTest::testBrowse

by Tim Fox (JIRA)

Intermittent race in BrowserTest::testBrowse -------------------------------------------- Key: JBMESSAGING-500 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-500 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.0.1.CR4 .main 11:29:38,156 INFO [BrowserTest] ####################################################### Start IN-VM test: testBrowse main 11:29:38,161 INFO [ServerManagement] IN-VM TEST main 11:29:39,759 INFO [WrapperDataSourceService] Bound ConnectionManager 'jboss.jca:name=DefaultDS,service=DataSourceBinding' to JNDI name 'java:/DefaultDS' main 11:29:40,094 INFO [ServiceContainer] remoting = "socket", serialization = "", database = "hsqldb" main 11:29:40,562 WARN [JDBCPersistenceManager] JBoss Messaging Warning: DataSource connection transaction isolation should be READ_COMMITTED, but it is currently NONE. Using an isolation level less strict than READ_COMMITTED may lead to data consistency problems. Using an isolation level more strict than READ_COMMITTED may lead to deadlock. main 11:29:41,066 INFO [ServerPeer] JBoss Messaging 1.0.1.CR4 server [server.0] started main 11:29:41,483 INFO [ConnectionFactory] Connector socket://localhost:9111 has leasing enabled, lease period 20000 milliseconds main 11:29:41,484 INFO [ConnectionFactory] [/ConnectionFactory, /XAConnectionFactory, java:/ConnectionFactory, java:/XAConnectionFactory] deployed main 11:29:41,568 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JCAConnectionFactory' to JNDI name 'java:/JCAConnectionFactory' main 11:29:41,569 INFO [LocalTestServer] server started main 11:29:41,661 INFO [Queue] Queue[/queue/Queue] started, fullSize=75000, pageSize=2000, downCacheSize=2000 main 11:29:43,235 INFO [Queue] Queue[/queue/Queue] stopped main 11:29:43,238 INFO [BrowserTest] ####################################################### Stop IN-VM test: testBrowse F Time: 5.09 There was 1 failure: 1) testBrowse(org.jboss.test.messaging.jms.BrowserTest)junit.framework.AssertionFailedError: expected:<0> but was:<1> at org.jboss.test.messaging.jms.BrowserTest.testBrowse(BrowserTest.java:207) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0 Only manifests on dual processor/dual core Need to run test around 20 times to reproduce -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Commented: (JGRP-248) Channel.down() hangs under some circumstances using multiplexer

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-248?page=comments#action_12340822 ] Bela Ban commented on JGRP-248: ------------------------------- I assume this is jboss-head (JBoss 5) ? I didn't see any Multiplexer code in 4.0.x. I'll checkout head then... > Channel.down() hangs under some circumstances using multiplexer > --------------------------------------------------------------- > > Key: JGRP-248 > URL: http://jira.jboss.com/jira/browse/JGRP-248 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.3 > Reporter: Jerry Gauthier > Assigned To: Bela Ban > Fix For: 2.4 > > > If I enable the ClusterPartition and TomcatClusterService mbeans for use with JGroups 2.3 multiplexer, the server startup process will hang when ClusterPartition invokes channel.down(). This is true even if the two services instantiate the multiplexer channel using createMultiplexerChannel(String, String) instead of the state transfer constructor. > To replicate this problem, the following steps are required. > 1) Modify cluster-service.xml to enable ClusterPartition for multiplexer use (e.g., remove the comments from the Multiplexer attribute). > 2) Modify tc5-cluster.sar\META-INF\jboss-service.xml to enable TomcatClusteringCache for multiplexer use (e.g., remove the comments from the Multiplexer attributes). > 3) JBossCache is currently inhibited from using the multiplexer in TreeCache.setMultiplexer(). The method's setter is commented out and a warning is issued if you attempt to use the multiplexer with JBossCache. If this is still true when you attempt to replicate this issue, you'll need to modify TreeCache.setMultiplexer() to allow the multiplexer to be used. > Note: I've only been able to replicate this issue when ClusterPartition and TomcatClusteringCache both have the multiplexer enabled. Using other cache services with ClusterPartition doesn't seem to trigger the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JGRP-239) FD_SOCK.interruptPingerThread() can cause NPEs

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-239?page=all ] Bela Ban resolved JGRP-239. --------------------------- Resolution: Done Added synchronization around pinger_thread > FD_SOCK.interruptPingerThread() can cause NPEs > ---------------------------------------------- > > Key: JGRP-239 > URL: http://jira.jboss.com/jira/browse/JGRP-239 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.3, 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.4 > > > [email from Bruce Schuchardt] > I doubt that I could reproduce it, but one of our apps ran into a NPE in FD_SOCK.interruptPingerThread on this line > if(pinger_thread != null && pinger_thread.isAlive()) { > This was during the passing down of a new view from pbcast.GMS.installView. > It looks like some synchronization is needed for this check in a few places in FD_SOCK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2006