[JBoss JIRA] (JBTM-1566) Expose timed delivery feature of hornetq in btenqueue
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1566?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-444 to JBTM-1566:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1566 (was: BLACKTIE-444)
Affects Version/s: 5.0.0.M2
(was: 5.0.0.M2)
Component/s: BlackTie
(was: All C++ )
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M3)
> Expose timed delivery feature of hornetq in btenqueue
> -----------------------------------------------------
>
> Key: JBTM-1566
> URL: https://issues.jboss.org/browse/JBTM-1566
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Crispin Boylan
> Assignee: Amos Feng
> Fix For: 5.0.0.M3
>
>
> It would be good to be able to specify a delivery time for the message (either relative or absolute) in the btenqueue.
> on #jbossts it was discussed and apparently HornetQ does support this so it just needs to be exposed to the blacktie interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1569) Allow topics to be shared between servers
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1569?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-441 to JBTM-1569:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1569 (was: BLACKTIE-441)
Affects Version/s: 5.0.0.M2
(was: 5.0.0.M2)
Component/s: BlackTie
(was: Admininstration)
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M3)
> Allow topics to be shared between servers
> -----------------------------------------
>
> Key: JBTM-1569
> URL: https://issues.jboss.org/browse/JBTM-1569
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Crispin Boylan
> Assignee: Amos Feng
> Fix For: 5.0.0.M3
>
>
> At the moment topics can only service one server with multiple instances. If you try to add a topic to 2 different servers the XSD parsing fails with a message that a service must be unique to one server.
> Agreed that generally this should be the case, but for topics it would be advantageous for all servers to be able to subscribe to a topic, as although the logic is mostly different some of ours share functionality, and being able to send the same info in one call to multiple servers is useful.
> eg current functionality is allowed:
> <server name='foo'>
> <machine-ref id='fooapp1'/>
> <machine-ref id='fooapp2' />
> <service id='topica' type='topic' />
> </server>
> but I would like this to be possible:
> <server name='foo'>
> <machine-ref id='fooapp1'/>
> <machine-ref id='fooapp2' />
> <service id='topica' type='topic' />
> </server>
> <server name='bar'>
> <machine-ref id='barapp1'/>
> <machine-ref id='barapp2' />
> <service id='topica' type='topic' />
> <service id='barsvc'/>
> </server>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1571) Put a message of the day on the blacktie chat room to redirect users to the jbossts room
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1571?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-442 to JBTM-1571:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1571 (was: BLACKTIE-442)
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M3)
> Put a message of the day on the blacktie chat room to redirect users to the jbossts room
> ----------------------------------------------------------------------------------------
>
> Key: JBTM-1571
> URL: https://issues.jboss.org/browse/JBTM-1571
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Tom Jenkinson
> Assignee: Mark Little
> Fix For: 5.0.0.M3
>
>
> I don't have permissions Mark, I think you are the owner
> I tried:
> /msg ChanServ set #blacktie ENTRYMSG All blacktie discussions are being carried out over on #jbossts, please join us over there
> This suggests you are the owner:
> (05:30:01 PM) tomjenkinson: info #blacktie
> (05:30:02 PM) ChanServ: (notice) Information on #blacktie:
> (05:30:02 PM) ChanServ: (notice) Founder : nmcl
> (05:30:02 PM) ChanServ: (notice) Registered : Dec 22 10:31:29 2008 (4 years, 12 weeks, 5 days, 06:57:28 ago)
> (05:30:02 PM) ChanServ: (notice) Last used : Mar 15 15:29:07 2013 (5 days, 01:59:50 ago)
> (05:30:02 PM) ChanServ: (notice) Mode lock : +ntc-slk
> (05:30:02 PM) ChanServ: (notice) Flags : GUARD
> (05:30:02 PM) ChanServ: (notice) *** End of Info ***
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1572) a failure in the txfooapp quickstart does not return -1 so it appears to run even when it hasn't
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1572?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-390 to JBTM-1572:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1572 (was: BLACKTIE-390)
Component/s: BlackTie
(was: atmibroker-tx)
Fix Version/s: 5.0.0.Final
(was: 5.0.0.Final)
> a failure in the txfooapp quickstart does not return -1 so it appears to run even when it hasn't
> ------------------------------------------------------------------------------------------------
>
> Key: JBTM-1572
> URL: https://issues.jboss.org/browse/JBTM-1572
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Michael Musgrove
> Fix For: 5.0.0.Final
>
> Attachments: client.valgrind, server.valgrind, windbg.out
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Note, it will definitely be worth doing this in a branch/pull as I suspect the database isn't running atm so that will need a kick too
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1570) Allow both Non-XA and XA servers
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1570?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-445 to JBTM-1570:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1570 (was: BLACKTIE-445)
Affects Version/s: 5.0.0.M2
(was: 5.0.0.M2)
Component/s: BlackTie
(was: All C++ )
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M3)
> Allow both Non-XA and XA servers
> --------------------------------
>
> Key: JBTM-1570
> URL: https://issues.jboss.org/browse/JBTM-1570
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Crispin Boylan
> Assignee: Amos Feng
> Fix For: 5.0.0.M3
>
>
> For our application we have a mixture of XA and non-XA servers, for performance and probably due to the fact that Informix (our main DB) only lets one datasource be used in XA mode.
> Unfortunately the blacktie servers do an implicit tx_open, so if you have any XA data sources defined these get used and Informix thinks its in XA mode.
> I currently have a workaround for this which is to have a duplicate btconfig.xml with the XA sources removed and the servers which are NonXA get passed this in the -c of the server args. Seems to work nice, but would be good not to have to do that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1573) Transaction timeout incompatible with block forever
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1573?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-324 to JBTM-1573:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1573 (was: BLACKTIE-324)
Component/s: BlackTie
BlackTie
(was: atmibroker-tx)
(was: All C++ )
Fix Version/s: 5.0.0.Final
(was: 5.0.0.Final)
> Transaction timeout incompatible with block forever
> ---------------------------------------------------
>
> Key: JBTM-1573
> URL: https://issues.jboss.org/browse/JBTM-1573
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie, BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
> Attachments: blocking call.log
>
>
> Currently we set a transaction timeout (e.g. in TestRollbackOnly.cxx we call tx_set_transaction_timeout)
> This ends up putting a timetolive on the message of the same duration.
> Now, if this message is not received within the period of time it will expire.
> However we also use a block forever waiting for the response.
> This can lead to a call never returning.
> i.e.
> server advertises queue
> client sends message with small timeout (e.g. 4) and then blocks forever waiting response
> server gets round to advertising queue 5 seconds later but never sees the clients initial request
> client is blocked forever
> I realise that we are meant to block forever when a client issues a tpcall under transactional conditions but something needs to be done as this can easily happen on slow machines?
> Perhaps we need to make use of the DLQ to wake up the blocked client with an error message??
> Perhaps the client doesn't block forever and just calls txrollback if nothing is heard back??
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1576) Introduce a JBoss deployable artifact for the C++ XATMI services
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1576?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-121 to JBTM-1576:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1576 (was: BLACKTIE-121)
Component/s: Tooling
BlackTie
BlackTie
(was: All Java)
(was: All C++ )
(was: Admininstration)
Fix Version/s: 5.0.0.Final
(was: 5.0.0.Final)
> Introduce a JBoss deployable artifact for the C++ XATMI services
> ----------------------------------------------------------------
>
> Key: JBTM-1576
> URL: https://issues.jboss.org/browse/JBTM-1576
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Tooling, BlackTie, BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
> Attachments: onmessage.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Currently the XATMI services must be deployed in the standalone "Server" CORBA container
> It is expected to be advantageous to support the deployment of the services into JBoss for ease of management and performance.
> It is expected that the user will deploy a .war file containing a btconfig.xml defining the .so/.dll (also contained in the .war).
> BlackTie java code will read the btconfig.xml and calculate the path of the .so based on the place that AS7 unzips war files to during deployment PLUS the path defined in the users btconfig.xml
> If AS7 does not explode war files during deployment, it will not be possible for the user to package their .so in their .war file (I don't think - please do investigate this) and so a java.native.library.path will need defining at boot time and the user will need to place all their jni code in there thereby not supporting hot deploy unfortunately but still gaining the benefits of performance (not requiring socket comms between java and C).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1575) Test support for Informix
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1575?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved BLACKTIE-446 to JBTM-1575:
----------------------------------------------
Project: JBoss Transaction Manager (was: Blacktie)
Key: JBTM-1575 (was: BLACKTIE-446)
Affects Version/s: 5.0.0.M2
(was: 5.0.0.M2)
Component/s: Testing
(was: Testing)
Fix Version/s: 5.0.0.Final
(was: 5.0.0.Final)
> Test support for Informix
> -------------------------
>
> Key: JBTM-1575
> URL: https://issues.jboss.org/browse/JBTM-1575
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 5.0.0.M2
> Reporter: Michael Musgrove
> Assignee: Amos Feng
> Priority: Optional
> Fix For: 5.0.0.Final
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months